@viral3/ui-design-tokens v0.3.0
Table of Contents
What is this?
This tool a token generator that parses json files and automatically generates variables for Sass and JavaScript allowing each application to have the same visual consistency. 😎
This means we can update a global token here and all applications can be updated without having to make the same change over and over. 🚀
What are Design Tokens?
Design tokens are a set of styles — colours, typography and size variables that are used across a product and can be converted into a format for any platform such as mobile and web applications.
They are tiny pieces of UI information that take the place of hard-coded properties. They allow designers and engineers to share a common design language.
They were pioneered by Salesforce, you can view the talk they presented for more information.
Why?
As Third Bridge looks to expand our technical and business capabilities there is an increasing need for both external and internal user facing applications. These applications will need to scale in number to meet the growing demand that we foresee. At the heart of these applications lie the user interface (UI) and user experience (UX). We need a way to deliver brand consistency with the same look and feel and well crafted user experience that will help to propel Third Bridge past our competitors.
See the Design Tokens Tech Spec for more information.
Workflow
- A designer (LeNam) updates a global token (let's say the colour brand-01).
- The designer (or engineer) takes this value and updates the file
src/globals/color/color-brand.json - We run the build script
- We bump the package.json version (probably a major bump but decide together)
- Publish to our private NPM repo
- Update all consuming applications
Under the hood
This token generator uses Style Dictionary to generate Sass/JavaScript variables from JSON files.
CTI
Style Dictionary advocates the CTI classification, that is Category -> Type -> Item.
However this project does not make use of that since it doesn't match a typical mental model and the structure can be quite rigid. For example when working with components it is easier to think about them like this:
- button-padding-size: ...
- button-font-size: ...
- button-font-color-primary: ...
- button-font-color-secondary: ...
- button-background-primary: ...
- button-background-secondary: ...Then this way (CTI):
- size-padding-button: ...
- size-font-button: ...
- color-font-button-primary: ...
- color-font-button-secondary: ...
- color-background-button-primary: ...
- color-background-button-secondary: ...Build Config
We have the build.js script which is responsible for generating the tokens. You'll see we currently target 3 platforms - web/js for JavaScript tokens (aka for CSS-in-JS), web/scss for Sass and styleguide. Styleguide is meant to be consumed by an application showing how all the tokens can be consumed, similar to how Salesforce does it. We don't have anything yet but please feel free to reach out if you'd like to help!
Contributing
So you'd like to help out - great! Work with myself (Viral Ganatra) and LeNam to add new variables. We'd like to create variables for each of our components (Modals, Buttons, Form Inputs etc) which can then eventually be consumed by applications and more importantly a UI Library! 👏
The Future
Today we have to update the JSON files manually, we should investigate a way to automate this process. Eventually the workflow could be a designer update their document in the design tool and then this triggers an update of the tokens stored here automagically! 🔮