You might not need (much) JavaScript for these common interface patterns.
While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.
Yes! Client-side JavaScript should do what only client-side JavaScript can do.
This is a superb way to deprecate a little JavaScript library. Now that you can just use HTML instead, the website for Pikaday has been turned into a guide to choosing the right design pattern for your needs. Bravo!
Pikaday is no longer a JavaScript date picker. Pikaday is now a friendly guide for front-end developers. I want to push developers away from the classic date picker entirely. Especially fat JavaScript libraries.
I’m fascinated by eponymous laws, and here’s a whole bunch of them gathered together, including a few I hadn’t heard of (mostly from the world of software).
- Install Stuff Indiscriminately From npm
- Pick a Framework Before You Know You Need One
- Always, Always Require a Compilation Step
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.
Deceptive design meets gamification in this explanatory puzzle game (though I wish it weren’t using the problematic label “dark patterns”).
I created this interactive experience to explore the intersection of design ethics and human psychology, helping us all make more informed choices while browsing the web.
- People only understand things relative to things they already understand
- People only understand things in context
- People rely on patterns and consistency
- People seek to minimize cognitive load
- People have varying levels of expertise and familiarity
- People are goal-oriented
- People often don’t know what they’re looking for
- Information is more useful when it’s actionable
I haven’t spoken at any conferences so far this year, and I don’t have any upcoming talks. That feels weird. I’m getting kind of antsy to give a talk.
I suspect my next talk will have something to do with HTML web components. If you’re organising an event and that sounds interesting to you, give me a shout.
But even though I’m not giving a conference talk this year, I’m doing a fair bit of hosting. There was the lovely Patterns Day back in March. And this week I’m off to Amsterdam to be one of the hosts of CSS Day. As always, I’m very much looking forward to that event.
Once that’s done, it’ll be time for the biggie. UX London is just two weeks away—squee!
There are still tickets available. If you haven’t got yours yet, I highly recommend getting it before midnight on Friday—that’s when the regular pricing ends. After that, it’ll be last-chance passes only.
Whenever I confront a design system problem, I ask myself this one question that guides the way: “What would HTML do?”
HTML is the ultimate composable language. With just a few elements shuffled together you can create wildly different interfaces. And that’s really where all the power from HTML comes up: everything has one job, does it really well (ideally), which makes the possible options almost infinite.
Design systems should hope for the same.
When I documented my approach to HTML web components I sang the praises of composability:
Rather than having a few powerful web components, I like having lots of simple web components. The power comes with how they’re combined. Like Unix pipes.
I feel the same way about design systems. In my experience, the design systems that encourage mixing and matching different combinations are the ones that actually get used.
The design systems that struggle with adoption often have the best of intentions. “Look, there are all these pre-made components for you—you should just use them!” But that can be very disempowering. Where’s the sense of agency in using a pre-made solution?
Robin wrote a fascinating post recently called The Other Side (almost certainly not a reference to the Salter Cane song of the same name). He went from being on a design system team trying to enforce adoption to being on a team on the receiving end:
I don’t wanna have to think about hex values or button sizes or box shadows. I don’t want to rethink padding and margins or rethink the grid each time I design a page.
But by golly if a design system says “no” to me then I will do my very best to blow it up.
Colours, spacing, type; these are all building blocks that a designer can compose with. But it gets murkier after that. Pre-made form fields? Sure. Pre-made forms? No thank you!
It’s like there’s a line where a design system crosses over from being a useful toolkit into being a bureaucratic hurdle to overcome. When you hear a designer complaining that a design system is stifling their creativity, I bet it’s because that line has been crossed.
There’s a tired cliché of an analogy when it comes to design systems: LEGO. It’s not a good analogy but I think it can help to understand this imbalance.
Remember old-school LEGO? The pieces were unopinionated. You had to use your imagination to combine them into something.
Later we got LEGO kits. You followed instructions to create a pre-ordained final combination.
I’m not just being an old man yelling at a cloud when I say that those later sets were different. Not bad, necessarily. But the fun came from cosplaying as a factory worker rather than inventing from whole cloth.
There are certainly organisations where pre-made kits are going to be useful. But when you start mandating their use, don’t be surprised when you get pushback from designers who miss the combinatorial power of using simple building blocks. As Robin says:
I want the design system to carefully guide me instead of brute-forcing its decisions onto my work.
Brad recently wrote about the art of design system recipes. Recipes are combinations of the building blocks in a design system, but they’re not intended to be The One True Way for everyone else solving a similar problem. It’s totally fine if a recipe is a one-off solution.
The design system’s core components are the ingredients stocked in the pantry. Other product designers then take those ingredients to create product-specific compositions that meet their product needs.
I suspect that a lot of design systems have made the mistake of canonising recipes too soon, mandating their use.
A Darwinian approach works better. If multiple people keep creating the same recipe independently then and only then should it be considered for inclusion in the design system.
A design system team should be reluctant to allow a new component into the inner sanctum. Instead I see design system teams eager to mint as many ready-made components as possible.
But if the true test of a design system is in its adoption, then the safest bet is to stick to the basic building blocks. Support designers by taking care of their baseline needs. But don’t stop them from composing.
I’ve been deep-diving into HTML web components over the past few weeks. I decided to refactor the JavaScript on The Session to use custom elements wherever it made sense.
I really enjoyed doing this, even though the end result for users is exactly the same as before. This was one of those refactors that was for me, and also for future me. The front-end codebase looks a lot more understandable and therefore maintainable.
Most of the JavaScript on The Session is good ol’ DOM scripting. Listen for events; when an event happens, make some update to some element. It’s the kind of stuff we might have used jQuery for in the past.
Chris invoked Betteridge’s law of headlines recently by asking Will Web Components replace React and Vue? I agree with his assessment. The reactivity you get with full-on frameworks isn’t something that web components offer. But I do think web components can replace jQuery and other approaches to scripting the DOM.
I’ve written about my preferred way to do DOM scripting: element.target.closest. One of the advantages to that approach is that even if the DOM gets updated—perhaps via Ajax—the event listening will still work.
Well, this is exactly the kind of thing that custom elements take care of for you. The connectedCallback method gets fired whenever an instance of the custom element is added to the document, regardless of whether that’s in the initial page load or later in an Ajax update.
So my client-side scripting style has updated over time:
event.target.closest.None of these progressions were particularly ground-breaking or allowed me to do anything I couldn’t do previously. But each progression improved the resilience and maintainability of my code.
Like Chris, I’m using web components to progressively enhance what’s already in the markup. In fact, looking at the code that Chris is sharing, I think we may be writing some very similar web components!
A few patterns have emerged for me…
Naming things is famously hard. Every time you make a new custom element you have to give it a name that includes a hyphen. I settled on the convention of using the first part of the name to echo the element being enhanced.
If I’m adding an enhancement to a button element, I’ll wrap it in a custom element that starts with button-. I’ve now got custom elements like button-geolocate, button-confirm, button-clipboard and so on.
Likewise if the custom element is enhancing a link, it will begin with a-. If it’s enhancing a form, it will begin with form-.
The name of the custom element tells me how it’s expected to be used. If I find myself wrapping a div with button-geolocate I shouldn’t be surprised when it doesn’t work.
You can use any attributes you want on a web component. You made up the name of the custom element and you can make up the names of the attributes too.
I’m a little nervous about this. What if HTML ends up with a new global attribute in the future that clashes with something I’ve invented? It’s unlikely but it still makes me wary.
So I use data- attributes. I’ve already got a hyphen in the name of my custom element, so it makes sense to have hyphens in my attributes too. And by using data- attributes, the browser gives me automatic reflection of the value in the dataset property.
Instead of getting a value with this.getAttribute('maximum') I get to use this.dataset.maximum. Nice and neat.
My favourite web components aren’t all-singing, all-dancing powerhouses. Rather they do one thing, often a very simple thing.
Here are some examples:
aria-collapsable for toggling the display of one element when you click on another.play-button for adding a play button to an audio or video element.ajax-form for sending a form via Ajax instead of a full page refresh.user-avatar for adding a tooltip to an image.table-saw for making tables responsive.All of those are HTML web components in that they extend your existing markup rather than JavaScript web components that are used to replace HTML. All of those are also unambitious by design. They each do one thing and one thing only.
But what if my web component needs to do two things?
I make two web components.
The beauty of custom elements is that they can be used just like regular HTML elements. And the beauty of HTML is that it’s composable.
What if you’ve got some text that you want to be a level-three heading and also a link? You don’t bemoan the lack of an element that does both things. You wrap an a element in an h3 element.
The same goes for custom elements. If I find myself adding multiple behaviours to a single custom element, I stop and ask myself if this should be multiple custom elements instead.
Take some of those button- elements I mentioned earlier. One of them copies text to the clipboard, button-clipboard. Another throws up a confirmation dialog to complete an action, button-confirm. Suppose I want users to confirm when they’re copying something to their clipboard (not a realistic example, I admit). I don’t have to create a new hybrid web component. Instead I wrap the button in the two existing custom elements.
Rather than having a few powerful web components, I like having lots of simple web components. The power comes with how they’re combined. Like Unix pipes. And it has the added benefit of stopping my code getting too complex and hard to understand.
Okay, so I’ve broken all of my behavioural enhancements down into single-responsibility web components. But what if one web component needs to have awareness of something that happens in another web component?
Here’s an example from The Session: the results page when you search for sessions in London.
There’s a map. That’s one web component. There’s a list of locations. That’s another web component. There are links for traversing backwards and forwards through the locations via Ajax. Those links are in web components too.
I want the map to update when the list of locations changes. Where should that logic live? How do I get the list of locations to communicate with the map?
When a list of locations is added to the document, it emits a custom event that bubbles all the way up. In fact, that’s all this component does.
You can call the event anything you want. It could be a newLocations event. That event is dispatched in the connectedCallback of the component.
Meanwhile in the map component, an event listener listens for any newLocations events on the document. When that event handler is triggered, the map updates.
The web component that lists locations has no idea that there’s a map on the same page. It doesn’t need to. It just needs to dispatch its event, no questions asked.
There’s nothing specific to web components here. Event-driven programming is a tried and tested approach. It’s just a little easier to do thanks to the connectedCallback method.
I’m documenting all this here as a snapshot of my current thinking on HTML web components when it comes to:
I may well end up changing my approach again in the future. For now though, these ideas are serving me well.
Lovely photos by Marc from Patterns Day!
Trys threads the themes of Patterns Day together:
Jeremy did a top job of combining big picture and nitty-gritty talks into the packed schedule.
A nice write-up of Patterns Day from Hidde.
The third Patterns Day happened yesterday. It was lovely!
The last time we had a Patterns Day was in 2019. After five years it felt very, very good to be back in the beautiful Duke Of York’s for another full day of design systems nerdery.
I wasn’t the only one who felt that way. A lot of people told me how much they enjoyed the event, which swelled my heart with happiness. I’m genuinely grateful to everyone who came—thank you so much!
The talks were, of course, excellent. I feel pretty good about the flow of the day. I tried to mix and match between big-picture talks with broad themes and nitty-gritty talks diving into details. The contrast worked really well.
In the pub afterwards it was fascinating to hear how much the different talks resonated with people. So many people felt seen, in the best possible way. It’s quite gratifying to hear that you’re not alone, that other people are struggling with the same kinds of issues with design systems as you are.
At the very first Patterns Day when it was still early days for design systems, there was still a certain amount of cheerleading, bigging up all the benefits of design systems. In 2024 there’s a lot more real talk about how much hard work there is. The design systems struggle is real.
There was another overarching theme at this year’s Patterns Day. Even though there was plenty of coverage of technical details like design tokens, typography and components, the big takeaway was all about people. Collaboration. Agreement. Community. These are the real foundations of a design system that works.
I’m so grateful to all the wonderful speakers yesterday for reminding us of what really matters.
Harry popped ’round to the Clearleft studio yesterday. It’s always nice when a Clearleft alum comes to visit.
It wasn’t just a social call though. Harry wanted to run through the ideas he’s got for his UX London talk.
Wait. I buried the lede. Let me start again.
Harry Brignull is speaking at this year’s UX London!
Yes, the person who literally wrote the book on deceptive design patterns will be on the line-up. And judging from what I heard yesterday, it’s going to be a brilliant talk.
It was fascinating listening to Harry talk about the times he’s been brought in to investigate companies accused of deliberately employing deceptive design tactics. It involves a lot of research and detective work, trawling through internal communications hoping to find a smoking gun like a memo from the boss or an objection from a beleaguered designer.
I thought about this again today reading Nic Chan’s post, Have we forgotten how to build ethical things for the web?. It resonates with what Harry will be talking about at UX London. What can an individual ethical designer do when they’re embedded in a company that doesn’t prioritise user safety?
It’s like a walking into a jets pray of bullshit, so much so that even those with good intentions get easily overwhelmed.
Though I try, my efforts rarely bear fruit, even with the most well-meaning of clients. And look, I get it, no on wants to be the tall poppy. It’s hard enough to squeeze money from the internet-stone these days. Why take a stance on a tiny issue when your users don’t even care? Your competitors certainly don’t. I usually end up quietly acquiescing to whatever bad are made, praying no future discerning user will notice and think badly of me.
It’s pretty clear to me that we can’t rely on individual people to make a difference here.
Still, I take some encouragement from Harry’s detective work. If the very least that an ethical designer (or developer) does is to speak up, on the record, then that can end up counting for a lot when the enshittification hits the fan.
If you see something, say something. Actually, don’t just say it. Write it down. In official communication channels, like email.
I remember when Clearleft crossed an ethical line (for me) by working on a cryptobollocks project, I didn’t just voice my objections, I wrote them down in a memo. It wasn’t fun being the tall poppy, the squeeky wheel, the wet blanket. But I think it would’ve been worse (for me) if I did nothing.
It is now exactly five weeks until Patterns Day—just another 35 sleeps!
Everthing is in place for a perfect day of deep dives into design systems. There’ll be eight snappy 30 minute talks—bam, bam, bam!
Here’s the schedule I’ve got planned for the day:
| Registration. | |
| Jeremy introduces the day. | |
| Jina delivers the opening keynote. | |
| Débora talks about the outcomes, lessons and challenges from using design tokens. | |
| Break. | |
| Yolijn talks about the relay method for design system governance. | |
| Geri talks about her journey navigating accessibility in design systems. | |
| Lunch. | |
| Richard talks about responsive typography in design systems. | |
| Samantha talks about getting buy-in for a design system. | |
| Break. | |
| Mary talks about transitioning from a single to a multi-brand design system. | |
| Vitaly delivers the closing keynote. | |
| Jeremy wraps up the day. | |
| Have a drink and a geek pub quiz at the Hare And Hounds pub. |
I assume you’ve got your ticket already, but if not use the discount code JOINJEREMY to get 10% off the ticket price.
See you there!
Patterns Day is exactly six weeks away—squee!
If you haven’t got your ticket yet, get one now. (And just between you and me, use the discount code JOINJEREMY to get a 10% discount.)
I’ve been talking to the speakers and getting very excited about what they’re going to be covering. It’s shaping up to be the perfect mix of practical case studies and big-picture thinking. You can expect talks on design system governance, accessibility, design tokens, typography, and more.
I’m hoping to have a schedule for the day ready by next week. It’s fun trying to craft the flow of the day. It’s like putting together a set list for a concert. Or maybe I’m just overthinking it and it really doesn’t matter because all the talks are going to be great anyway.
There are sponsors for Patterns Day now too. Thanks to Supernova and Etch you’re going to have bountiful supplies of coffee, tea and pastries throughout the day. Then, when the conference talks are done, we’ll head across the road to the Hare And Hounds for one of Luke Murphy’s famous geek pub quizes, with a bar tab generously provided by Zero Height.
Now, the venue for Patterns Day is beautiful but it doesn’t have enough space to provide everyone with lunch, so you’re going to have an hour and a half to explore some of Brighton’s trendy lunchtime spots. I’ve put together a list of lunch options for you, ordered by proximity to the Duke of York’s. These are all places I can personally vouch for.
Then, after the conference day, and after the pub quiz, there’s Vitaly’s workshop the next day. I will most definitely be there feeding on Vitaly’s knowledge. Get a ticket if you want to join me.
But wait! That’s not all! Even after the conference, and the pub quiz, and the workshop, the nerdy fun continues on the weekend. There’s going to be an Indie Web Camp here in Brighton on the Saturday and Sunday after Patterns Day.
If you’ve been to an Indie Web Camp before, you know how inspiring and fun it is. If you haven’t been to one yet, you should definitely come along. It’s free! If you’ve got your own website, or if you’re even just thinking about having your own website, it’s a great opportunity to meet with like-minded people.
So that’s going to be four days of non-stop good stuff here in Brighton. I’m looking forward to seeing you then!
Okay, if you weren’t already excited for Patterns Day, get a load of what Rich is going to be talking about!
You’ve got your ticket, right?
The line-up for Patterns Day is complete! You’ll be hearing from eight fantastic speakers on March 7th 2024 here in Brighton.
I really like the mix of speakers we’ve got…
Half of the speakers will be sharing what they’ve learned from design systems in their organisations: Débora from LEGO, Mary from the Financial Times, Yolijn from the Dutch government, and Samantha from University College London. That’s a good spread of deep dives.
The other half of the speakers can go broad across design systems in general: Vitaly on design patterns, Rich on typography, Geri on accessibility, and Jina on …well, absolutely everything to do with design systems!
I’m so happy that I could get the line-up to have this mix. If you have any interest in design systems at all—whether it’s as a designer, a developer, a product manager, or anything else—you won’t want to miss this. Early bird tickets are £225.
But wait! That’s not all. If you really want to dive deep into interface design patterns, then stick around. The day after Patterns Day, Vitaly is running a one-day workshop:
In this in-person workshop with Vitaly Friedman, UX consultant and creative lead behind Smashing Magazine, we’ll dive deep into dissecting how to solve complex design problems. Whether you’re working on a complex nested multi-level navigation or creating enterprise grade tables, this workshop will give you the tools you need to excel at your work.
Places are limited. There isn’t room for everyone who’s going to be at Patterns Day, so if you—and your team—want to learn design pattern kung-fu from the master, get your workshop ticket now! Workshop tickets are £445.