This article is only intended to describe the attempts I made and the attempts I saw in the team in the direction of design draft generation code after I joined Alipay. No industry history, no debate about direction. The article is mainly based on the formation of the current situation and the evolution of my ideas. At the end of the article, I will mention the new opportunities I see. So if you’re not interested in the status quo and the deduction you can just turn to the chapter on The Slings.
Based on the
When I first started creating code plugins for Sketch three years ago, I was targeting prototyping tools, not usable pages. I didn’t think it would make sense to generate usable code directly from design draft for two reasons:
- The front-end itself was in the middle of a debate about what framework to use, and the design tools had to be resolved before they could generate code that most developers would accept.
- Design languages are more different from programming languages than you think.
Let me elaborate on the second point. Layers in a design draft are usually expressed in a back-to-front order, with the front covering the back. Layer grouping is just for management, there is no logical aggregation relationship. In the image below, the red layer in the background is level with the shape layer and does not show inclusion.
And in design, it’s common to put things on the same layer by type rather than by logical attribution, which makes it easier for designers to batch when making changes. In front end componentization, components are almost always divided by logical function. The hierarchical representation of components is also a logical containment relationship. Only part of this relationship matches the visual front to back. In React, for example, many component-level expressions are not contextual.
Therefore, in order to achieve perfect transformation from vision to logic, there are only two possibilities. One is to restrict visual layers and group them according to logical requirements. The second is to rely on machine learning and other methods for intelligent recognition (there are open source projects in the community).
The first way is technically possible, but not human. Two aspects, one is to designers caused a huge learning cost. The big one does not mean that the designer can’t learn, but that the rules may be designed poorly or not easily enough, forcing the designer to do a lot of unnecessary extra work for himself. For example, elements that can be drawn by a designer on a single layer should be grouped and layered as required by the rules. The second is that these rules are likely to ignore the designer’s needs, such as the aforementioned problem of managing the same type of elements on the same layer. I tried to use some of the solutions in the community, and from a designer’s point of view, the experience was like:
Although I thought about the second way at that time, I did not explore it in depth. The reason was that the front-end changes were too fast at that time, and I thought it was impossible to find enough stable samples for training.
With this conclusion in mind, it occurred to me that while directly generating usable pages is not an option, prototyping is possible. The cost of communication between the designer and the front end is also an issue that needs to be addressed. The most common is that designers need to tell the front end of an element hover is what effect, click what effect, etc. Now that the designer has drawn these things, could you automate the way of expression and save the cost of manual communication? Prototyping tools like Axure have similar capabilities. However, these tools are usually aimed at the initial prototyping of the product, lacking visual details, and cannot completely replace the communication between the designer and the front end.
So I started to make the Sketch plugin Blade from visual draft to prototype. The plugin also requires the designer to follow certain rules to some extent, but the rules are already meaningful to the designer, saving him the verbal description.
On the sidelines
After the first version was developed, there was no more maintenance due to job changes. Later, it became unusable due to API changes after Sketch upgrade. To my surprise, some people kept opening issues and writing emails in the past two years, hoping that I could continue to update. In the issue, I euphemistically indicated that the project is no longer maintained, and you can try other schemes in the community. But there are only a handful of other projects in the community, and the direction and orientation are not quite the same.
In the order I came across them.
Marketch, too, generates HTML files, but focuses on annotation functions that make it easy for front-end students to get location and style information. This positioning is very precise and eliminates the need for the front-end to install its own Sketch.
According to the ecosystem of Sketch, plug-ins can be divided into two categories. One is for the convenience of designers, such as the quick generation of some commonly used elements, such as head pictures and maps. The other is extending functionality beyond design, such as generating standards and prototypes. The former category of plug-ins is relatively easy to develop for individual developers, and the benefits are clear. While the latter is relatively difficult and profitable are not optimistic. In the second category of plug-ins I have seen since, they are almost always developed by teams. For example, Framer and Proto. IO.
What both tools have in common is that they have moved away from the Sketch system and become stand-alone applications. Integrate the output of tools such as Sketch/Photoshop in an imported way. But positioning is still an interactive prototype. It wasn’t until Launchpad that I was aware of the first plugin aimed at generating usable pages.
According to the functionality provided by Lauchpad, the page generation function is very simple, only simple links, forms, and does not involve complex interaction logic. The generated code cannot be redeveloped. But Launchpad has made a business, and seems to be doing well. From the designers I’ve been communicating with via email, I’ve also found a lot of requests to build websites directly. Let’s go back to the two reasons WHY I thought this path would not work. Was I wrong?
The first reason is that I think the generated code has to be acceptable to the front end. Launchpad seems to circumvent this problem by not providing this capability. But it also limits ability.
The second reason is the difference between design languages and programming languages. Similarly, narrowing down the scenarios that need to be covered and not providing secondary development also minimizes the burden on the designer.
So it’s not a question of right or wrong, it’s a question of being positioned differently. When I think about this question, I don’t really differentiate scenarios, I target situations where simple pages to complex single-page applications should work. Launchpad offers a new idea, which is partially achievable by scaling down the scene.
The related plug-ins listed above are made from a design perspective. Airbnb’s Recent React-Sketch plugin offers a new perspective.
Its goal is to design the management of assets. It has the ability to import design assets, components, from code into Sketch and export them from Sketch into code. So we can say that we’re both standing on the designer’s side and we can say that we’re standing on the front end. There is a comment on the React sketch on Zhihu. The first two answers are very clear. Readers can take a look. The tools mentioned in the answer don’t work well in real teams, and I agree. Because it was looking at things from a new perspective, there had to be a new role (design engineer?) with the same perspective. It’s worth showing up. Otherwise, designers alone, to the front end, will feel little significance.
Similarly, the React Sketch provides a new way of thinking about the value of unifying code and design elements in terms of design assets. This unity, in fact, is able to convert each other.
Cast stone
Just observing the evolution of the Sketch plugin is not enough to trigger new thinking about the thesis. The real opportunity came in the last year or two of working on frameworks and visual platforms. Let’s go back to the first two reasons, or two problems, that I thought didn’t work, and see if anything has changed over the last two years.
Following the thread of designing assets from the previous section, let’s first look at the second difference between design languages and programming languages. Unifying design and code with component dimensions is essentially a compensation for design. Since designers need to adhere to a common convention to use or modify the design of components, rather than following a personal custom, let the burden of such conventions be minimized, which are generated automatically by plug-ins and require no extra memory. At the same time, fully automatic management of resources is provided to designers as compensation. Management with tools can be shared through the team’s platform. If the whole team needs to upgrade or modify in a unified way in the future, it can be completed in a unified way through tools, without the need for human synchronization.
Further, because the component itself is a logical unit. While designers may not follow logical units, they still follow logical units when receiving information and communicating with others. In fact, this design tool can do more convenient functions for designers. For example, you can “quickly select the layers of all buttons, forms, slides and other components to modify them in batches”, etc. Replace designers’ habits of improving efficiency with technology.
In this way, the second problem seems to be solvable by shifting the perspective a little bit and taking the initiative to make some changes for designers.
Looking at the first question, what kind of code to produce is acceptable to the front end. First, at least within Alipay, there is little debate about the front end framework. React and its ecosystem are generally accepted. In actual React code, however, atomic components are usually wrapped into corresponding business components with business logic. Only a few business components are visible at the top level. Unlike in the design, where all components are atomic, the top layer is visible. When I thought about this, I suddenly realized that this was no longer a problem because we were already using a tiled, top-visible component structure in our visual scaffolding. As long as there is a suitable application layer framework, it can solve the problem when the page structure is relatively stable. The component tree in the lower right corner of the figure below represents the tiling of similar layers.
We abstract the concept of data tree from the tiled component structure. By manipulating the data tree, you can perfectly control the entire component tree, that is, the entire application. Advanced functionality that rises to the application framework level, such as form validation, is also built on the data tree. With a data tree, you actually have a logical entry point to the actual page. The following figure shows the data tree directly visible to the user in debug mode.
Thinking of this can not help but look back to find a simple but can produce qualitative change idea:
To do secondary development, the generated code doesn’t have to conform to manual coding specifications, or even be readable!
We can think of the generated interface as a black box application, as long as the secondary developer can control it through the API! (See Front-end servitization — Death and Life of page-building tools). The application complexity supported by this approach, which is actually the application complexity supported by the corresponding logic writing style, is not related to the interface itself.
At this point, both problems have been solved, in the visual automatic generation of this road is a new stone.
whispers
Automation from design to code can actually be seen as the final piece of completion of the visual platform. As of today, the previous visualization platform has supported 56 systems and output more than 1000 pages without front-end involvement. The link has gone from development to automated testing to online. The test tool effect is shown as follows:
If the design link is successfully added, the page development scenario can be imagined as follows:
- Simple display class pages can be launched directly from the design draft.
- If interactive logic is needed, the front-end will complete the logic in the generated code. Record the test case and go live.
- If the design is modified in style and the logic is not affected, then the design can be automatically re-tested and online after the design is changed, no front-end involvement is required.
- If there is a logical change, the platform can get the component change through the diff design and then get the logical code scope of the impact through semantic analysis.
Once you’ve built this assembly line, you’ll produce enough standardized samples that might be good enough for ai to make your dream come true.
Also, readers who want to get involved in this can talk to me at [email protected].
A reader asked
We received some very high quality reader questions recently, excerpts of which have been compiled here (and some of the answers have been revised) :
Q:
Component-level precipitation doesn’t feel like much of a breakthrough in efficiency. But when it comes to downgrading functionality to visual constructs like CURD pages, I see a lot of potential problems that may boil down to the balance between “flexibility” and “efficiency.” The biggest problem with the backend class system is not the standardization of the presentation layer, nor how the presentation layer is created by drag and drop. The biggest problem is “the intricacies of the interface data layer and related logic”. For example, the presentation of a date component might be related to the selection of the previous category Select, which in turn might be dynamically fetched by an asynchronous interface that might be pieced together by other components’ Queries. I do not rule out that building a complete logical data control flow and providing a complex configuration interface can solve this set of problems. But if this approach comes with a huge configuration cost, isn’t it better to invest in the front end manpower? The traditional way of writing code, at least developers have direct control of the code, although more code, but more intuitive and maintainable, rather than a black box.
A:
The tradeoff between “flexibility” and “efficiency” does come up in real situations. Flexibility means that most scenarios have to be considered, and that systems mean providing a variety of capabilities to solve a variety of problems, which means higher learning costs. An example of this is the Angular1 design in the front-end framework, which provides services, filters, and other mechanisms that cover enough scenarios but make learning costs steep. And when we built this system, we came up with a solution that kind of circumvented that problem. Our solution: provide a “progressive, extensible, programmatically readable” abstraction with the goal of letting the back end do what the front end does. Let’s explain the plan.
Incremental means that for some simple pages, the system can actually put the page together and configure the component data (many similar systems provide a “configure data source” way to do this). For complex pages, the system can provide other ways, such as writing simple logic code to handle the logic. In short, as the user grades the complexity of the scenarios the user is working on, a step up provides him with new solutions to the new problems he encounters. The key here is that the solution should be as downward compatible as possible. For example, in www.cnblogs.com/sskyy/p/649… At the bottom of the list, users manipulating the data sources themselves with logical code can solve any problem, which is sufficient for simple scenarios. However, in some more complex scenarios, such as “check whether each item in the form has been verified before deciding whether to send a request”, it is not convenient to let the user read component data one by one, so we inject a form object into the user’s logical code on this basis. Methods on this object help him quickly read form component data. But essentially, it’s based on the original component data tree. This is compatible for the user regardless of the scenario, regardless of how the code is written. Learning is progressive bit by bit.
Similarly, easy to scale refers to the same scenario as gradual, only described to the developer. With the above unified manipulation of the data tree scheme, we can constantly add new auxiliary objects (called util) to handle different scenarios. For example, when sending Ajax, the component automatically displays loading state. With easy scalability, the system can be adapted to different scenarios with minimal cost, and it also provides the possibility for third-party developers to provide capabilities for the platform. Finally, “program readable” is the key to ensure the stability of the system and the application is not out of control. Our system starts with the understanding that user-written code is only in response to “component events” and there are strict rules about how to manipulate the component data tree and how to use util. With this foundation, we have a very strong understanding of the intent in the user’s logic. For example, we can now scan the code before running to indicate which components are affected by which logic. Component names have been changed, which logic code has been changed, and so on. Also, more powerful debugging functions can be achieved by wrapping the API in the debug state. This is also the answer to “why should users give up flexibility and continue to use your system after accumulating certain experience?” Because users give up flexibility, we can provide stronger escort for them.
Finally, going back to the previous topic, I can’t agree more that “flexible” and “efficient” are two ends of the scale. But you don’t have to worry about it. I was inspired by a book on interaction design that talked about thinking of users as “smart but busy people.” “Smart” means that if you give him abstractions that are common or simple, he will pick them up quickly. Being busy means thinking from his point of view, once you have mastered the abstraction, how you can speed up his work or offer him ways to speed up his work on his own. As long as you’re “getting smart people to get things done quickly,” you’re successful, and people who can’t use your product probably aren’t really good enough to use it. From this point of view, it will be found that the reason for the contradiction between flexibility and efficiency is that there are “smart efficiency” and “stupid efficiency” in efficiency. “Dumb efficiency” means you have to package everything to him, which is the opposite of being flexible. So give up “stupid efficiency” and forget about it.
Q:
The hardest part is getting the designers to work with you directly from the design draft, because it puts more constraints on them. How do you deal with that?
A:
Compared to specific technical problems, this is actually the most difficult problem to solve. In fact, I mentioned slightly in the article that constraints are the key to “automation” and cannot be avoided. In this article airbnb. Design /building- A -… This is also mentioned in the. Since it can’t be avoided, the key is how this constraint benefits the designer as well. As mentioned in our article, there is really only one constraint on designers: “Normalize layers in a specific way, such as naming them, so that they are associated with the components to be generated.” We have now launched the project, and the designers are directly involved, and we talked to them about the key points that are valuable to them:
1. Benefit from process. If the platform can ensure that as long as designers follow the rules, it will look exactly like the design, then designers won’t have to double-check the actual page before they go live.
2. Management of design assets. The concept of “component” is common to both the front end and the designer, who currently lacks the tools or specifications to manage components in a code base. If we can programmatically read what components designers use and how they use them, then we have an opportunity to create design asset management tools for designers as well. For example, the design component library management tool can automatically tell the designer which corresponding components on the page should be upgraded when the overall design style is upgraded. If the design is well done, it can even automatically upgrade the visual draft.
3. Satisfy the designer’s product heart. If the system is stable and easy to use to a certain extent, designers actually have the opportunity to make products that work. This in itself is a great temptation for designers.
In addition to these specific points, the most important thing is to involve the designer directly in the design of the programming system, which naturally breaks down the barriers between the functions themselves.
Q:
Why do you want to do such a thing, and when open source?
A:
Over the years, I have been working towards improving the efficiency of web application development, both as a framework and as a tool. After witnessing the constant changes in the front-end’s new underlying technologies (browser environment, language) and frameworks, I realized one thing:
There is no question of r&d effectiveness for the individual. Because a person can deal with a limited number of problems, also need to use a limited number of things, tools are not easy to use is another. The idea of programming is to learn something new. But for big companies, the problem is radically different. First of all, the imbalance of resources will produce “short board effect”, for example, the lack of front-end personnel, it is impossible to drag down the whole product development because of this, right? So some departments overtime, some idle. For example, the excessive division of functions and the long process lead to a sharp increase in communication costs in the middle, which will also greatly drag down the overall efficiency.
I’ve been exploring frameworks, tools, “finding the right abstraction,” “practicing a programming philosophy,” which are really personal solutions. The common solutions seen in the industry for teams are building “component libraries”, building various “publishing platforms”, “monitoring platforms”, and so on. These are all solved by improving the “reuse capability of a tool”. You see fewer process-specific solutions. After seeing so many frameworks and tools rise and die. I think a “process automation” approach to problem solving is more helpful for large teams and companies. Therefore, the most important thing in this article is not the specific implementation technology, but the whole process series of “design – RESEARCH and development – test – deployment”, and realize automation in the process. I’ll write a separate article on this, but we should be slowly moving into a new phase of Web application development. I also welcome readers who are interested in writing and communicating with me. I will continue to update this post.
The platform will gradually be open source in the form of tools. If you want to participate, please contact me first.