Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design Token-Based UI Architecture

martinfowler.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Design Token-Based UI Architecture

#111

Post by have_faith »

motorest wrote: post #104
aridiculous wrote: post #86

Seems like a lot of the comments are not getting it. The purpose of tokens is be able to have a single language-agnostic source of truth for the core bits of the design decisions. Let's say you have a website, an iOS app, an Android app, Figma templates, and documentation. Let's also say your main brand color is currently a certain shade of green. When your brand evolves to a different shade of green, you update one…

> This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows. Perhaps I'm missing something, but Bootstrap does support this, doesn't it? https://getbootstrap.com/docs/5.2/customize/css-variables/ Please explain why you feel this usecase hasn't already been supported for years. Also, other to…

The point of design tokens is that they sit above your framework and library choices, so it's not possible for bootstrap to solve this as it's a down-stream library. Bootstrap is a consumer of design tokens in that they might be fed into bootstraps css variable system. But in a design token system you wouldn't use bootstrap as a source of truth for these tokens, you want something more flexible and programatically portable than CSS.

Re: Design Token-Based UI Architecture

#112

Post by kaelig »

yakshaving_jgt wrote: post #103
kaelig wrote: post #101

Earlier quoted context omitted.

Joke aside, there are truly valid reasons why you'd want to change a single color across dozens of codebases, for what can amount to tens of thousands of occurrences. For example: adjusting link color contrast for accessibility compliance. Salesforce (where the term "design tokens" was coined) is akin to an operating system for the web, with its own app ecosystem. Developers building Salesforce apps can blend into th…

Fortunately, computers are already really good at finding and replacing strings.

You can try automating search/replace on hex/hsl/rgb values across all your codebases, but targeting "primary button backgrounds on hover" is only possible with some more advanced tooling in place.

And there's an important runtime aspect when it comes to theming, so it's not just about finding/replacing hardcoded values.

Re: Design Token-Based UI Architecture

#113

Post by kaelig »

motorest wrote: post #104
aridiculous wrote: post #86

Seems like a lot of the comments are not getting it. The purpose of tokens is be able to have a single language-agnostic source of truth for the core bits of the design decisions. Let's say you have a website, an iOS app, an Android app, Figma templates, and documentation. Let's also say your main brand color is currently a certain shade of green. When your brand evolves to a different shade of green, you update one…

> This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows. Perhaps I'm missing something, but Bootstrap does support this, doesn't it? https://getbootstrap.com/docs/5.2/customize/css-variables/ Please explain why you feel this usecase hasn't already been supported for years. Also, other to…

Bootstrap and Sass are for the web. They don't solve the interop problem for Figma/Sketch/Framer/iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars and what have you.

And that's not even accounting for web styling solutions that don't use CSS variables.

Re: Design Token-Based UI Architecture

#114

Post by hombre_fatal »

rendaw wrote: post #49
kaelig wrote: post #26

Earlier quoted context omitted.

Yes to everything you say, except for "option/decision/component" as that's up to the users. The spec is acting just like how CSS doesn't tell you how to name and nest classes.

Why call it tokens instead of variables?

New jargon lets you avoid overloading existing terms and it adds specificity.

When someone says design token, you know they're talking about this. They don't have to say "variables" or "constants" + extra explanation that narrows the reference to the TFA concept every time they want to refer to the concept.

We do this so often in programming that you take it for granted. You're using dozens of words that weren't used 10 years ago.

Hydration is a good example of one of those words in the webdev space.

Re: Design Token-Based UI Architecture

#115

Post by [deleted] »

kaelig wrote: post #101
Joker_vD wrote: post #100

Earlier quoted context omitted.

> When your brand evolves to a different shade of green This is such a funny line to read. I just can't help but imagine a brand like a small bulbasaur that evolves into big, strong venosaur which of course involves changing its shade of green. > An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?" An even more interesting question would be "if…

Joke aside, there are truly valid reasons why you'd want to change a single color across dozens of codebases, for what can amount to tens of thousands of occurrences. For example: adjusting link color contrast for accessibility compliance. Salesforce (where the term "design tokens" was coined) is akin to an operating system for the web, with its own app ecosystem. Developers building Salesforce apps can blend into th…

[deleted]

Re: Design Token-Based UI Architecture

#116

Post by kaelig »

groby_b wrote: post #108
aridiculous wrote: post #86

Seems like a lot of the comments are not getting it. The purpose of tokens is be able to have a single language-agnostic source of truth for the core bits of the design decisions. Let's say you have a website, an iOS app, an Android app, Figma templates, and documentation. Let's also say your main brand color is currently a certain shade of green. When your brand evolves to a different shade of green, you update one…

> This is an organizational tool that increases in value as a multi-platform company grows. That sounds impressive enough for the UX sales presentation. Meanwhile, how is it any different from "don't just use numbers, use an agreed-upon set of constants"? > When your brand evolves to a different shade of green, you update one value in one place. All of the above surfaces are updated at the same time. Awesome. And I a…

It's not too different, as the concept was heavily influenced by localization libraries.

That said they're not always constants. A design token can mutate based on device, light/dark/high-contrast mode, viewport size, user preference, locale, brand, product, theme, etc. This mutation can apply at runtime or at build time depending on the use-case.

Re: Design Token-Based UI Architecture

#117

Post by motorest »

kaelig wrote: post #113
motorest wrote: post #104

Earlier quoted context omitted.

> This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows. Perhaps I'm missing something, but Bootstrap does support this, doesn't it? https://getbootstrap.com/docs/5.2/customize/css-variables/ Please explain why you feel this usecase hasn't already been supported for years. Also, other to…

Bootstrap and Sass are for the web. They don't solve the interop problem for Figma/Sketch/Framer/iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars and what have you. And that's not even accounting for web styling solutions that don't use CSS variables.

> Bootstrap and Sass are for the web.

Cool, so we establish that the likes of Bootstrap and Sass already solve this problem for the web.

> They don't solve the interop problem for Figma/Sketch/Framer

That's irrelevant, isn't it? I mean, do you run apps straight out of Sigma/Sketch/Framer? Do you also think it's reasonable to call out Photoshop/Gimp/MSPaint?

> iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars

You're trying to refer to platforms/OSes, aren't you? Do you think it makes any sense to bundle everything together? Those who work on iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars would certainly look at you perplexed just for suggesting that specifying color schemes even registers as a concern in the whole cross-platform discussion.

>

Re: Design Token-Based UI Architecture

#118

Post by rendaw »

seanhunter wrote: post #110
meiraleal wrote: post #107

Earlier quoted context omitted.

because they are constants, not really variables?

Why not call them constants then? Tokens is a really terrible name given the strong expectation that anyone with a computer science background has around the meaning of "token".

Yeah... auth tokens, resource tokens, rate limiting tokens, monetary tokens, LLM tokens, parser tokens, etc... you might as well name it "thing". It's about as bad as "node".

Re: Design Token-Based UI Architecture

#119

Post by braden-lk »

Design-first thinking with tokens is a game-changer for an org building a product that needs to adapt to multiple clients. It's still useful for a singularly-branded product just for separation-of-concerns reasons, but maybe less useful.

Design tokens aren't concerned with implementation. (CSS vars, constants, etc.). Design tokens are an abstraction for standardizing and communicating the values in your design system, regardless of where they show up. Yes, you might implement your design tokens as CSS variables, but not necessarily.

Re: Design Token-Based UI Architecture

#120

Post by bmelton »

kaelig wrote: post #109
motorest wrote: post #102

Earlier quoted context omitted.

I'm sorry, you wrote words but they don't say anything. They sound like machine-generated nonsense. Can you actually provide a concrete example of a concrete problem you want to solve with the token-based UI initiative? Write your answer following the STAR format, and leave the buzzword bingo out. If you cannot explain your problem then this is a very clear tell that it might not exist at all.

> They sound like machine-generated nonsense. Fair! Perhaps I should have used an LLM to de-bullshitify my message... Let's walk through a common scenario: Design tool A has brand colors coded in hexadecimal, those have no name, they're just hex values. Design tool B has colors named in CamelCase, values in HSL. Codebases A, B, C have colors in RGB, named the same as in Design Tool B. Codebase D has colors in Hex8, w…

Great answer. In your scenarios, let's say OrangeCorp has their 'brand-orange' color token. They've defined it as the hexadecimal `#FFA500`.

Engineer Bob implements it as `hsl(39, 100%, 50%)` in a web project because the loading state requires shifting the color values, and he has a library that works with HSL but doesn't work hex.

What do you store for the source of truth? Are we just storing the hex value, and deriving translations from that? Or are we storing 'brand-orange' with a map of "hex: FFA500" and "HSL: 39, 100, 50"? Does the specification have an opinion?

Post reply on HN