The conflict between web design and development tools has always been a long-standing problem in the industry. The final result of web design is usually a model, in which developers used to make websites and designers made websites "painted works", and this disconnect created huge friction. Which one is the source of the truth?
What if there really is a single source of fact? What if the design tool uses exactly the same code as the production website? The latest chapter of this protracted discussion is UXPin.
Let's get some facts first so we can understand all of this better.
UXPin is a powerful design tool with all the features you expect, focusing especially on digital screen-based design and advanced prototyping.
The fact that it is based on code is particularly important. Use all the visual components (which are actually rooted in code) to design the website, bringing the design closer to the final product. Your design not only looks like a website or app, but also features like a website or app. For example, instead of a static box with an outline, the input field gives you the real feeling of filling it with text.
Code-based design has provided all specifications for each element—such as this card component; exact colors (using the correct format), and precise pixel sizes, and more. In some cases, it is even possible to extract precise code of UI components for developers to use.
Ania Kubów elaborates on this very well in a video about UXPin.
More than a decade ago, Jason Santa Maria thought seriously about what the next generation of design tools looked like. Can we use the browser directly?
I don't think the browser is enough. Web designers jump into the browser before solving creative and information transfer problems, just like an architect knocks the wood together and then measures it. Tools limit imagination, and the imagination or inspiration at the beginning of design lays the foundation for everything that follows.
Jason Santa Maria , “A Real Web Design App”
Maybe not using the browser directly, but code-based tools can make the UI work like your website or application, which can be the best of both worlds:
Web pages are dynamic and living spaces, and the minimum interactions of visitors can change the scope of the entire website. […] Because we are not dealing with static media, we need to be able to design the changing sight of interactions and web pages […] Applications need to view elements, not colors or blocks of text. Photoshop, Illustrator, and Fireworks have some low-level features in this regard, but the need for more dynamic and non-destructive processing is obvious.
This is the magic of the single source of fact . If a design tool can output React (or any other framework) components, that's one thing. This is a clever trick. But it's likely to be a one-way trip. Components in real-world projects are filled with other content that is not entirely in the field of design. Maybe a component uses a hook to return the permissions of the current user, and if they don't have access, a button is disabled. Disabled buttons have certain design elements, but not the case for most code.
If the design tool cannot respect other code in that component and basically just ignore it, it is impractical. Essentially, if a design tool exports components as code, but does not allow designers to import these UI components first, it is not very useful.
This is where UXPin Merge comes in.
Now, to be fair, this requires some work to set up. It may only take a few hours or weeks to complete a complete system design. Currently, UXPin only works with React and uses webpack configuration to integrate it.
Once you start running, the components you use in UXPin are really the components you use to build your production website.
It's really impressive to see a design tool digesting pre-built components and allowing them to be used for prototyping on a brand new canvas.
UXPin helps you implement this feature in your project, including:
Components often have aspects such as attributes, attribute control design and internal content. UXPin provides you with a UI of properties, which means you have complete control over the components.
<code><linechart ...="" barcolor="green" data="{[" height="200" showxaxis="false" showyaxis="true" width="500"></linechart></code>Knowing this, you can provide a property interface for the component, providing a lot of design control. For example, the integrated theme switch.
Another tool that is very popular in the JavaScript component field for testing and building components is Storybook. It's not a design tool like UXPin - it's more like a "zoo" of components. You may have set it up, or you may find it valuable to use a Storybook.
What is the good news? UXPin Merge works perfectly with Storybook. It makes integration very fast and easy. In addition, it supports any framework such as Angular, Svelte, Vue, etc. - besides React.
See how fast it is:
UXPin CEO Marcin Treder has a strong vision:
What if the designer could use the exact same components used by the engineer, and all of them were stored in a shared design system (with accurate documentation and tests)? Many frustrating and costly misunderstandings between designers and engineers will no longer exist.
And a plan:
That's what they do here.
Experience UXPin Merge
The above is the detailed content of Developers and Designers Work on a Single Source of Truth With UXPin. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
