The GUI development process is different for each project team. The process of some project teams is very backward, and there is basically no framework design. They are all direct code setting UI controls, which is not conducive to iteration. Do better will use MVC related patterns for design, the following also only use MVC workflow. C is implemented by the client students. V was made by GUI students. In an ideal situation, the connection work of M and V should also be set by the GUI students, but because of some difficulty in getting started, it did not land well, so this part was finally set by the client students.
In general, the GUI development process is divided into the following stages. Planning will first put forward the interface requirements, the client program needs to carefully read the requirements of the document, to ensure that the requirements are complete. Because I have met with the incomplete requirement documents provided by the planner before, the requirement is inconsistent, the requirement details are missing, and the requirement is ambiguous. In one particularly outrageous case, the store’s requirements document did not give a specific numerical design. It is very inefficient to start working on the function when the requirements are not complete. It is necessary to ask the planning while working, and sometimes it takes half a day for a question to be answered by the planning. Don’t start with incomplete requirements, mention them more than once to the planner and the PM. The planner and PM must pay attention to the preliminary planning work, otherwise, it will become the planner to do whatever he thinks, add more content when he thinks of something, and delete the previous content when he finds that it is somewhat inconsistent with the previous content. This can lead to an unnecessary waste of time and, in extreme cases, a clean start.
Demand is clear after the GUI students output renderings.
After confirming the effect of the plan, the client students should also take a look at the effect drawing. See if there are any strange effects, discuss them, and decide how to implement them or change them. If the interface is more complex, you need to check the hierarchy with your GUI classmates.
Interface resource output. Generally, the output of interface resources is delegated to the GUI students, but some projects will delegate the output to the client students. A project team I once worked on did this. It needed to stack a semi-transparent rendering on the top of the interface and spell it out bit by bit. Sometimes an interface can last a day, eyes will explode, I don’t know if I am a program or a GUI. Regardless of who outputs it, pay attention to the naming of the UI controls and don’t use names such as A, B, C, 1, 2, 3. It is better to express the type and function of the UI control, such as LoginBtn, which means that this is a button to click to log in. After the client students get the interface resources, the first thing they need to do is to check whether the hierarchical structure of UI controls is reasonable. The hierarchy can be divided by region or function module. The advantage of this is that you can quickly locate the UI control you want, and then it will be much easier to iterate over the UI resources. In general, the amount of UI controls in an interface is not very small. Even if it is very small at the beginning, it will become more and more with the iterative optimization of functions and effects. Finding resources during resource iteration can make you wonder if you don’t handle the hierarchy of UI controls.
Once the UI resources have been processed, you can begin the data binding work. This process involves correlating V and M, and visual editing tools are typically provided without writing code. So this work actually GUI classmate also can do. But because data binding requires a deeper understanding of business requirements, most GUI students feel that this is not what they should be doing, and that they should only be responsible for producing good-looking interfaces that meet functional requirements. If the GUI student is responsible for the setup, the client program can start writing business logic code synchronously, and production is faster. However, it is necessary to do a good job of early communication to ensure that everyone’s cognition of the data is consistent, and this communication may also take time. In general, this work is better handled by the client program.
The client program can start writing logical code at this point. One principle that needs to be observed here is that since we are all using the MVC framework, we are not allowed to manipulate UI controls directly through code, only allow to modify the binding data corresponding to UI controls. In the process of realizing functions, it is generally not allowed to modify the style of the UI interface. If you do not want to modify, in the case of relatively small changes can be changed by the client program, and then let GUI students come over to confirm the next. If the change is relatively large, it will be directly handed over to GUI students to modify. GUI development as a whole is not difficult, as long as active communication is good. Generally speaking, if the development time is longer than expected, it is mostly due to some mysterious Bug in the development process, caused by the UI framework design. In this case, bugs that are easy to fix can be fixed directly. Bugs that are more difficult to fix can be recorded in a special document. It is convenient for others to find solutions quickly when they encounter the same problem, so as to improve the overall development efficiency, and also serve as a checklist to fix bugs later.