kaelig

7 ms·

1.
Building design system components with agent teams(kaelig.fr)
2 points by kaelig 5mo ago|0 comments
2.
Penpot (open-source Figma alternative) AI whitepaper(penpot.app)
1 points by kaelig 1y ago|0 comments
3.
by kaelig 2y ago
It goes beyond variables. At the minimum it's a name and a static or dynamic value, but it can also contain metadata, transforms, private/public attributes, formatting constraints... You may not be aware (and 10 years late in tryi
4.
by kaelig 2y ago
> But the dark primary button background color and light primary button background color are constants in a design system. They are not necessarily constants, and _could_ point to a theme's value, or even be generated on the fly. &g
5.
by kaelig 2y ago
Thank you for sharing – and good luck, as this is a tough situation to be in. Some teams neglect to consider the entire lifecycle of a token and introduce too many, too early. They can bring a ton of value, but it has to be weighed against
6.
by kaelig 2y ago
The "fun" part with HSL is that RGB->HSL->RGB conversion doesn't always land back on the initial value (and that's why I discourage using HSL altogether). In orgs without design tokens, I forgot to mention there&#x
7.
by kaelig 2y ago
> Bootstrap and Sass already solve this problem for the web. In a vacuum, sure. But products aren't all built in a web-centric vacuum. > That's irrelevant, isn't it? I mean, do you run apps straight out of Sigma/Sk
8.
by kaelig 2y ago
They can be constants, but not always: 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 happen at runtime or at build t
9.
by kaelig 2y ago
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, us
10.
by kaelig 2y ago
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 no
11.
by kaelig 2y ago
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
12.
by kaelig 2y ago
> 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, the
13.
by kaelig 2y ago
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 complia
14.
by kaelig 2y ago
It also helps small teams build faster. A shared language around color, spacing, typography makes design/engineering collaboration way smoother, and reduces rework. A good first step is to have your color palette in your design tool of
15.
by kaelig 2y ago
Colors can be expressed in many ways. For example in Android it's common to see hex codes as #AARRGGBB, but in CSS the alpha is at the end (#RRGGBBAA). With wider gamuts (lch, dcip3...), there are separate channels and alpha is express
16.
by kaelig 2y ago
A few members and myself have commented to explain in various ways what we're solving. This methodology is being used by most frontend and design teams at medium/large companies. There's a real need for a way to communicate d
17.
by kaelig 2y ago
> processes focused on product release +10000 As I mentioned in a couple of my other messages, beware of people over-systematizing and over-centralizing, as it can come at the cost of delivery efficiency and defeats the point of operatio
18.
by kaelig 2y ago
You're right in that the "centralized single source of truth" actually rarely is a thing at scale. It's common to adopt a mixed approach: some design tokens make sense to centralize (like global brand colors), and others
19.
by kaelig 2y ago
Thank you for sharing — sounds like we've had different experiences but I can absolutely see how poorly implemented devops is worse than well-implemented ops. I've written about operationalizing design and design/engineering
20.
by kaelig 2y ago
"it depends" When working on products that can last decades, you can't just throw away all styling and start from scratch. In this case, design tokens are essentially styling hooks that allow teams to propagate design changes
21.
by kaelig 2y ago
It's certainly been a longer journey than I'd anticipated to get to a "V1", but the current snapshot of the spec does have good penetration, allowing us to see what works and what doesn't in the wild. The main areas
22.
by kaelig 2y ago
Say more
23.
by kaelig 2y ago
For context, this name was coined 10 years ago, before the crypto/blockchain craze.
24.
by kaelig 2y ago
Correct, I'm fact I've advised a few teams to only introduce layers of abstraction they needed and could actively document & support. It's very tempting to copy fortune 500 companies because they're the ones with des
25.
by kaelig 2y ago
A few names, including "design variables", were considered in 2014 when Jina Anne and Jon Levine (Salesforce) coined the term. I wasn't in the room when they made the decision, but perhaps they'll pop into this thread an
26.
by kaelig 2y ago
This is fair, I've also seen design systems grow in complexity. Sometimes for good reasons, but also because "design systems professionals will... systematize". That said, it's not just about "updatability" of
27.
by kaelig 2y ago
The role of the spec is to have alignment throughout proprietary and open source toolchains, from design tools to CI build scripts to UI frameworks, so everyone working on an experience can speak the same language, have high fidelity end to
28.
by kaelig 2y ago
There are multiple ways to solve this, we've explored a few and we found that clearly differentiating user inputs from the spec keys was the right way to go for this use-case and our audience. That said, there definitely are other vali
29.
by kaelig 2y ago
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 m
30.
by kaelig 2y ago
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.

More ›