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

61–70 of 143 posts

Re: Design Token-Based UI Architecture

#61

Post by jastuk »

kaelig wrote: post #14

Hi, I'm the founder of the Design Tokens W3C Community Group, we are writing a spec to help with interop across design and developer tooling [1] There's a whole movement bringing DevOps and SRE thinking to design/UX, essentially working on design infrastructure. Design Tokens are a part of it. Ask me anything — this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more. 1: https://t…

I was super happy learning about design tokens a couple of years back, and eager to use them, but since then my enthusiasm fell as it seemed to "never get there". Figma implemented something which is okay-ish, but completely useless for our needs, while Penpot announced their collab efforts and then radio silence for roughly 2 years now.

I could be out of the loop a bit, but I see that this spec is also still a draft. As somone who'd love to evangelize and implement design tokens internally, when do you see this stepping into the spotlight in a meaningful way? Is there a roadmap of some kind that's available to the public?

Re: Design Token-Based UI Architecture

#62

Post by MrMcCall »

svachalek wrote: post #2

It seems like there are some good ideas in here but the terminology is utterly alien to me. Not sure if it's me or this is just deeply wrapped in consulting jargon.

What they are calling "tokens" are just their design elements.

They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.

This is a fancy way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them into the entire system, as needed, at the latest possible point the actual values are needed.

It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake.

Re: Design Token-Based UI Architecture

#63

Post by s2l »

kaelig wrote: post #30
starbugs wrote: post #29

Earlier quoted context omitted.

> At a certain scale, design and brand teams need infrastructure to drive change What does this mean? Do you have a concrete example of where this actually solves a real problem? And what problem would that be?

Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent. Now imagine rolling out dark mo…

> or perhaps a brand refresh.

Doesn't brand refresh often includes new components and new design language? In creative space, every design agency tries to sell something different to the organization and thus brand refresh will discontinue any prior design tokens and come up with new one.

Re: Design Token-Based UI Architecture

#64

Post by MrMcCall »

This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element".

Here is my slightly edited comment from below:

What they are calling "tokens" are just their design elements.

They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.

This is a fancy (but seemingly excellent) way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them throughout the entire system, as needed, at the latest possible point the actual values are needed.

It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake of nomenclature.

Re: Design Token-Based UI Architecture

#66

Post by einsty »

MrMcCall wrote: post #64

This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element". Here is my slightly edited comment from below: What they are calling "tokens" are just their design elements. They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before dep…

I think the term token had been used in some UI products for quite a while now. The first time I heard it felt a little awkward but it is really quite natural now.

Re: Design Token-Based UI Architecture

#67

Post by strogonoff »

MrMcCall wrote: post #64

This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element". Here is my slightly edited comment from below: What they are calling "tokens" are just their design elements. They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before dep…

“Design token” is an accepted and widely used term (see Amazon’s Style Dictionary, Adobe’s Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike “design element”, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as “token” rather than “element”.

(The term “variable” may be more fitting, but it is on the other hand too generic and conflicting with a different idea in implementation domain: CSS or JS variables can mean the same thing, but not always.)

[0] https://github.com/design-tokens/community-group

Re: Design Token-Based UI Architecture

#68

Post by MrMcCall »

einsty wrote: post #66
MrMcCall wrote: post #64

This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element". Here is my slightly edited comment from below: What they are calling "tokens" are just their design elements. They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before dep…

I think the term token had been used in some UI products for quite a while now. The first time I heard it felt a little awkward but it is really quite natural now.

Thanks. That's not my workspace, so it makes sense that I would be unaware of it, my just being a programmer.

Re: Design Token-Based UI Architecture

#69

Post by MrMcCall »

strogonoff wrote: post #67
MrMcCall wrote: post #64

This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element". Here is my slightly edited comment from below: What they are calling "tokens" are just their design elements. They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before dep…

“Design token” is an accepted and widely used term (see Amazon’s Style Dictionary, Adobe’s Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike “design element”, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as “token” rather than “element”. (The term “variable” may be more fitting, but it is on the other hand too generic and c…

Thanks. That makes sense, even if my old-school brain finds the term less than optimal.

Re: Design Token-Based UI Architecture

#70

Post by whoisstan »

This makes sense to me, but it seems to contrary to the current utility-based css wave. For example 'text-red-100' for error message text wouldn't be in style dictionary like that, it would be 'text-color-error' since using 'text-red-100' would always be red 100 and not able to change the text-yellow-500.

Point being isn't that a route back to semantic styling? I much prefer the maintainability cycles of semantic styling over the onslaught of classes in i.e. tailwind.

Post reply on HN