I like the idea of adding this to personal websites:
Mastodon shows an “Alt” button in the bottom right of images that have associated alt text. This button, when clicked, shows the alt text the author has written for the image.
Marcin has outdone himself this time. Not only has he created an exhaustive history of the settings controls in Apple interfaces, he’s gone and made them all interactive!
While it’s easy to be blown away by the detail of the interactive elements here, it’s also worth taking a moment to appreciate just how good the writing is too.
Bravo!
Overall, consistency, user control, and actual UX innovation are in decline. Everything is converging on TikTok—which is basically TV with infinite channels. You don’t control anything except the channel switch. It’s like Carcinisation, a form of convergent evolution where unrelated crustaceans all evolve into something vaguely crab-shaped.
I’m obviously biased, but I like the sound of what Chris is doing to create a library of HTML web components.
I’ve been banging on for a while now about how much I’d like a declarative option for the Web Share API. I was thinking that the type attribute on the button element would be a good candidate for this (there’s prior art in the way we extended the type attribute on the input element for HTML5).
I wrote about the reason for a share button type as well as creating a polyfill. I also wrote about how this idea would work for other button types: fullscreen, print, copy to clipboard, that sort of thing.
Since then, I’ve been very interested in the idea of “invokers” being pursued by the Open UI group. Rather than extending the type attribute, they’ve been looking at adding a new attribute. Initially it was called invoketarget (so something like button invoketarget="share").
Things have been rolling along and invoketarget has now become the command attribute (there’s also a new commandfor attribute that you can point to an element with an ID). Here’s a list of potential values for the command attribute on a button element.
Right now they’re focusing on providing declarative options for launching dialogs and other popovers. That’s already shipping.
The next step is to use command and commandfor for controlling audio and video, as well as some form controls. I very much approve! I love the idea of being able to build and style a fully-featured media player without any JavaScript.
I’m hoping that after that we’ll see the command attribute get expanded to cover JavaScript APIs that require a user interaction. These seem like the ideal candidates:
button command="share"button command="fullscreen"button command="print"button command="copy"button command="install"There’s also scope for declarative options for navigating the browser’s history stack:
button command="back"button command="forward"button command="refresh"Whatever happens next, I’m very glad to see that so much thinking is being applied to declarative solutions for common interface patterns.
dialog, details, datalist, progress, optgroup, and more:
If this article helps just a single developer avoid an unnecessary Javascript dependency, I’ll be happy. Native HTML can handle plenty of features that people typically jump straight to JS for (or otherwise over-complicate).
And by LLMS I mean: (L)ots of (L)ittle ht(M)l page(S).
I really like this approach: using separate pages instead of in-page interactions. I remember Simon talking about how great this works, and that was a few years back, before we had view transitions.
I build separate, small HTML pages for each “interaction” I want, then I let CSS transitions take over and I get something that feels better than its JS counterpart for way less work.
Every UI control you roll yourself is a liability. You have to design it, test it, ship it, document it, debug it, maintain it — the list goes on.
It makes you wonder why we insist on rolling (or styling) our own common UI controls so often. Perhaps we’d be better off asking: What are the fewest amount of components we have to build to deliver value to our users?
It’s great to see the evolution of HTML happening in response to real use-cases—the turbo-charging of the select element just gets better and better!
- Violates User Expectations
- Causes Motion Sickness
- Reduces Accessibility for Disabled Users
- Inconsistent Performance Across Devices
- Impairs Usability for Power Users
- Increases Page Load Times
- Breaks Native Browser Features
- Makes Scroll Position Unclear
- Adds Maintenance Overhead
- Disrespects the User’s Control
What an excellent personal website!
I do not want any software
I believe that this mindset is the healthiest way to design and build things that people will use and not hate us for building. For me, it’s a way to remind myself that all humans have a whole rich, challenging life outside of the little screens I’m making for them. So that even when I’m focused on user needs and user problems, I can keep it just out of the corner of my eye: the person I’m making this for doesn’t actually want to be here, and that’s OK.
We want speedy internet and fast-loading services because we want to stop pushing buttons and opening accordions as quickly as possible.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
I concur:
Just because a user interface uses 3D-buttons and some shading doesn’t mean that it has to look tacky. In fact, if you have to make the choice between tacky-but-usable and minimalistic-but-hard-to-use, tacky is the way to go. You don’t have to make that choice though: It’s perfectly possible to create something that is both good-looking and easy to use.
This is a really interesting proposal, and I have thoughts.
The key to making a beautiful URL is finding a balance between brevity and clarity. In other words, a good URL is short but not so short as to obscure what it’s pointing to. Put another way, a good URL contains enough information about its related resource to be useful, but not so much information that it drags on and becomes unwieldy.
A look at how personalisation works in digital interfaces and real-world objects.
Josh mashes up design systems and pace layers, like Mark did a few years back. With this mindset, if your product interface are in sync, that’s not good—either your product is moving too slow or your design system is moving too fast.
The job of the design system team is not to innovate, but to curate. The system should provide answers only for settled solutions: the components and patterns that don’t require innovation because they’ve been solved and now standardized. Answers go into the design system when the questions are no longer interesting—proven out in product. The most exciting design systems are boring.
Maybe when I wrote about performative performance? Michelle has a prime example:
The low carbon toggle does absolutely nothing.
In fact, worse than nothing. It doesn’t prevent images being downloaded. It doesn’t switch the site to dark mode, or prevent autoplaying animations (e.g. the hero carousel), or reduce resources transferred in other way. All it does is overlay an extra element with a background gradient on top of the large images on the site to give the appearance that those images being prevented from loading.
Pirijan talks us through the design principles underpinning Kinopio, a tool I like very much:
- Embrace Smallness by Embracing Code as a Living Design System
- Building for Fidget-Ability, hmmm
- Embrace Plain Text
- A Single Interface for Mobile and Desktop
- Refine by Pruning