Theme Architecture: Switching

[pjrundle]

🪨 Static theme settings tokens

Most elements of a theme settings object are "static" tokens. I.e:

• heading font family
• heading letter spacing
• button radius style
• footer color mode
• header color mode
• etc etc etc

These tokens are consistent and present across all/any theme settings object, so we can rely on them being there when switching between themes.

👩‍🎨 Dynamic theme settings tokens

However, recently I’ve been experimenting with "dynamic" theme tokens.

For instance, theme A might have/need two brand colors, whereas theme B might need 5/whatever brand colors.

Theme A might need gradients, theme B might not.

An example of where this currently problematic: You've built a page, and some of the blocks are using a color/gradient from theme A. When you switch the theme B, these values do not exist.

---

Solution 1 - Only static tokens

• don't even have dynamic theme setting tokens
• all tokens are defined and must be set by theme creators
• this would mean defining more colors, gradient tokens than most themes would need, and they would sit there dormant

Pros:

• simple
• could possibly enforce sensible use of color (i.e not having 1 million colors like brandwatch)
• possibly means switching themes will be more effective
• very structured - might enforce a design schema
• reliable, repeatable, consistent for any site/theme
• no need for parent child theme relationships

Cons:

• schema/tokens will need very careful thought
• unused design tokens
• until optimised delivers a lot of dead code
• would require some probably quite weird UX to make style guide page work (i.e hiding things that aren't relevant to xyz theme)
• design tokens irrelevant to XYZ theme would appear in dropdowns, pickers etc unless dealt with
• less powerful?
• might feel less like a design tool
• possibly less scalable - if we have architecture to accommodate dynamic tokens it could be easier to maintain?

Solution 2 - Gracefully handle non-existent tokens - flag non existent tokens

• flag in the block builder UI that XYZ token does not exist for theme B.
• web block (for example) background color will be "unset" (className/style has no value)

Pros:

• kind of simple
• possibly expected behaviour?

Cons:

• poor UX?
• makes switching themes kinda pointless?
• pages can and probably will look broken when switching themes

Solution 2.5 - Gracefully handle non-existent tokens - fallback to defaults

• "Can’t the sections without a corresponding token revert to a standard setting? For example a white background if it’s a light theme or black if it’s dark?"
• would need to check if tokens do not exist and then find next best option/default

Solution 3 - Theme specific block settings

• blocks get some theme specific props: i.e { heading: "My heading", ..., theme: { theme_abc: { background_color: 'theme_abc_bg_1'}}}

Pros:

• when switching between themes, there would be no "breakages" - UI would remember settings, web render wouldn't be broken etc
• any method other than this means theme switching isn't as useful
• truest method in terms of design/content separation - colors etc belong to themes not content
• powerful as a design tool - theme switching is more useful
• works with Pete‘s mental model
• this type functionality isn't even available in raw code

Cons:

• more complicated
• options would need to be "set"
• dissimilar to flat consistent block props design which seems to be working very well
• blocks would/could carry "dead" code that's not used
• potential confusion UX wise to get across what's happening? I think it would be ok but it is how my mental model works.
• what happens when you duplicate a theme?
• does this mean we need parent/child relationship for themes to address the above?

Solution 4 - One theme per site

• completely do away with switchable themes
• each site has one theme and that's it
• realistically, do people switch themes anyway? They're likely to have one theme and that's it. - Unless we make it actually useful to switch themes.

---

💡 Thought immediately after writing this. Unless we make switching themes genuinely useful/powerful, then is having switchable themes actually useful?

---

Some possible utilities of switching themes

• a powerful design tool - not available anywhere else
• brand updates and redesigns
• pitching brand/design options, agency setting etc

[bhallstein]

Solution 2 - Gracefully handle non-existent tokens - flag non existent tokens

• flag in the block builder UI that XYZ token does not exist for theme B.
• web block (for example) background color will be "unset" (className/style has no value)

Or perhaps set to a grayscale 'stub' color/gradient. (or a spectacularly lurid one? see clearcolor in video games)

I can imagine in the theme editor in the colour token panel we could display to the user all the tokens currently in use on the site that do not have values as a kind of 'unset color' control, and let them set one. This could provide an efficient workflow for making a new theme and quickly building out the set of required tokens for that theme based on the tokens that exist in the current site.

(this is sort of like a solution 2.6 🤣)

[bhallstein]

Solution 4 - One theme per site

IMO they need multiple themes so they can experiment and most of all have the freedom to screw up. I still see the decoupling of content from design as a core tenet for Wom.

[bhallstein]

Solution 3 - Theme specific block settings

For me the main question mark over this is whether there a UX solution is even possible that does "for this block, if the theme is X, use these settings, if Y, use these other settings, if other, fall back to original settings"*. I do have some ideas, be interesting to talk over/sketch some ideas. Also interested if we can point to anything like this type of UI problem exists in any other problem domain, however remotely similar.

* (and also, in this other non dynamic property mode, don't do any of this 🤣)

what happens when you duplicate a theme? does this mean we need parent/child relationship for themes to address the above?

Lots to think through on this on a technical level as previously discussed, but in general my feeling is a parent-child relationship would be a coding nightmare.

[bhallstein]

Related: #112 (brand-versioned assets)