Re: [community-group] Conditional token values (#169)

> Using `$extensions` for this use case is discouraged by the spec. It should be solved with multiple files or in the spec itself.

Very fair point. 

> > At my last company I put together something similar to the $conditionalValues @romainmenke is proposing above, to solve for nearly the same requirements (if not an identical solution, the same in spirit). It required a great deal of additional complexity in our token translator, and all formatters had to accommodate these mystery box tokens.
> 
> @jeromefarnum Forgot to ask, but did this work well once the tooling was there to support it?

@romainmenke let me try to answer this in short, and also with more detail should it help others. 

TLDR; it worked well enough in the areas of our workflows where we implemented it, however as we didn’t have it implemented fully in our design tools it became a source of confusion and human error. Our team started with many conditional values as we initially built our design system, but over time greatly reduced the number of conditional tokens as the cost of system complexity wasn’t returned in added value (design systems have a natural inertia towards this, I think). At the time of my departure we were in the process of fully stripping out these conditional tokens in favor of a file swapping approach to handle the relatively few conditional tokens we had. 

—

Functionally, after doing all the work to implement the feature, it worked well enough in the token translator. Though the additional complexity did make adding some features later more difficult.

We also had to add support for the feature to our token documentation site so designers could understand that SOME tokens had different values under SOME conditions. Frankly, as the person that was responsible for the token documentation site, I think how I communicated that wasn’t as successful as it should have been. We regularly had designers getting confused as to which value should be used for a token. 

Part of the problem was that we didn’t have a proper plugin to connect our tokens to our design tools; or more precisely our plugin was in beta and wasn’t feature complete enough for our team to daily drive it. IIRC these responsive tokens were one of the more complex features to add to the plugin, where many of the other features were completed but this feature was one of a small set that was causing the plugin development to stretch out.

One aspect that made it challenging to implement in design tools was that we initially thought to use the artboard size to determine which conditional value to use, but we discovered that a large portion of the time tokens where being used was in component masters (pretty sensible) which nearly always used arbitrary artboard sizes. In those cases the token value that was selected due to artboard size was often not as desired; requiring the designer to manually configure which condition to use for the artboard.

In the end designers needed to intervene so often to select which conditional values should be used, IMO, it’s simply easier to use a file swapping method, use whatever complex conditional logic to swap files as needed and generate as many themes as needed at the token-translator stage to provide designers with the appropriate options they need (probably a matrix of light/dark and device/platforms covers the large majority of teams.) This approach likely covers most teams’ needs without having to clutter the specification or adding undue complexity for tooling builders. 

/rant 

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 20 September 2022 05:04:02 UTC