- From: James Nash via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Oct 2019 16:49:06 +0000
- To: public-design-tokens-log@w3.org
I certainly agree that my interfaces proposal is out of scope for an initial version of our design token file format spec. However, since this thread is discussing possible approaches to support theming use-cases, I do think it's worth considering and debating that proposal as a possible approach to work towards in future spec versions. Re-reading this thread and the other approaches being proposed, I wonder if people have _slightly_ different mental models / approaches of how to use and organize design tokens. So, to try and disambiguate, allow me to explain how _I_ think of them. I'd be really interested to hear where others here have differing ideas / approaches / terminology. I think most here will agree with the basic definition from [SalesForce Lightning](https://www.lightningdesignsystem.com/design-tokens/): >Design tokens [...] are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development. In my mind, a basic use of design tokens, with a few colors and lengths being _directly_ applied to UI elements could be visualised like this:  In practice though, most design systems define some intermediate abstraction layer(s). These will often use more semantic names that try to describe the _intent_ of the token. However, to keep things DRY, those may ultimately reference other tokens with explicit values. I quite like [the names Nathan Curtis uses for these 2 groups](https://medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421) of design tokens: **Options** (the named values) and **Choices** (the aliases that represent the _choice_ of using a particular value for some purpose). Extending my little example with this concept, you might have something like this:  As systems grow in complexity, teams may introduce additional layers of abstraction within the _choice_ design tokens. If I understood @NateBaldwinDesign's [earlier comment](https://github.com/design-tokens/community-group/issues/2#issuecomment-528536749) correctly, this is what he was alluding to (and please do correct me if I misunderstood!). Using his terminology, I'd say _global context_ is the similar to Nathan Curtis' _options_. Then, _relative contexts_, _shared contexts_ and _explicit contexts_ are perhaps sub-divisions of the _choices_. So, extending my example with an extra layer of abstraction might yield something like this:  Based on what I've read and my own hands-on experience, I think the decisions around what breadth of _choice_ design tokens to have, what to call them and how many layers of abstraction to have are all bespoke to each design system. Getting this right is _hard_ and, I suspect, most design systems will need to iterate and evolve the relationships they model via their _choice_ design tokens over time. For that reason, I don't think anything the DTCG defines should prescribe a particular structure or naming convention to users. I see our job as defining a format that _enables_ users to make token hierarchies as flat or deep as they like. _But_, at the same time, what we come up with also needs to facilitate interoperability (otherwise, what's the point) so that tools can operate on arbitrary design token files in a meaningful way, or use such files to exchange design token data between them. That's why I believe that references (or "aliases", if you prefer), typing for token values and as little constraints as possible on how tokens are organised within a design token file are important features. References are the means by which we enable people to express _choices_. Types are the means by which we let tools operate on arbitrary design token files (since they can differentiate between, say, a color value and a font name regardless of what those tokens are named or how they are categorised). Finally, being un-opinionated about how tokens are grouped or organised within a design token file (or perhaps even across multiple files) mean we don't constrain design system teams. So that's how I see tokens and how I _think_ people use them. Hopefully, the format we define over in issue #1 will support all of the above somehow. If people here have different mental models or views on any of this, I'd love to hear them. Firstly, it's fascinating. Secondly, we will eventually need to form some kind of consensus around this. ### Theming Moving on to the topic of _this_ thread, my understanding of the broader "theming" problem we want to solve is this: A design system may need a means to vary its token values. There can be many reasons for these variations - and combinations of them may well be needed (which can result in a large number of possible permutations): * Platforms: E.g. adjusting certain values to better fit into particular OS * Colors modes: E.g. OS light & dark modes, high contrast mode, etc. * Information density: E.g. sparse, compact, ... * Multiple brands: Brand A, Brand B, ... * etc. My reading of the initial approach @kaelig suggested at the start of this thread was to have a base file with your default design token values and then one or more override files that get layered on and alter the values of some tokens. Subsequent comments have refined this, but that basic idea remains. I see my interface proposal as an alternative to that (although not necessarily an mutually exclusive one). My feeling is that defining explicit interfaces gives a means to authors to express which of their tokens are _intended_ to have their values be tweaked (almost like a public API) and which are considered "internal" to that design system. That in turns could also enable tools to expose or manipulate those tokens in a helpful way. For instance a design system may wish to enforce that links and buttons always have the same colour, but want that shared color to be something that is themeable. Extending my example diagram once again, here's an illustration of the interface approach:   (If my previous comment was confusing, hopefully this clears things up a bit!) In this case I'm just showing a single interface with 2 possible implementations. However, you could define as many interfaces as you like. They can be as high or low in abstraction as you like and could be interconnected. In the interest of not being too opinionated, it would up to each design system to decide how many interfaces it wants to expose and at which level(s) of abstraction they are. Or indeed, if it wants to use interfaces at all. :-) Coming back to the original theming challenge, I feel this approach _does_ is a potential solution: * An interface could expose all the slots that need color values assigned to them in order to color in UI elements. Differing implementations could the fill in color values for light and dark themes, high and low contrast themes, etc. * An interface could expose a minimal set of slots for length values that will be used throughout the UI for paddings and margins. Differing implementations could then fill in different sets of values to create dense or sparse UI layouts. * A large interface could expose all the things the system considers configurable. Differing implementations could then set all those values to re-skin the entire UI for different brands. (If you think about it, [the SASS vars that Bootstrap provides for theming](https://getbootstrap.com/docs/4.3/getting-started/theming/) are essentially such an interface!) So yeah, I feel this proposal _is_ in scope for this discussion :-D Whether or not y'all like is another matter of course. Please go ahead and scrutinise it thoroughly. I'm sure there are gaps and issues I haven't considered. -- GitHub Notification of comment by c1rrus Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/2#issuecomment-537125174 using your GitHub account
Received on Tuesday, 1 October 2019 16:49:08 UTC