Author: Convex Man-TT
preface
In the process of front-end development, the most closely working position with the front-end should be the designer. In business processes, designers give their interactive and visual artwork to developers with an expected error of 1px or less. But there are a few inconveniences along the way:
-
Design draft can be disassembled into layout, pattern, text, color, etc. The style coding of layout, text, and color takes a lot of time for the front-end developer. Although in recent years, with the birth of blue Lake and other design collaborative working platforms, some CSS codes can be obtained on the platform, but it still cannot meet the situation of web, iOS, Android and other multi-platform.
-
The update of the design draft cannot be reflected in the developer’s code in time. Firstly, the developer needs to get the new design draft first, and then update the code after judging the difference according to the annotation or even the naked eye. On the other hand, seemingly simple changes in the design can lead to larger code changes, such as font sizes.
To address these issues and improve the collaborative process between Design and development, Design Tokens emerged.
What are Design Tokens
Before understanding Design Tokens, you need to understand the concept of Design System. This concept has been prevalent in the design and development communication process for a long time, and is integral to the engineering of team design systems.
A Design System is the single source of truth which groups all the elements that will allow the teams to design, realize and develop a product.
The design system can ensure the consistency of the design manuscript and the development code in the project — the designer componentizes the content of the design manuscript and uploads the style, text attribute, color value and so on of each component in this system. And developers can get their own components through this system. But this only implements a collaboration platform, so how to solve the two problems mentioned above?
Design Tokens is at the heart of problem solving.
Design tokens are the visual design atoms of the design system.
Design Tokens unify style attributes and front-end languages, treating each attribute as a front-end variable.
For example, when a color value is passed into the system and converted into a token, the front-end can directly take this variable and use it. Even if the color value is changed, while the variable name remains unchanged, it has no effect on the overall code, and all the developer has to do is re-import a token.
The language type of the token can be CSS, SCSS, or YML.
How to Develop Design Tokens
Given that Design Tokens are essentially variables, what we need to do is transform color values and text attributes into corresponding variables.
Among them, the text attribute has a special place. In addition to converting font-family, font-size and other variables into variables, it also needs to set these variables in a mixin to facilitate the overall use.
So there are four things we need to do: get the property, generate the variable, generate the mixin, and output the result. Get attributes without saying much, directly from the database to get the color value and text data, and then write json file to save.
1. Generate variables
There are eight variable types that we converted, including CSS, SCSS, LESS, stylus, JSON, YAML, Android and iOS. Among them, CSS, SCSS, LESS, stylus and Android are realized through Theo library, and the rest are realized manually by the code.
Theo
Let’s start with Theo, a library that can transform and format styles and then output the corresponding variables. The implementation principle is roughly as follows: first, the values in the JSON file are processed — the color values are processed as RGB or RGBA, and the values of the rest of the style attributes are unified in units. The processed value is then written to a new object according to certain rules. And that object is Design Tokens.
Directly on the code:
static async formatWebOrtAndroid (type: string) {
const res = await theo
.convert({
transform: {
// Here is the type, can be Web or Android
type: 'web'.file: path.resolve(__dirname, 'data.json'),},format: {
// Here are the variable language types to be output: CSS, SCSS, less, stylus, Android, etc
type,
}
})
.then(data= > {
// Here you can do data processing according to your own needs
return data
})
.catch(error= > console.log(`Something went wrong: ${error}`))
return res
}
Copy the code
Custom methods
Other json, YAML and iOS need to be implemented manually. Json and YAML are very simple to implement. You just need to manipulate the data into the format you want, and then write to json or YAML files.
IOS is a bit more complex and supports both Objective-C and Swift, so you have to deal with both languages separately.
-
Objective-c needs to be split into.h and.m files, and the color values are processed as follows:
// Write the variable name first let colorsH += `- (UIColor *)${colorName}; \n` // Process the color value under the corresponding variable name let colorsM += `- (UIColor *)${colorName} { return [UIColor colorWithRed:(${red})/255 green:(${green})/255 blue:(${blue})/255 alpha:(${alpha})]; }\n\n` // handle the beginning and end colorsH = `@interface UIColor (Colors)\n\n${colorsH}\n@end` colorsM = `#import "designTokenColor.h"\n\n@implementation UIColor (Colors)\n\n${colorsM}\n@end\n` Copy the code
-
Swift handles this in a similar way, directly to the code:
// Write the variable name first and process the color value let colorsSwift += `class func ${colorName}() -> UIColor{\n return UIColor( red: (${red})/255, green: (${green})/255, blue: (${blue})/255, alpha: (${alpha}) );}\n\n` colorsSwift = `import UIKit; \n\nextension UIColor{\n\n${colorsSwift}\n}\n` Copy the code
In fact, the above custom methods can also be defined directly in Theo, because Theo supports the registration of custom Transform events and custom Format events, and the secondary processing of the obtained data.
2. Generate a mixin
A mixin is the name in SCSS, which is essentially a collection of variables that allow a set of attributes to be applied collectively. Since Theo does not provide corresponding methods, we adopt manual generation. So far only the literal attributes we need to use have been built.
We already generated the variables for all the attributes in the first step, so when we build mixins, we just need to combine the corresponding variables, which is not a lot of work. However, due to the need to build more language types, for different languages to output different formats, so still write part of the similar code.
The following code is generated for content in different languages:
-
css
--aotu: { font-family: var(--aotu-font-family); font-size: var(--aotu-font-size); font-style: var(--aotu-font-style); font-weight: var(--aotu-font-weight); letter-spacing: var(--aotu-letter-spacing); line-height: var(--aotu-line-height); opacity: var(--aotu-opacity); text-align: var(--aotu-text-align); color: var(--aotu-text-color); text-decoration: var(--aotu-text-decoration); text-transform: var(--aotu-text-transform); }; Copy the code
-
scss
@mixin aotu () { font-family: $aotu-font-family; font-size: $aotu-font-size; font-style: $aotu-font-style; font-weight: $aotu-font-weight; letter-spacing: $aotu-letter-spacing; line-height: $aotu-line-height; opacity: $aotu-opacity; text-align: $aotu-text-align; color: $aotu-text-color; text-decoration: $aotu-text-decoration; text-transform: $aotu-text-transform; } Copy the code
-
less
.aotu () { font-family: @aotu-font-family; font-size: @aotu-font-size; font-style: @aotu-font-style; font-weight: @aotu-font-weight; letter-spacing: @aotu-letter-spacing; line-height: @aotu-line-height; opacity: @aotu-opacity; text-align: @aotu-text-align; color: @aotu-text-color; text-decoration: @aotu-text-decoration; text-transform: @aotu-text-transform; } Copy the code
-
Android
// This is an object that contains various values<style name=${aotu.name}> <item name="android:fontFamily">${aotu.fontFamily}</item> <item name="android:textSize">${aotu.fontSize}</item> <item name="android:letterSpacing">${aotu.letterSpacing}</item> <item name="android:lineHeight">${aotu.lineHeight}</item> <item name="android:textStyle">${aotu.fontStyle}</item> <item name="android:textFontWeight">${aotu.fontWeight}</item> <item name="android:gravity">${aotu.textAlign}</item> <item name="android:textAllCaps">${aotu.textTransform === 'uppercase'}</item> <item name="android:alpha">${aotu.opacity}</item> <item name="android:textColor">${aotu.color}</item> </style> Copy the code
At this point, the generation of Design Tokens is complete.
3. Output the result
We save the output in various languages in different files, upload it to the server, and return the content and fetch links to the user. Users can download files directly from the link for use, or manually copy the content into their own projects for use. When designers change the draft, they need to re-upload the component content, and The content of Design Tokens changes accordingly. For developers, a large number of code updates can be directly completed by re-importing a new link, which greatly improves the efficiency of designers and developers, reduces the repetitive work of developers, and reduces the cost of communication and version iteration.
The Design application Tokens
Design Tokens have been applied to smooth workflows.
To start a project, you need to create a project on the internal quark platform, including designers and front-end developers. The designer then uses the Sketch plugin provided by the Quark platform to save the required color values and text styles into the project. The following is the display effect in the plug-in:
After the designer completes the above steps, the developer enters the quark platform and can view color values and text styles in the corresponding project. You can see the variable name for each attribute, and you can change the variable name.
All Design Tokens are presented in a single page, including a download link that developers can use to download content and apply it to their own project code.
conclusion
Design System may be a mode of cooperation between designers and developers in the future, but the corresponding applications are not very widespread at present. On smaller projects, people tend to talk, document, etc., rather than take the time to build a design system first. However, with the expansion and accumulation of projects of the company or department, a perfect design system and efficient communication platform will be necessary. Design System and Design Tokens bring us new approaches and new possibilities that we will continue to explore.