I personally think we have this all wrong, and that all species should have to comply with some level of public decorum to be allowed in public human-dominated spaces.
If a dog doesn't make loud noises, physically agitates others, or excessively spread diseases (slobbering all over the place), it seems fine to let them be in the same place. If someone has allergies, an agreement can usually be worked out to create distance, but if it can't we should favor the human.
So in a sense, I agree with you: They should have licenses that can be revoked based on their behavior. I don't really care if they're for service reasons or otherwise, I just care they're fit to be in public. Some dogs are, some aren't. Basically, we should be comfortable with fascistic enforcement around dog's behaviorally. That seems like a healthy middle-ground.
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 value in one place. All of the above surfaces are updated at the same time.
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.
It's true that most websites and apps probably don't work this way today. I've worked in a lot of them, and they were not pleasant developer experiences burning up way more developer time than necessary. They become unwieldy at any kind of scale, producing all kinds of visual bugs and incongruencies on every single engineer PR.
An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?". But the answer to the question of the utility of the design tokens is obvious if you do decide that design systems are important for a business.
> 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 assume all contrast issues fix themselves? So do color clashes? No? Designers still need to consider their change in context? So, again, how is it different from a set of agreed-upon constants?
CSS variables and derived values are a way to implement those constants. Not the only one, but a decent one. Yes, you need to properly resolve dependencies/propagate values, but you need to do that with any other implementation as well.
Sure, call it design tokens instead of constants - but is there any difference? I'm really trying to understand how this is contributing anything on top of symbolic referents. Something that at least on the engineering side is well known since before the infamous "should the value of pi change" manual entry.
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.
I suspect commenters already don't quite get the point of design systems in the first place, this UI architecture idea goes several steps beyond that. Design systems are already really hard to pull off depending on the people involved, any effort at systematizing that approach are very well worth it, but is going to be met with opposition.
I suspect if you wrote about atomic design[1] for example you would get similar comments.
Also here[2] is an example of a design system to better understand how to extrapolate the "brand color" example.
> 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 we keep changing the colours/shapes/general theme/etc. of our brand's logos every nine months or so, do they even matter, really?"
My suspicion is that the answer is "no, not really, that's why we can afford to meddle with them since it's a mostly consequence-free environment, and it distracts busybodies from breaking some actually important aspect of the business".
> 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.
It won't be just a single color either, but a whole palette for them. It's not practical to do a search/replace of color hexes across all designs and code, because it can depend on context which color is appropriate to use where, especially for accessibility.
It's also the norm I would say for startups and small companies to launch with minimal/good-enough branding (often with poor color contrast for the main brand colors because people love bright colors on white), and then they change/refine it later when it's more important.
Not saying you need design tokens at all stages, but brands do evolve.
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 the Salesforce ecosystem thanks to their design system and design tokens.
M3 is an upgrade but even the "header carousel" component there had me straight up pause and study all the ways it's terrible
From the ripple effect that overflows depending on how wide the text underneath is.
The "back button" which is actually for going from one section to the next
And the way it behaves as I click from section to section using those buttons is "top tier jank" for the lack of a better term
The way it also randomly seems to align or not align the currently selected heading resulting in weird clipping of text that just looks confusing and broken.
The shadow indicating the elevation chance as it goes sticky also looks and feels straight out of Windows 95
Why can't Google just make an aesthetically pleasing UI? It almost feels like Apple and the "modern SaaS template ala WorkOS" guys stole the only two good looking directions for modern UI aesthetics and now Google is stuck pushing along their hideous (but identifiable!) aesthetic along side them.
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.
But what you need to replace is semantic strings, which "computers" are really bad at finding, and programmers, thinking it's easy, are really bad at adding
if this is the first time you heard that term then you will be hopelessly lost, but these concepts are a decade old by now and used by UI teams in every medium/major company in the world. It's well established terminology, if people never heard about it before they should question the validity of their opinions on the matter.
> 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?
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.
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.
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?
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.
> 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/Sketch/Framer? Do you also think it's reasonable to call out Photoshop/Gimp/MSPaint?
Figma/Sketch/Framer are design and prototyping tools. They are _very_ relevant in how we build products. The back-and-forth between design and engineering leads to better outcomes if both sides speak the same language, and their tools allow them to do so.
(Photoshop/Gimp/MSPaint aren't so relevant un product design)
> Do you think it makes any sense to bundle everything together?
Not everything. You generally want folks using your products across iOS, their car, their TV, and a web browser have a coherent experience. This doesn't mean that everything needs to look exactly the same. It means that key design decisions can be distributed across the board.
If you're talking about liking the full experience with settings and previews, that I'm afraid is all custom built. I can't imagine an open source reusable one being out there, but I could be wrong!
It does say they have a business model ("our business model means safety, security, and progress are all insulated from short-term commercial pressures"). I imagine it's some kind of patron model that requires a long-term commitment.
Seems to me like bowling rules could use an update. When every pro is so good that they are just competing on mental focus, the nature of the ball, and slight environmental factors like the changing slickness of the wood, it has ceased to become compelling competition. I’d love to see some kind of dynamic interaction between the players: e.g. if you hit your 3 pin, it gets added to the opposing player. Something like that.
I suppose this goes for all sports of this kind where the players actions don’t affect each other.
Ahem: snooker, darts, golf, test match cricket, tennis. To varying degrees with these sports, at the top tier, mastery of the skill is merely the table stakes. The winners are the ones who can do so under immense pressure.
(Not to knock the people who do that vs less high tech bullseye disciples, because they're also definitely better - they clean house in the lower tech competitions too)
I'm reminded of an excerpt from Ian Banks culture series, the game player one (player of games?). Really good games need some element of random, not just pure skill+gear.
I just wish they would use real rifles. I don't get the point of target shooting with air rifles. Dealing with the characteristics of an actual gun is a core part of marksmanship.
To me, competing in target shooting with an air rifles is like competing in a marathon using a treadmill.
This is probably stating the obvious but being able to compete with low energy rifles is a must for inclusivity in the sport. Gas rifles are legal and available everywhere.
The limit in the UK is 12 foot pounds for an air rifle. Oddly, comparing that with a bow (draw weight of 40 pounds firing a 30” arrow) makes archery seem pretty lethal.
Yup this is exactly it. As more countries limit civilian gun ownership, the ISSF has followed to keep participation at the international level broader. At some point I imagine 50m 3p will get replaced by 3p air - 50m prone is already gone from Olympics.
There are a few places where 300m ISSF is still done, like Switzerland, but it's dwindling.
Even in the US, high power bullseye is much less common than smallbore/air, because there's no terminal college or international goal.
From a precision standpoint, the air rifles are also much more exact for cheaper. 10m air rifle is insanely difficult.
And also let's be honest, bullseye is a weird mental game that most people don't like anyways. So anyone in the US doing gun-competition-for-fun is doing USPSA or similar.
If you want to do high power bullseye, there's still a handful of people left doing it.
ISSF is trying to gamify the finals for bullseye competitions, and it's... well it's a thing. Idk if it's good, but it's probably more entertaining for the bundesliga cheering people
Yeah and the league hates it, so they deadened the ball two years back. Just enough that close homers would go for fly outs but not enough to change the math so players would change their approach.
One of the few un-nuanced takes I have is that every component library/DS should be built on top of Radix or React-Aria or some other thorough but extensible library. If you’re implementing your own tooltips and menus, you’ve lost the plot. We need to stop reimplementing bad versions of commoditized bits of UI that overlook accessibility, appropriately generic prop APIs, boundary detection, composability, documentation, testing, etc.
It pains me to see dev teams spending time on rebuilding solved problems. I understand brownfield constraints, but the greenfield situations are particularly painful.
It's painful sometimes to think of the sheer number of man-hours wasted because browsers have never added a combobox or any way to style select dropdowns.
I’m in that stage now and this was a really good set of insights here (admittedly that I don’t quite fully understand). Open to DM? My email in profile.
1) Adding it to an existing codebase with lots of global scope. The techniques espoused in the documentation simply don't work well with existing leaky CSS with varying levels of specificity. Adding important to all TW classes and name-spacing all of them invites new problems.
2) Making your own components with lots of variants: the syntax required feels like you're doing contortions to make it work nicely. There's probably some special techniques but it's a lot easier to take advantage of the cascade in my experience.
3) Dev tooling: the OP I think is dead-on in the criticism that you break a lot of browser tooling when using Tailwind. The right hand side of the Elements tab is a complete disaster. The JIT that Tailwind provides to only include styles you need also makes things annoying: If I want to add some classes on the fly in the Elements tab (which is annoying anyway by having to edit HTML), it won't work if you need any classes not currently not used in the built code. You can mitigate this with modifying your JIT setting for dev to include a ton of classes but it just doesn't flow. The TW documentation is very cagey about how dev flows should work and for good reason.
I actually like utility classes as a concept and if I were starting greenfield projects I might consider Tailwind with an existing component library despite the dev tooling issues. I just think it doesn't layer onto existing codebases well.
1) My heart goes out to you here. I feel like re-adapting any existing styles to work in or with a new system can be a real challenge, and I'd hate to have to make it work. I've tried this once in an environment where it would have to mesh into a larger system with prefixes/important. I gave up and wrote vanilla. Tailwind just doesn't seem like a good fit there.
2) They have a couple of pseudo-selectors but just largely don't use them if we need the cascade. We just write vanilla instead, but it's funny how often that isn't required. When things need to be dynamic we'll often use the classnames library.
3) This is really interesting because we haven't really experienced this. I wonder if it's framework or ecosystem specific. I often find opinions vary broadly across these lines because of what you noted about the variance in dev flow.
If a dog doesn't make loud noises, physically agitates others, or excessively spread diseases (slobbering all over the place), it seems fine to let them be in the same place. If someone has allergies, an agreement can usually be worked out to create distance, but if it can't we should favor the human.
So in a sense, I agree with you: They should have licenses that can be revoked based on their behavior. I don't really care if they're for service reasons or otherwise, I just care they're fit to be in public. Some dogs are, some aren't. Basically, we should be comfortable with fascistic enforcement around dog's behaviorally. That seems like a healthy middle-ground.