Multi-dimensional Themes

[six7]

Our current Themes concept is 1-dimensional, but this fails when trying to split up color themes from brand themes. It also fails when users have to attach Type styles to color themes, given they can only have 1 active theme at a time (imagine Dark theme and typography from Brand A).

Let's break this up and make it multi-dimensional. Users could create groups where themes live. Users could have a group for Platform, one for Color modes, one for Typography modes.

Current:

Dark
Light

Proposed:

Color/Dark
Color/Light
Type/BrandA
Type/BrandB
Platform/Android
Platform/iOS

Architecture

We could let users create these groups in the UI, or just add the mode property in code itself.

New structure:

  {
    "id": "003c77e089903a48c6ab1d0c8a77af9b66d5257c",
    "name": "dark",
+   "group": "color",
    "selectedTokenSets": {
       "theme/dark": "enabled",
      "semantic/colors": "enabled",
      "base/core": "source",
      "semantic/shadows": "enabled"
    },
    "$figmaStyleReferences": {
      …
    }
  }

We'd then group all themes under their group name in the UI, both in Manage themes and Theme switch dropdown:

The Manage Themes modal itself would also get Groups added:

Implications

• When users have multiple themes active (max. 1 per group), we'd again combine all tokens that result from the sets active.
• When users have groups where themes have the same token sets active inside, the latter one wins (eg if I have a dark theme active in group color, and have the high contrast theme active that changes all borders to a higher contrast color, then I'd expect to see the high contrast colors "win", not the dark theme colors).

[onurorhon]

This is great.

As the theme feature gets more robust with multi-dimensional, the word “theme” is starting to feel very limited. Something generic, like “Mode” or “scheme” makes much more sense to me when it comes to breakpoints or other non-color modes. Users can still name their groups as “Color Theme” etc for context.

[mikejyoung]

I agree "Theme" can create the wrong impression. At first, I though of the feature only in terms of setting up tokens for specific looks such as light/dark or by brand. I presumed deleting themes would be a destructive action. It took me a while to realize I was just simulating certain configurations, which then I was able to use the feature to it's full potential.

My recommendation would be using the term "Environment", as that feels congruent with the purpose of the feature (especially when implementing these improvements). Effectively, you are enabling certain tokens sets to simulate the production environment.

[onurorhon]

I was thinking it should be more high level. I remember @six7 referring to sets as "just files”, so maybe we can also think of these entities as collections or composition of files.

For me, “token compositions” captures the spirit. And maybe manage themes becomes “Token Composer”. Here's what the menu could look like in this paradigm: