Re: [community-group] [RFC] Design Token Editors (#36)

FWIW, for design system projects I've worked on it's (initially) copy-pasta too. Some tools like InVision DSM can extract _some_ token values from Sketch symbols (seems to just be colors & typography styles for now, not spacing amounts as far as I'm aware) and export them in formats suitable for direct inclusion into code. But they're still a bit basic compared to what you can express in code.

Ultimately though, I think different design system teams will always use a variety of approaches. Many may start in design tools (in which case that's a logical starting point for generating your initial design tokens), but others may start with code. Some may not even have both - maintaining shared design assets suffices for some and likewise only having code works for others.

A bit like @NateBaldwinDesign, my hope for the format we will define is that it becomes an interchange format that many tools can read and/or write. Hopefully, UI design tools will one day be able to read and write design token files, so it doesn't really matter which way round your process goes.

I think dedicated design token editors like you propose would be a great addition to our tooling eco system. I can imagine other kinds of tools might emerge too: Imagine having tools to analyse your tokens in various ways (give you stats similar to CSS Stats, maybe flag when your tokens are becoming overly complex and suggest simplifications, etc.). Or to test/lint them (e.g. flagging non-accessible colour pairings, font sizes that are too small, etc.).

I also hope that tools that specialise only on certain types of tokens will adopt the format. E.g. tools for creating or editing colour palettes like Lyft's ColorBox or Adobe Color should be able to load a token file and read/edit/save only the colour values and ignore the rest (💡  Hmm.. maybe our spec ought to require implementations to leave token data they don't understand unchanged?). Similarly, other tools might focus on just typographic values or sizes.

I sincerely hope that if we succeed in defining a common file format that gets widely adopted, it'll give rise to all kinds of new tools because people won't be wasting time (re-)inventing their wo proprietary design token file formats and can instead focus their efforts on doing valuable things with the tokens.

Take JPEG images for example: Virtually every digital camera can produce them, every gallery app and web browser can display them and pretty much any image manipulation software can read and write them. Other niche tools also exist, for example to edit the metadata or optimise the compression. They all "just work" because JPG is a standardised file format. I hope that what we define here will be like that but for design tokens. :-)

-- 
GitHub Notification of comment by c1rrus
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/36#issuecomment-576462490 using your GitHub account

Received on Monday, 20 January 2020 23:46:49 UTC