Re: [community-group] [RFC] Theming (#2)

Hi there 👋 !  I'm particularly interested in the issue of theming and token authoring. This is one problem that is seemingly simple but can become incredibly complex. There are a few thoughts that I have regarding this issue:

1. Definition of "Theme"
2. Abstracting contexts for token flexibility
2. Philosophical use of overrides
3. Token definition vs. tooling

**Definition of "Theme"**
I believe some clear definitions may be helpful prior to having deeper discussion into theming. For some folks, "theme" refers to the color palette used. For others, a "theme" refers to the entirety of the design language itself (think parent companies that have vastly different brands using the same core components).

There's value in recognizing that for each type of token a user defines (color, spacing, typography, etc), there is the possibility of having relative "themes"; essentially just different contexts that can be applied to a design language (as mentioned by @mkeftz regarding complexity of brand 'themes' above).

I believe the original comments of this thread assume "theme" to relate to "color themes". If that is the case, I would recommend using that language with the assumption that there may also be "scale themes", or "typographic themes" which designers may combine into unique design languages.

The rest of my comments are under the umbrella of "color themes"

**Abstracting contexts for token flexibility**
What @ddamato illustrates above is exactly where I believe there's value in approaching the issue of themes. There should be abstractions in tokens that allow for *global context* (such as color palettes), *relative context* (such as semantically aliasing tokens to common uses), *shared contexts* (such as common groups of tokens that are represented in multiple different components) and *explicit context* (such as defining a button's tokens for a button only). Although the shared contexts layer is not always needed depending on implementation.

Global context (at least for Adobe's design system Spectrum) is where users define the hard values that they wish to use. This has been tremendously helpful in allowing us to combine color theme and scale independently. Users can define *only* the color values for each theme in separate files, thus allowing contextual and explicit aliases to only be written once. ie:
```
// light.js
   'gray-100': 'rgb(245, 245, 245)';

// dark.js
   'gray-100': 'rgb(50, 50, 50)';

// colorAliases.js
   'background-color-default': 'gray-100'

// sideNavigation.js
   'background-color: 'background-color-default'
```
Explicitness in errors (such as "Dark.js does not have token 'gray-100'") is fine in my opinion. It helps designers to ensure there's parity in the applied philosophy behind their design system, even though it is bound to them in some ways. Although this can be mitigated. For example, if we don't have gray-100 in dark.js, you should be able to specify in the alias layer what you would like instead. For example:
```
// colorAliases.js
   'background-color-default': {
        'light': 'gray-100',
        'dark': 'some-other-color'
    }
```

 **Philosophical use of overrides**
Regarding the discussion on overrides for themes, it comes down to the question of what is a default for any given thing? The idea of a color palette having a "default value" is very unusual and will result in very bizarre outputs that will create confusion for designers -- especially if some themes have colors that are very similar to the "default" (design may overlook or not even see that there is an error).

Overriding makes sense when there is a *sensible* default, such as default states of a component. The notion of overrides in terms of defining state-related color changes, or variant-related color changes is 100% appropriate. 

But when it comes to global-level tokens, I'm in the camp of throwing an error. Theming (for both color and all other types of theming) can become very complex, and "defaulting" to a particular value could be more problematic than just throwing an error. For example, Brand A has a theme that is overridden by Brand B. Brand A is vibrant in color, and Brand B is a more muted B2B theme. If a color token defaults to the vibrant Brand A color rather than throwing an error, the result would be highly undesirable. 

**Token definitions vs Tooling**
I believe token standardization can happen agnostic of tooling. Tools can be built to do any number of things, and the standard should not be predisposed to assumptions about problems a tool may have to solve. Relativity in tokens is a must-have in my opinion. Many platforms support relative values, and their use in a design system is tremendously beneficial. Many (if not most/all) design decisions made by systems designers revolve around relativity... so even when a designer says "give this item 32px height", sometimes what they're really saying is "this item has the same height as the base type line height". 

If tokens can be defined as relationships (wherever needed), that will help designers to codify the  gestalt of their design aesthetic into every detail of their system in a much more manageable way.

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

Received on Thursday, 5 September 2019 19:11:08 UTC