Find freedom not in infinite choice, but in working a single seam until you strike gold: conducting dozens, even hundreds, of iterations within a tight parameter space—not in search of more, but in search of better.
A fantastic explanation of the building blocks of SVG, illustrated—as always—with Josh’s interactive examples.
I don’t normally link to articles on Medium—I respect you too much—and I do wish this were written on Mike Hall’s own site, but this is just too good not to share.
And don’t dismiss this as a nostalgiac case study from the past:
At no point did the constraints make the product feel compromised. Users on modern devices got a smooth experience and instant feedback, while those on older devices got fast, reliable functionality. Users on feature phones got the same core experience without the bells and whistles.
The constraints forced us to solve problems in ways we wouldn’t have considered otherwise. Without those constraints, we could have just thrown bytes at the problem, but with them every feature had to justify itself. Core functionality had to work everywhere, and without JavaScript crutches proper markup became essential.
This experience changed how I approach design problems. Constraints aren’t a straitjacket, keeping us from doing our best work; they are the foundation that makes innovation possible. When you have to work within severe limitations, you find elegant solutions that scale beyond those limitations.
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!
I love the interactive illustrations in this article filled with type and architecture nerdery!
An excellent appraisal of the importance of the rule of least power.
AI presents design leaders with a quandary, requiring us to tread a fine line between what is acceptable and useful, and what is problematic and harmful.
This document is not a manifesto or an agenda. It is a series of prompts written by design leaders for design leaders, conceived to help us navigate these tricky waters.
In order for principles to truly drive the work and serve as a good framework for the outcomes, they have to be debated, opinionated, and painful.
Yes! Design principles aren’t there to make you feel good; they should provoke arguments.
One of the tests that I’ve developed in thinking through writing down principles, design or otherwise, is to ask the question: “versus what?”.
Also sprach Wittgenstein:
Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.
Or in English, thus spoke Wittgenstein:
The limits of my language mean the limits of my world.
Language and thinking are intertwined. I’m not saying there’s anything to the strong form of the Sapir-Whorf hypothesis but I think George Lakoff is onto something when he talks about political language.
There’s literal political language like saying “tax relief”—framing taxation as something burdensome that needs to be relieved. But our everyday language has plenty of framing devices that might subconsciously influence our thinking.
When it comes to technology, our framing of new technologies often comes from previous technologies. As a listener to a show, you might find yourself being encouraged to “tune in again next week” when you may never have turned a radio dial in your entire life.
In the early days of the web we used a lot of language from print. John Allsopp wrote about this in his classic article A Dao Of Web Design:
The web is a new medium, although it has emerged from the medium of printing, whose skills, design language and conventions strongly influence it. Yet it is often too shaped by that from which it sprang.
One outdated piece of language on the web is a framing device in two senses: “above the fold”. It’s a conceptual framing device that comes straight from print where newspapers were literally folded in half. It’s a literal framing device that puts the important content at the top of the page.
But there is no fold. We pretended that everyone’s screens were 640 by 480 pixels. Then we pretended that everyone’s screens were 800 by 600 pixels. But we never really knew. It was all a consensual hallucination. Even before mobile devices showed up there was never a single fold.
Even if you know that there’s no literal page fold on the web, using the phrase “above the fold” is still insidiously unhelpful.
So what’s the alternative? Well, James has what I think is an excellent framing:
The landing zone.
It’s the bit of the page where people first show up. It doesn’t have a defined boundary. The landing zone isn’t something separate to the rest of the page; the content landing zone merges into the rest of the content.
You don’t know where the landing zone ends, and that’s okay. It’s better than okay. It encourages you design in a way that still prioritises the most important content but without fooling yourself into thinking there’s some invisible boundary line.
Next time you’re discussing the design of a web page—whether it’s with a colleague or a client—try talking about the landing zone.
A great talk by Matthias on what you can do with web standards today!
Today is Global Accessibility Awareness Day:
The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.
Awareness is good. It’s necessary. But it’s not sufficient.
Accessibility, like sustainability and equality, is the kind of thing that most businesses will put at the end of sentences that begin “We are committed to…”
It’s what happens next that matters. How does that declared commitment—that awareness—turn into action?
In the worst-case scenario, an organisation might reach for an accessibility overlay. Who can blame them? They care about accessibility. They want to do something. This is something.
Good intentions alone can result in an inaccessible website. That’s why I think there’s another level of awareness that’s equally important. Designers and developers need to be aware of what they can actually do in service of accessibility.
Fortunately that’s not an onerous expectation. It doesn’t take long to grasp the importance of having good colour contrast or using the right HTML elements.
An awareness of HTML is like a superpower when it comes to accessibility. Like I wrote in the foreword to the Web Accessibility Cookbook by O’Reilly:
It’s supposed to be an accessibility cookbook but it’s also one of the best HTML tutorials you’ll ever find. Come for the accessibility recipe; stay for the deep understanding of markup.
The challenge is that HTML is hidden. Like Cassie said in the accessibility episode of The Clearleft Podcast:
You get JavaScript errors if you do that wrong and you can see if your CSS is broken, but you don’t really have that with accessibility. It’s not as obvious when you’ve got something wrong.
We are biased towards what we can see—hierarchy, layout, imagery, widgets. Those are the outputs. When it comes to accessibility, what matters is how those outputs are generated. Is that button actually a button element or is it a div? Is that heading actually an h1 or is it another div?
This isn’t about the semantics of HTML. This is about the UX of HTML:
Instead of explaining the meaning of a certain element, I show them what it does.
That’s the kind of awareness I’m talking about.
One way of gaining this awareness is to get a feel for using a screen reader.
The name is a bit of a misnomer. Reading the text on screen is the least important thing that the software does. The really important thing that a screen reader does is convey the structure of what’s on screen.
Friend of Clearleft, Jamie Knight very generously spent an hour of his time this week showing everyone the basics of using VoiceOver on a Mac (there’s a great short video by Ethan that also covers this).
Using the rotor, everyone was able to explore what’s under the hood of a web page; all the headings, the text of all the links, the different regions of the page.
That’s not going to turn anyone into an accessibility expert overnight, but it gave everyone an awareness of how much the HTML matters.
Mind you, accessibility is a much bigger field than just screen readers.
Fred recently hosted a terrific panel called Is neurodiversity the next frontier of accessibility in UX design?—well worth a watch!
One of those panelists—Craig Abbott—is speaking on day two of UX London next month. His talk has the magnificent title, Accessibility is a design problem:
I spend a bit of time covering some misconceptions about accessibility, who is responsible for it, and why it’s important that we design for it up front. It also includes real-world examples where design has impacted accessibility, before moving onto lots of practical guidance on what to be aware of and how to design for many different accessibility issues.
Get yourself a ticket and get ready for some practical accessibility awareness.
I’ve been thinking about the kind of CSS I write by default when I start a new project.
Some of it is habitual. I now use logical properties automatically. It took me a while to rewire my brain, but now seeing left or top in a style sheet looks wrong to me.
When I mentioned this recently, I had some pushback from people wondering why you’d bother using logical properites if you never planned to translate the website into a language with a different writing system. I pointed out that even if you don’t plan to translate a web page, a user may still choose to. Using logical properties helps them. From that perspective, it’s kind of like using user preference queries.
That’s something else I use by default now. If I’ve got any animations or transitions in my CSS, I wrap them in prefers-reduced-motion: no-preference query.
For instance, I’m a huge fan of view transitions and I enable them by default on every new project, but I do it like this:
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}
I’ll usually have a prefers-color-scheme query for dark mode too. This is often quite straightforward if I’m using custom properties for colours, something else I’m doing habitually. And now I’m starting to use OKLCH for those colours, even if they start as hexadecimal values.
Custom properties are something else I reach for a lot, though I try to avoid premature optimisation. Generally I wait until I spot a value I’m using more than two or three times in a stylesheet; then I convert it to a custom property.
I make full use of clamp() for text sizing. Sometimes I’ll just set a fluid width on the html element and then size everything else with ems or rems. More often, I’ll use Utopia to flow between different type scales.
Okay, those are all features of CSS—logical properties, preference queries, view transitions, custom properties, fluid type—but what about actual snippets of CSS that I re-use from project to project?
I’m not talking about a CSS reset, which usually involves zeroing out the initial values provided by the browser. I’m talking about tiny little enhancements just one level up from those user-agent styles.
Here’s one I picked up from Eric that I apply to the figcaption element:
figcaption {
max-inline-size: max-content;
margin-inline: auto;
}
That will centre-align the text until it wraps onto more than one line, at which point it’s no longer centred. Neat!
Here’s another one I start with on every project:
a:focus-visible {
outline-offset: 0.25em;
outline-width: 0.25em;
outline-color: currentColor;
}
That puts a nice chunky focus ring on links when they’re tabbed to. Personally, I like having the focus ring relative to the font size of the link but I know other people prefer to use a pixel size. You do you. Using the currentColor of the focused is usually a good starting point, thought I might end up over-riding this with a different hightlight colour.
Then there’s typography. Rich has a veritable cornucopia of starting styles you can use to improve typography in CSS.
Something I’m reaching for now is the text-wrap property with its new values of pretty and balance:
ul,ol,dl,dt,dd,p,figure,blockquote {
hanging-punctuation: first last;
text-wrap: pretty;
}
And maybe this for headings, if they’re being centred:
h1,h2,h3,h4,h5,h6 {
text-align: center;
text-wrap: balance;
}
All of these little snippets should be easily over-writable so I tend to wrap them in a :where() selector to reduce their specificity:
:where(figcaption) {
max-inline-size: max-content;
margin-inline: auto;
}
:where(a:focus-visible) {
outline-offset: 0.25em;
outline-width: 0.25em;
outline-color: currentColor;
}
:where(ul,ol,dl,dt,dd,p,figure,blockquote) {
hanging-punctuation: first last;
text-wrap: pretty;
}
But if I really want them to be easily over-writable, then the galaxy-brain move would be to put them in their own cascade layer. That’s what Manu does with his CSS boilerplate:
@layer core, third-party, components, utility;
Then I could put those snippets in the core layer, making sure they could be overwritten by the CSS in any of the other layers:
@layer core {
figcaption {
max-inline-size: max-content;
margin-inline: auto;
}
a:focus-visible {
outline-offset: 0.25em;
outline-width: 0.25em;
outline-color: currentColor;
}
ul,ol,dl,dt,dd,p,figure,blockquote {
hanging-punctuation: first last;
text-wrap: pretty;
}
}
For now I’m just using :where() but I think I should start using cascade layers.
I also want to start training myself to use the lh value (line-height) for block spacing.
And although I’m using the :has() selector, I don’t think I’ve yet trained my brain to reach for it by default.
CSS has sooooo much to offer today—I want to make sure I’m taking full advantage of it.
Great design isn’t defined by who knows your name, but by how well your work serves human needs. It’s measured in the problems solved, the frustrations eased, the moments of delight created, and the dignity preserved through thoughtful solutions. These metrics operate independently of fame or recognition.
Our obsession with visibility also creates a troubling dynamic: design that prioritizes being noticed over being useful. This leads to visual pollution, cognitive overload, and solutions that serve the designer’s portfolio more than the user’s needs.
An enjoyable guided tour of album artwork starting at the beginning of the twentieth century.
Thoughtful analysis from Ben (as always).
In exactly six weeks time, UX London is happening!
I am ridiculously excited about this year’s line-up—I can’t wait to see the talks and get hands-on in the workshops.
If you haven’t yet got your ticket, now is the time. There’s a flash sale this week: use the discount code FLASH20 to get a whopping 20% of any ticket. Do it before the end of Friday!
Whether you’re coming for all three days or choosing one focused day, you’re in for a treat.
Head on over to the website to get all the details and then get your discounted ticket.
See you there!
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.
You won’t be able to unsee this. It’s like the FedEx logo …if the arrow was an anus.
- Circular shape (often with a gradient)
- Central opening or focal point
- Radiating elements from the center
- Soft, organic curves
Sound familiar? It should, because it’s also an apt description of… well, you know.
A workshop on resilient CSS layouts
Oh, hell yes!
Do not hesitate—sign yourself up to this series of three online workshops by Miriam. This is the quickest to level up your working knowledge of the most powerful parts of CSS.
By the end of this you’re going to feel like Neo in that bit of The Matrix when he says “I know kung-fu!” …except kung-fu isn’t very useful for building resilient and maintainable websites, whereas modern CSS absolutely is.
Everything you ever wanted to know about text-wrap: pretty in CSS.