preface

We have been busy in the last month or so, because the project of our group has progressed to a more in-depth stage and is no longer in the early stage of function accumulation, so we need to optimize the project in a more refined and targeted way. One of the optimization points is the UI style and optimization. However, due to the tight time in the early stage of the project, some necessary work was not carried out, and the subsequent release of THE UI style in the project led to the repeated UI repair recently, which greatly reduced the work efficiency.

Problem description and cause

  • Problem description

    • Inconsistency of design drawing is the first problem on the design drawing, each version of the design of the same function module style is not unified, such as the following two pictures:

      It is obvious that the same subtitle, a few weeks after the release of the version of the design is not the same, this example is a glance to see the problem. Others, like these two images, are not.

      This is the font color change between different versions of the same module, and this change is not made by any rules, it is simply a similar looking color just put on top of it. This problem does not occur between one or two versions. Every design has some very subtle but unnegotiated changes, including but not limited to font size, font color, background color, spacing, border thickness, etc. This leads to a bigger problem.

    • We all know that in modern front-end development we use some CSS preprocessors, for examplesass.less, and these preprocessors contain the function of style variables, so we rely on the function to make some style variables, and then introduce these variables where they are needed, such as the font size variable shown below:

      The advantage of this is that you only need to modify this variable if you want to change some styles later. In this step, we implemented the project construction at the beginning of the front end, but later, due to the first problem (the design drawing style is not uniform), we changed back to writing each color separately, and the variables set in the early stage are basically invalid. As a result, styles are hard to maintain, and a significant amount of time has recently been spent changing styles one by one.

    • The problem of not having a UI review process has always existed, but because the project was still in the functional stacking stage, the emphasis on UI style was not enough, so there was no review. Sometimes a pixel or two was missing in some places. When the project enters the intensive cultivation stage and begins to pay attention to UI, it will be found that each module of the application can be looked at alone, but there will be problems such as asymmetry and awkwardness when viewed as a whole.
    • Everyone’s understanding of the UI style different to the front-end duplication of effort This problem is caused by the process is not standard, pure performance for the UI design comes out, the front set out to work, because before making cost to other functions don’t know what is the design, so after finished product out a see everybody think it is wrong that is not good, Then the designer comes up with the diagram and does the front end. This leads to a lot of wasted work, a lot of wasted time, and it undermines motivation.

  • The causes of problems In fact, the above three questions are based on a cause, is in the initial stage of project, not for the UI style and interactive way to develop a unified standard, it will lead to the designer when designing product figure is in a state of a headless flies (sometimes is directly copy the style of the design before, And then it’s not hard to see that this is a chain reaction:

No unified UI style standards -> designers design product drawings without basic points -> style design is not unified -> front-end work to fly -> constantly reworkCopy the code

The solution

It will certainly take a lot longer to formulate UI standards when the functions of the project are basically completed at the present stage. However, UI rectification is something that needs to be done immediately. Therefore, a solution suitable for the current stage is obtained after discussion with functions such as design and product:

  • Due to the pressing time, we decided to develop some basic standards, such as color font and other standards, as shown below:

    Then the project is divided into several large modules, and the corresponding standards (spacing, expression, interaction, etc.) are formulated for each piece. Finally, after the standards of each module are formulated and the UI rectification of the project has come to an end, the standards of each module are unified.

  • The process specification sets UI review and UI review stages in the existing development process, from drawing design to front-end completion, and the process is roughly as follows:
Product requirements will be -> designer drawing -> UI review (all relevant personnel involved) -> Front-end take over -> UI review (designer review, similar to testing)Copy the code

Afterword.

Finding and solving problems is the most fundamental work of a programmer. At present, our project team has started to implement the above-mentioned solutions and obtained certain results. But there are other issues as new steps are added to the workflow: Well such as the time is too tight on the execution, etc., and in the foreseeable future, as including, but not limited to the UI style of various standards and unification, the standard of maintenance costs will certainly more and more high, so is still a long way to go, now on these emerging issues and have no thought of what better way, and can only be in the subsequent see the following instead.