Re: [community-group] Native modes and theming support (#210)

A few points from @gossi's post.

Shared language is definitely an area of improvement here. I think of a theme as a collection of semantic token and value pairs. Then that theme is like a cassette tape which provides a mood which can be swapped out to provide different moods. In a way, if I'm in a sad mood, it'll be very hard to make happy music. Same goes for theme curation and thinking in terms of the light theme as a complete unit of work apart from other themes. This is where the idea of context comes in. Context is thinking about a certain mood specifically. Context switching happens when I'm trying to think about light and dark near-simultaneously and where mistakes will occur.

> For that a theme first must mention its capabilities in terms of features and scopes

This is where I think we're going to have the most trouble. As an example, I'm not sure how this might support changes for locale (eg., black colored buttons do not perform well in China, so we have to support a different colored button in this context)[^1]. There's going to be other considerations here past ones the token designer might maintain. Experimentation comes to mind here which is often either marketing or product driven. This is why I'm not confident that the tokens specification should hold the explicit conditional as a schema. I think of it more as a human-readable field.

```json5
// default-zh-CN.json
{
  "$description": "Changes made for the zh-CN market",
  "$tokens": {
    "intent-action-base-background": {}
  }
}
```

This is because the way that we trigger when these tokens should be used will differ between platforms or organizational resources.

However, if the human-readable field is too freeform, I think the task is then _how do we encode the purpose for this specific theme into a well-defined schema?_ Keeping in mind that it'll be near impossible to identify all the reasons one might want to create a theme. Something like an array of `$tags` (or another name `$categorization`, `$purpose`, `$context`?) might work here for systems to have their own way of categorization (as the categorization of themes is also highly influenced by the people using them).  Requests for a theme would search against all the themes with a given set of tags and find the best match. An enhancement to `$tags` could set a priority to the field showing that finding the correct market is a higher priority than finding the correct contrast theme.

```json5
// zh-CN-high-contrast.json
{
 "$tags": [{
    "$type": "market",
    "$value": "zh-CN",
    "$priority": 1
  }, {
    "$type": "contrast",
    "$value": "high",
    "$priority": 2
  }],
  "$tokens": { ... }
}
```

You could also adjust this as an object like `$tokens` so there are tokens that represent the theme categorization itself (how meta).

```json5
// zh-CN-high-contrast.json
{
  "$tags": {
    "zh-CN-market": {
      "$type": "market",
      "$value": "zh-CN",
      "$priority": 1
    }
  },
  "$tokens": { ... }
}
```

Though I'm not sure what the benefit of providing a token-like construction for this would be. As mentioned above, I imagine systems would loop through the `$tags` to identify the best match and return the `$tokens` from that.

[^1]: This also opens up the possibility of theme inheritance; the ability to use one theme as a base and update a subset of semantic tokens with new values. In practice I shouldn't need to copy _all_ of the values from the base theme and then change one value for the zh-CN market. We should have a solution (if one doesn't exist yet) to show that one theme can extend from another. Admittedly, having all the values in one file is a solution but I'm hoping for a way which reduces the context. In other words, it's less intimidating to make a zh-CN change in a file with only a few tokens, than one that has _all the tokens_.

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


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

Received on Friday, 14 April 2023 23:39:10 UTC