Journal tags: work

I don’t like magic.

I’m not talking about acts of prestidigitation and illusion. I mean the kind of magic that’s used to market technologies. It’s magic. It just works. Don’t think about it.

I’ve written about seamless and seamful design before. Seamlessness is often touted as the ultimate goal of UX—“don’t make me think!”—but it comes with a price. That price is the reduction of agency.

When it comes to front-end development, my distrust of magic tips over into being a complete control freak.

I don’t like using code that I haven’t written and understood myself. Sometimes its unavoidable. I use two JavaScript libraries on The Session. One for displaying interactive maps and another for generating sheet music. As dependencies go, they’re very good but I still don’t like the feeling of being dependant on anything I don’t fully understand.

I can’t stomach the idea of using npm to install client-side JavaScript (which then installs more JavaScript, which in turn is dependant on even more JavaScript). It gives me the heebie-jeebies. I’m kind of astonished that most front-end developers have normalised doing daily trust falls with their codebases.

While I’m mistrustful of libraries, I’m completely allergic to frameworks.

Often I don’t distinguish between libraries and frameworks but the distinction matters here. Libraries are bits of other people’s code that I call from my code. Frameworks are other people’s code that call bits of my code.

Think of React. In order to use it, you basically have to adopt its idioms, its approach, its syntax. It’s a deeper level of dependency than just dropping in a regular piece of JavaScript.

I’ve always avoided client-side React because of its direct harm to end users (over-engineered bloated sites that take way longer to load than they need to). But the truth is that I also really dislike the extra layer of abstraction it puts between me and the browser.

Now, whenever there’s any talk about abstractions someone inevitably points out that, when it comes to computers, there’s always some layer of abstraction. If you’re not writing in binary, you don’t get to complain about an extra layer of abstraction making you uncomfortable.

I get that. But I still draw a line. When it comes to front-end development, that line is for me to stay as close as I can to raw HTML, CSS, and JavaScript. After all, that’s what users are going to get in their browsers.

My control freakery is not typical. It’s also not a very commercial or pragmatic attitude.

Over the years, I’ve stopped doing front-end development for client projects at work. Partly that’s because I’m pretty slow; it makes more sense to give the work to a better, faster developer. But it’s also because of my aversion to React. Projects came in where usage of React was a foregone conclusion. I wouldn’t work on those projects.

I mention this to point out that you probably shouldn’t adopt my inflexible mistrustful attitude if you want a career in front-end development.

Fortunately for me, front-end development still exists outside of client work. I get to have fun with my own website and with The Session. Heck, they even let me build the occasional hand-crafted website for a Clearleft event. I get to do all that the long, hard stupid way.

Meanwhile in the real world, the abstractions are piling up. Developers can now use large language models to generate code. Sometimes the code is good. Sometimes its not. You should probably check it before using it. But some developers just YOLO it straight to production.

That gives me the heebie-jeebies, but then again, so did npm. Is it really all that different? With npm you dialled up other people’s code directly. With large language models, they first slurp up everyone’s code (like, the whole World Wide Web), run a computationally expensive process of tokenisation, and then give you the bit you need when you need it. In a way, large language model coding tools are like a turbo-charged npm with even more layers of abstraction.

It’s not for me but I absolutely understand why it can work in a pragmatic commercial environment. Like Alice said:

Knitting is the future of coding. Nobody knits because they want a quick or cheap jumper, they knit because they love the craft. This is the future of writing code by hand. You will do it because you find it satisfying but it will be neither the cheapest or quickest way to write software.

But as Dave points out:

And so now we have these “magic words” in our codebases. Spells, essentially. Spells that work sometimes. Spells that we cast with no practical way to measure their effectiveness. They are prayers as much as they are instructions.

I shudder!

But again, this too is nothing new. We’ve all seen those codebases that contain mysterious arcane parts that nobody dares touch. coughWebpackcough. The issue isn’t with the code itself, but with the understanding of the code. If the understanding of the code was in one developer’s head, and that person has since left, the code is dangerous and best left untouched.

This, as you can imagine, is a maintenance nightmare. That’s where I’ve seen the real cost of abstractions. Abstractions often really do speed up production, but you pay the price in maintenance later on. If you want to understand the codebase, you must first understand the abstractions used in the codebase. That’s a lot to document, and let’s face it, documentation is the first casuality of almost every project.

So perhaps my aversion to abstraction in general—and large language models in particular—is because I tend to work on long-term projects. This website and The Session have lifespans measured in decades. For these kinds of projects, maintenance is a top priority.

Large language model coding tools truly are magic.

I don’t like magic.

Toward the end of 2021, I wrote about working a four-day week. It really suited me. So much so that I’ve gone one further. For the past year or so I’ve been working a three-day week.

I work on Tuesday, Wednesday, and Thursday. From Friday to Monday, my days are my own.

This really changes the dynamic of the week. It no longer feels like an extended weekend. What I mean is that usually we think about the working week as the default and the weekend as the exception. That’s been flipped on its head for me. The three days I spend working feel like the exception.

Once again, this decision meant earning less money. But I’ve decided that I value time more than money. I know that’s a privileged position to be in. Many people have to expend all their time in order to make just enough money.

I’ve made some choices along the way that certainly help. I don’t have children. I don’t have a car. I live in a modest flat and I’ve paid off the mortgage. I live in a country where healthcare is free.

So I don’t have too many expenses. My biggest expenses are travel-related; getting to the States to see family, or travelling to Irish music festivals wherever they may be.

But still, working a three-day week means I can make enough to cover my expenses and still put some money aside for the future.

Now, this wouldn’t work for everyone. My work tends to be the kind that doesn’t require much direct collaboration (which is also why I mostly work from home). I imagine it could get frustrating being on a team of people working different numbers of days.

I’m also really lucky to have the choice to do this. I know that many workplaces wouldn’t allow this kind of lifestyle. Clearleft is different.

In my last conference talk, I touched on this:

I think you could you could divide management into two categories like you can do with programming languages. There is a very imperative school of management where it’s all about measurements, it’s all about those performance reports, it’s all about metrics, time tracking. Maybe they install software on your machine to track how long you’ve been working. It’s all about measuring those outputs.

That’s one approach to management. Then there’s a more declarative approach, where you just care about the work getting done and you don’t care how people do it. So if they want to work from home, let them work from home. If they want to work strange hours, let them work strange hours. What do you care as long as the work gets done? This is more about giving people autonomy and trust.

I’m very happy that Clearleft takes the declarative approach.

And I can reiterate what I said when I stopped working on Fridays:

I haven’t experienced any reduction in productivity. Quite the opposite. There may be a corollary to Parkinson’s Law: work contracts to fill the time available.

Now that I don’t work on Mondays, bank holiday weekends don’t mean much to me anymore. Or to put it another way, every weekend is like a bank holiday weekend. If I want to travel somewhere on a Friday and come back on a Monday, I don’t need to book any time off. That’s really nice.

I’ve got four days in a row to do with as I wish. I had to fight the urge to immediately launch into some new project or side-hustle to fill the time. I’m savouring it instead.

I’ve got time to take care of The Session. I’ve got time to read. I’ve got time to cook. I’ve got time to spend learning Irish. Mostly I’ve got time to just be.

This isn’t a rhetorical question. I genuinely want to know why developers choose to build websites using React.

There are many possible reasons. Alas, none of them relate directly to user experience, other than a trickle-down justification: happy productive developers will make better websites. Citation needed.

It’s also worth mentioning that some people don’t choose to use React, but its use is mandated by their workplace (like some other more recent technologies I could mention). By my definition, this makes React enterprise software in this situation. My definition of enterprise software is any software that you use but that you yourself didn’t choose.

Inertia

By far the most common reason for choosing React today is inertia. If it’s what you’re comfortable with, you’d need a really compelling reason not to use it. That’s generally the reason behind usage mandates too. If we “standardise” on React, then it’ll make hiring more straightforward (though the reality isn’t quite so simple, as the React ecosystem has mutated and bifurcated over time).

And you know what? Inertia is a perfectly valid reason to choose a technology. If time is of the essence, and you know it’s going to take you time to learn a new technology, it makes sense to stick with what you know, even if it’s out of date. This isn’t just true of React, it’s true of any tech stack.

This would all be absolutely fine if React weren’t a framework that gets executed in browsers. Any client-side framework is a tax on the end user. They have to download, parse, and execute the framework in order for you to benefit.

But maybe React doesn’t need to run in the browser at all. That’s the promise of server-side rendering.

The front end

There used to be a fairly clear distinction between front-end development and back-end development. The front end consisted of HTML, CSS, and client-side JavaScript. The back end was anything you wanted as long as it could spit out those bits of the front end: PHP, Ruby, Python, or even just a plain web server with static files.

Then it became possible to write JavaScript on the back end. Great! Now you didn’t need to context-switch when you were scripting for the client or the server. But this blessing also turned out to be a bit of a curse.

When you’re writing code for the back end, some things matter more than others. File size, for example, isn’t really a concern. Your code can get really long and it probably won’t slow down the execution. And if it does, you can always buy your way out of the problem by getting a more powerful server.

On the front end, your code should have different priorities. File size matters, especially with JavaScript. The code won’t be executed on your server. It’s executed on all sorts of devices on all sorts of networks running all sorts of browsers. If things get slow, you can’t buy your way out of the problem because you can’t buy every single one of your users a new device and a new network plan.

Now that JavaScript can run on the server as well as the client, it’s tempting to just treat the code the same. It’s the same language after all. But the context really matters. Some JavaScript that’s perfectly fine to run on the server can be a resource hog on the client.

And this is where it gets interesting with React. Because most of the things people like about React still apply on the back end.

React developers

When React first appeared, it was touted as front-end tool. State management and a near-magical virtual DOM were the main selling points.

Over time, that’s changed. The claimed speed benefits of the virtual DOM turned out to be just plain false. That just left state management.

But by that time, the selling points had changed. The component-based architecture turned out to be really popular. Developers liked JSX. A lot. Once you got used to it, it was a neat way to encapsulate little bits of functionality into building blocks that can be combined in all sorts of ways.

For the longest time, I didn’t realise this had happened. I was still thinking of React as being a framework like jQuery. But React is a framework like Rails or Django. As a developer, it’s where you do all your work. Heck, it’s pretty much your identity.

But whereas Rails or Django run on the back end, React runs on the front end …except when it doesn’t.

JavaScript can run on the server, which means React can run on the server. It’s entirely possible to have your React cake and eat it. You can write all of your code in React without serving up a single line of React to your users.

That’s true in theory. The devil is in the tooling.

Priorities

Next.js allows you to write in React and do server-side rendering. But it really, really wants to output React to the client as well.

By default, you get the dreaded hydration pattern—do all the computing on the server in JavaScript (yay!), serve up HTML straight away (yay! yay!) …and then serve up all the same JavaScript that’s on the server anyway (ya—wait, what?).

It’s possible to get Next.js to skip that last step, but it’s not easy. You’ll be battling it every step of the way.

Astro takes a very different approach. It will do everything it can to keep the client-side JavaScript to a minimum. Developers get to keep their beloved JSX authoring environment without penalising users.

Alas, the collective inertia of the “modern” development community is bound up in the React/Next/Vercel ecosystem. That’s a shame, because Astro shows us that it doesn’t have to be this way.

Switching away from using React on the front end doesn’t mean you have to switch away from using React on the back end.

Why use React?

The titular question I asked is too broad and naïve. There are plenty of reasons to use React, just as there are plenty of reasons to use Wordpress, Eleventy, or any other technology that works on the back end. If it’s what you like or what you’re comfortable with, that’s reason enough.

All I really care about is the front end. I’m not going to pass judgment on anyone’s choice of server-side framework, as long as it doesn’t impact what you can do in the client. Like Harry says:

…if you’re going to use one, I shouldn’t be able to smell it.

Here’s the question I should be asking:

Why use React in the browser?

Because if the reason you’re using React is cultural—the whole team works in JSX, it makes hiring easier—then there’s probably no need to make your users download React.

If you’re making a single-page app, then …well, the first thing you should do is ask yourself if it really needs to be a single-page app. They should be the exception, not the default. But if you’re determined to make a single-page app, then I can see why state management becomes very important.

In that situation, try shipping Preact instead of React. As a developer, you’ll almost certainly notice no difference, but your users will appreciate the refreshing lack of bloat.

Mostly though, I’d encourage you to investigate what you can do with vanilla JavaScript in the browser. I totally get why you’d want to hold on to React as an authoring environment, but don’t let your framework limit what you can do on the front end. If you use React on the client, you’re not doing your users any favours.

You can continue to write in React. You can continue to use JSX. You can continue to hire React developers. But keep it on your machine. For your users, make the most of what web browsers can do.

Once you keep React on the server, then a whole world of possibilities opens up on the client. Web browsers have become incredibly powerful in what they offer you. Don’t let React-on-the-client hold you back.

And if you want to know more about what web browsers are capable of today, come to Web Day Out in Brighton on Thursday, 12th March 2026.

If you’re building software, it’s generally a good idea to avoid the Not-Invented-Here syndrome. This is when you insist on writing absolutely everything from scratch even if it would make more sense to use a third-party provider.

Need your app to take payments? Don’t try to become your own payment provider—use an existing provider instead.

Need your app to send email? Don’t try to code all that up yourself—just use an existing service.

This same thinking seems to apply to JavaScript libraries too. If you don’t use a library or framework, you’ll just end up writing your own library or framework instead, right?

Except that’s not the way that JavaScript frameworks work. At least not any more.

There was a time when JavaScript libraries really did abstract away browser differences that you probably didn’t want to deal with yourself. In the early days of jQuery—before querySelector existed—trying to work with the DOM could be a real pain. Libraries like jQuery helped avoid that pain.

Maybe it was even true in the early days of Angular and React. If you were trying to handle navigations yourself, it probably made sense to use a framework.

But that’s not the case any more, and hasn’t been for quite a while.

These days, client-side JavaScript frameworks don’t abstract away the underlying platform, they instead try to be an alternative. In fact, if you attempt to use web platform features, your JavaScript framework will often get in the way. You have to wait until your framework of choice supports a feature like view transitions before you get to use it.

This is nuts. Developers are choosing to use tools that actively get in the way of the web platform.

I think that most developers have the mental model of JavaScript frameworks completely backwards. They believe that the framework saves them time and effort (just like a payment provider or an email service). Instead these frameworks are simply limiting the possibility space of what you can do in web browsers today.

When you use a JavaScript framework, that isn’t the end of your work, it’s just the beginning. You still have to write your own code that makes use of that framework. Except now your code is restricted to only what the framework can do.

And yet most developers still believe that using a JavaScript framework somehow enables them to do more.

Jim Nielsen has a great framing on this. JavaScript libraries aren’t like payment providers or email services. Rather, it’s the features built into web browsers today that are like these third-party providers. When you use these features, you’re benefiting from all the work that the browser makers have put into making them as efficient as possible:

Browser makers have teams of people who, day-in and day-out, are spending lots of time developing and optimizing new their offerings.

So if you leverage what they offer you, that gives you an advantage because you don’t have to build it yourself.

Want to do nifty page transitions? Don’t use a library. Use view transitions.

Want to animate parts of the page as the user scrolls? Don’t use a library. Use scroll-driven animations.

Want to make something happen when the user clicks? Don’t use a library. For the love of all that is holy, just use a button.

If you agree that using a button makes more sense than using a div, then I encourage you to apply the same thinking to everything else your app needs to do.

Take advantage of all the wonderful things you can do in web browsers today. If instead you decide to use a JavaScript framework, you’re basically inventing from scratch.

Except now all of your users pay the price because they’re the ones who have to download the JavaScript framework when they use your app.

UX London will be back in 2026. It’s on June 2nd, 3rd, and 4th:

Each day features a morning packed with inspiring talks followed by an afternoon of practical hands-on workshops. It’s the perfect blend!

As with last year, each day will be themed:

• 2 June 2026: discovery day
• 3 June 2026: design day
• 4 June 2026: delivery day

You can come for a single day, but for best value, you should come for all three days.

I’m starting to put the line-up together now—hoping to match the excellence of last year’s event—and I’ll start announcing speakers early in the new year.

But if you trust me, then I highly recommend getting a super-early bird ticket now. They’ll only be available for another couple of weeks. You get a significant discount if you buy now.

Oh, and while I’m in the process of putting the line-up together, you should know that you can submit a talk or workshop proposal:

We always pay ALL our speakers for their time as well as covering the cost of accommodation and economy travel.

Don’t be shy! Pitch early, pitch often.

(That said, I wouldn’t recommend pitching a talk that focuses on “AI”. It’s not just that the bubble will probably have burst by the time UX London rolls around, it’s also that UX London doesn’t tend to focus on tools, whether they’re graphic design tools like Figma or generative tools like whatever people are using to turbo-charge their output of slop. If you’ve got a case study you want to talk about that happened to use some “AI” tool, great! But don’t make that the focus of the talk. Tell me about the problem and the solution.)

I’m very happy to announce that the one and only Jake Jaffa-The-Cake Archibald will be speaking at Web Day Out!

Given the agenda for this event, I think you’ll agree that Jake is a perfect fit. He’s been at the forefront of championing user-centred web standards, writing specs and shipping features in browsers.

Along the way he’s also created two valuable performance tools that I use all the time: SVGOMG and Squoosh, which has a permanent place in my dock—if you need to compress images, I highly recommend adding this progressive web app to your desktop.

He’s the man behind service workers and view transitions—two of the most important features for making websites first-class citizens on any device.

So what will he talk about at Web Day Out? Image formats? Offline functionality? Smooth animations? Something else entirely?

All will be revealed soon. In the meantime, grab yourself a ticket to Web Day Out—it’s just £225+VAT—and I’ll see you in Brighton on Thursday, 12 March 2026!

A bunch of the UX London speakers have been saying very nice things about the event over on LinkedIn. I’m going to quote a few of them for my future self to look at when I’m freaking out about curating the next event…

Valentina D’Efilippo:

Still buzzing … UX London smashed all expectations!

Huge shoutout to Jeremy Keith and the entire Clearleft team for their tireless efforts in making this event truly special. Three days packed with inspiration, insights, and true gems – I left feeling inspired, grateful, and already looking forward to next year’s event!

Eleni Beveratou:

Huge thanks to my fellow speakers for the inspiring talks, and to the team at Clearleft (Jeremy Keith, Louise Ash, and so many more!) for putting together such a brilliant event.

Videha Sharma:

I’ve loved learning and sharing this week! Feeling super inspired and looking forward to building new friendships!

Carolina Greno:

Last week in UX London I got to witness event planning mastery, I was in awe. Things ran smoothly and people were united under a premise: to share knowledge and build community.

This doesn’t happen by chance, it’s the mastery that pros like Jeremy and Louise bring to the table.

Sayani Mitra

Bold, thought-provoking talks. Hands-on workshops that challenged and stretched thinking. And a real sense of community that reminded me why spaces like this matter so much.

Nina Mathilde Dyrberg:

The conference was packed with inspiration, thoughtful conversations, and a strong focus on accessibility and inclusivity. Thank you Luke Hay, Jeremy Keith, Louise Ash, and the whole Clearleft team for creating such a welcoming and inspiring space!

Craig Abbott:

Jeremy Keith, Richard Rutter, Louise Ash, Chris How, Sophie Count, Luke Hay and the rest of Clearleft, take a bow! Hands down one of the best conference experiences I’ve had!

The curation was excellent, the talks complimented each other so well, it was almost like we’d all met up and rehearsed it beforehand!

ÌníOlúwa Abíódún:

A huge thank you to Jeremy Keith, Louise Ash and the Clearleft team for the opportunity and the brilliant conference you’ve put together.

It’s been inspiring to experience every moment of it.

Laura Dantonio:

Shoutout to the organisers for curating such a rich experience—3 themed days focused on Discovery, Design, and Delivery.

We remember through stories. And this event was full of them. Already looking forward to next year.

And I’m just going to quote Rachel Rosenson’s post in its entirety:

Spoke at UXLondon last week—and while the talks were great, it was something off-stage that really stuck with me.

After the Day 1 talks wrapped, a bunch of us speakers grabbed a drink, and someone pointed out: Every single speaker that day—every one—was a woman. 5 talks. 4 workshops. All women.

And it wasn’t a “Women in Tech” day. It was just… the conference.

No one made a fuss. No banners. No “look at us go!”

Just incredible women, giving incredible talks, like it was the most normal thing in the world. (Spoiler: it should be.)

Jeremy Keith mentioned how frustrating it is that all-male line-ups are still so common—and how important it is to actively design for inclusion. Major props to Jeremy and the Clearleft team for curating a line-up that was intentional without performativity.

It was refreshing. No tokenism. No checkbox energy. Just great voices on great stages. And a big honor to be one of them.

UX London happened last week.

Working on an event is a weird kind of project. You spend all your time and effort on something that is then over in the blink of an eye.

I’d been preparing for this all year. 95% of my work happened before the event—curating the line-up, planning each day. There wasn’t all that much for me to do at the event itself other than introduce the speakers and chat with the attendees.

Maybe it was because there was very little left in my control, but the night before the event I found myself feeling really anxious and nervous. I was pretty sure the line-up was excellent, but anything could happen. I really wanted everyone to have a great time, but at that point, there wasn’t much more I could do.

Then the first day started. Every talk was superb. Everyone got really stuck into their workshops. By the end of the day, people were buzzing about what a great time they’d had.

My nervousness was easing. But that was only one day of three.

The second day was just as good. Again, every talk was superb. I began to suspect that the first day wasn’t just a fluke.

The third day confirmed it. Three days of top-notch talks—nary a dud in the whole line-up!

It was, dare I say it, the best UX London yet. Not just because of the talks and workshops. The attendees were absolutely lovely! There was a really good buzz throughout.

By the end of the event I felt a huge sense of relief.

For this year’s UX London, I put a lot of time and effort into curating the line-up. There were some safe bets. There were some risky bets. They all paid off.

I’m incredibly grateful to all of the fantastic speakers and workshop hosts who really gave it their all. And I’m so, so grateful to everyone who came. It’s a tough time for events right now, and I really appreciate every single person who made it to this year’s UX London. Thank you!

The only downside to pouring my heart and soul into this year’s line-up is that I left nothing in the tank for next year. I’m already starting to worry—how am I going to top UX London 2025?

I don’t use large language models. My objection to using them is ethical. I know how the sausage is made.

I wanted to clarify that. I’m not rejecting large language models because they’re useless. They can absolutely be useful. I just don’t think the usefulness outweighs the ethical issues in how they’re trained.

Molly White came to the same conclusion:

The benefits, though extant, seem to pale in comparison to the costs.

Rich has similar thoughts:

What I do know is that I find LLMs useful on occasion, but every time I use one I die a little inside.

I genuinely look forward to being able to use a large language model with a clear conscience. Such a model would need to be trained ethically. When we get a free-range organic large language model I’ll be the first in line to use it. Until then, I’ll abstain. Remember:

You don’t get companies to change their behaviour by rewarding them for it. If you really want better behaviour from the purveyors of generative tools, you should be boycotting the current offerings.

Still, in anticipation of an ethical large language model someday becoming reality, I think it’s good for me to have an understanding of which tasks these tools are good at.

Prototyping seems like a good use case. My general attitude to prototyping is the exact opposite to my attitude to production code; use absolutely any tool you want and prioritise speed over quality.

When it comes to coding in general, I think Laurie is really onto something when he says:

Is what you’re doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it’s probably going to be great at it. If you’re asking it to convert into a roughly equal amount of text it will be so-so. If you’re asking it to create more text than you gave it, forget about it.

In other words, despite what the hype says, these tools are far better at transforming than they are at generating.

Iris Meredith goes deeper into this distinction between transformative and compositional work:

Compositionality relies (among other things) on two core values or functions: choice and precision, both of which are antithetical to LLM functioning.

My own take on this is that transformative work is often the drudge work—take this data dump and convert it to some other format; take this mock-up and make a disposable prototype. I want my tools to help me with that.

But compositional work that relies on judgement, taste, and choice? Not only would I not use a large language model for that, it’s exactly the kind of work that I don’t want to automate away.

Transformative work is done with broad brushstrokes. Compositional work is done with a scalpel.

Large language models are big messy brushes, not scalpels.

Meetings can be frustrating. But they don’t have to be.

A lot of the frustration comes from unmet expectations. You go into the meeting expecting one outcome, and when it doesn’t materialise, you declare the meeting a waste of time. But had you gone into that same meeting with different expectations, perhaps you would emerge from it in a happier state.

We were talking about this at Clearleft recently and I suggested that a simple little taxonomy of meetings might be a good starting point for avoiding frustration.

Divergent meetings

In a divergent meeting the goal is to generate ideas. These meetings often happen early in a project.

Quantity matters more than quality. Plenty of “yes, and…” rather than “no, but…” to create lots of suggestions. This is not the meeting to point out potential problems with the suggestions.

Convergent meetings

In a convergent meeting the goal is to come to a decision.

The meeting might begin with lots of options on the table. They need to be winnowed down. Poke at them. Dissect them. Ideally dismiss lots of them.

This is not the time to introduce new ideas—save that for a divergent meeting.

Just having those two categories alone could save you a lot of grief. The last thing you want is someone participating in a convergent meeting who thinks it’s a divergent meeting (or the other way around).

Those two categories account for the majority of meetings, but there’s one more category to consider…

Chemistry meetings

In a chemistry meeting there is no tangible output. The goal is to get to know one another.

In a large organisation this might be when multiple departments are going to work together on a project. At an agency like Clearleft, a chemistry meeting between us and the client team is really useful at the beginning of our partnership.

Again, the key thing is expectations. If there are people in a chemistry meeting who are expecting to emerge with a framework or a list or any kind of output, they’re going to be frustrated. But if everyone knows it’s a chemistry meeting there’s no expectation that any decisions are going to be made.

There you have it. A tiny taxonomy of meetings:

1. divergent
2. convergent
3. chemistry

This tiny taxonomy won’t cover every possible kind of meeting, but it probably covers 90% of them.

Ideally every meeting should be categorised in advance so that everyone’s going in with the same expectations.

If you find yourself trying to categorise a meeting and you think “Well, it’s mostly convergent, but there’s also this divergent aspect…” then you should probably have two separate shorter meetings instead.

And if you’re trying to categorise a meeting and you find yourself thinking, “This meeting is mostly so I can deliver information” …that meeting should be an email.

It’s just over one month until UX London. You should grab a ticket if you haven’t already!

The format of UX London is quite special. While the focus of each day is different—discovery, design, and delivery—each day unfolds like this…

There are four talks in the morning. You get your brain filled with ideas and learn from fantastic speakers. It’s a single track—everyone’s getting the same shared experience.

Then after a lunch, you choose from one of four workshops. Whatever you choose, it’s going to be hands-on. You can leave your laptop at home.

A day of listening to talks could get exhausting. A workshop that lasts all day could be even more exhausting. But somehow by splitting the day between both activities, the energy level is just right!

That said, we don’t want the day to end with everyone spread across four different workshop rooms. That’s why there’s one final talk at the end of each day.

These closing talks are a bit different to the morning talks. Whereas the focus of the morning talks is on practical skills that you can apply straight away, the closing talks are an opportunity to sit back and have your mind expanded. They’ll be fun and thought-provoking.

Paula Zuccotti is closing out day one with a talk about two of her projects: Every Thing We Touch and Future Archeology:

This talk invites audiences to reconsider the meaning of the objects they encounter every day and reflect on what their possessions might reveal about who we are and what we value, both now and in the years to come.

Sarah Hyndman will wrap up day two with a fun interactive talk about your senses:

Join a live expedition into our inner world to explore why we see, feel and remember.

Finally, Rachel Coldicutt is going to finish UX London with a rallying cry:

Introducing the Society of Hopeful Technologists and discussing how, in modern technology development, your practice is probably more political than you realise.

I can’t wait! Get yourself a ticket for a day or for all three days.

And as a little thank you for tolerating my excitement, use the discount code JOINJEREMY to get 20% off your ticket.

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.

• Day one on Tuesday, 10 June is discovery day.
• Day two on Wednesday, 11 June is design day.
• Day three on Thursday, 12 June is deliver day.

Head on over to the website to get all the details and then get your discounted ticket.

See you there!

For the past couple of years, myself and Jessica have been going to the Belfast Tradfest in the Summer. It’s an excellent event with great workshops, sessions, and concerts. And it helps that Belfast is such a lovely city to spend a week in.

What struck me the first time we were participating in workshops there was the great mix of age ranges. It always warms my heart to see young people getting really into the music.

Then I found out about their bursary sponsorship scheme:

For many young musicians, financial barriers stand in the way of this invaluable experience. Your support can make a real difference by sponsoring a bursary that covers the cost of tuition for a deserving student.

Last year, I decided to forego one month’s worth of donations to The Session—the contributions that help cover the costs of hosting, newsletters, geocoding, and so on. Instead the money went towards bursary sponsorships for Belfast Tradfest.

It was a great success that managed to cover places for quite a few young musicians.

So we’re doing it again.

Normally, I wouldn’t mention the ins-and-outs of TheSession.org over here on adactio.com but I thought you might like to partake in this year’s fund drive:

For the month of April 2025, any donations made to The Session will go towards bursary sponsorships for young musicians to attend workshops at this year’s Belfast Trad Fest:

thesession.org/donate

Maybe you’ve liked something I’ve written here. Maybe you enjoyed Resilient Web Design, the free book I published online. You can also read HTML5 For Web Designers and Going Offline for free now too.

I’ve never asked for any recompense for my online ramblings, but if you’ve ever wanted to drop me some money to thank me for something I’ve put out there, now’s your chance.

Any contribution you make will go towards fostering the next generation of traditional Irish musicians, something that’s very dear to my heart.

Dan wrote an interesting post with a somewhat clickbaity title; This Competition Exposed How AI is Reshaping Design:

I watched two designers go head-to-head in a high-speed battle to create the best landing page in 45 minutes. One was a seasoned pro. The other was a non-designer using AI.

If you can ignore the title (and the fact that Dan still actively posts on Twitter; something I find very hard to ignore), then there’s a really thoughtful analysis in there.

It’s less about one platform or tool vs. another more than it is a commentary on how design happens, and whether or not that’s changing in a significant way.

In particular, there’s a very revealing graph that shows the pros and cons of both approaches.

There’s no doubt about it, using a generative large language model helped a non-designer to get past the blank page. But it was less useful in subsequent iterations that rely on decision-making:

I’ve said it before and I’ll say it again: design is deciding. The best designers are the best deciders.

Dan finishes by saying that what he’d really like to see is an experienced designer/decider using these tools to turbo-boost their process:

AI raises the floor for non-designers. But can it raise the ceiling for designers?

Meanwhile, Matt has been writing about Vibe-designing. Matt is an experienced designer, but he’s not experienced with Figma. He’s found that he can work around that using a large language model:

Where in the past 30 years I might have had to cajole a more technically adept colleague into making something through sketches, gesticulating and making sound effects – I open up a Claude window and start what-iffing.

The “vibe” part of the equation often defaults to the mean, which is not a surprise when you think about what you’re asking to help is a staggeringly-massive machine for producing generally-unsurprising satisfactory answers quickly. So, you look at the output as a basis for the next sketch, and the next sketch and quickly, together, you move to something more novel as a result.

Interesting! Just as Dan insisted, the important work is making the decision and moving on to the next stage. If the actual outputs at each stage are mediocre, that seems to be okay, as long as they’re just good enough to inform a go/no-go decision.

This certainly seems more centaur-like than the usual boring uses of large language models to simply do what people are already doing.

Rich gets at something similar when he talks about using large language models for prototyping, where it’s okay if the code is kind of shitty:

If all you need is crappy code to try out a concept or a solution, then an LLM might well enable you (the designer) to do that.

Mind you, even if you do end up finding useful and appropriate ways to use these tools, you’re still using a tool built on exploitation and unfairness:

It’s hard (and reckless) to ignore the heartfelt and cogent perspective laid out by Miriam on the role of AI companies in the current geopolitical crisis:

When eugenics-obsessed billionaires try to sell me a new toy, I don’t ask how many keystrokes it will save me at work. It’s impossible for me to discuss the utility of a thing when I fundamentally disagree with the purpose of it.

Check it out—here’s the line-up for UX London 2025!

This is going to be so good! Grab a ticket if you haven’t got one yet.

UX London takes place over three days, from June 10th to 12th at a fantastic venue in the heart of the city. To get the full experience, you should come for all three days. But you can also get a ticket for individual days. Each day has a focus, and when you put them all together, the whole event mirrors the design process:

1. Day one: Discovery
2. Day two: Design
3. Day three: Delivery

Each day features a morning of talks, followed by an afternoon of workshops. The talks are on a single track; four consecutive half-hour presentations to get you inspired. Then after lunch, you choose from one of four workshops. All the workshops are two and half hours long and very hands-on. No laptop required.

On discovery day you’ll have talks in the morning about research, content design, strategy and evaluating technology, followed by workshops on discovery and definition and behavioural design.

On design day there’ll be talks on interface design, a healthcare case study, inclusive design, and typography, followed by workshops in the afternoon on data visualisation and ethics.

Finally on delivery day you’ll get talks on conversion design, cross-team collaboration, convincing stakeholders, and improving design critiques, followed by workshops on facilitating workshops and getting better at public speaking.

Every workshop is repeated on another day so you’ll definitely get the chance to attend the one you want.

Oh, and at the end of every day there’ll be a closing keynote. Those are yet to be revealed, but I can guarantee they’re going to be top-notch!

Right now you can get early-bird tickets for all three days, or individual days. That changes from March 15th, when the regular pricing kicks in—a three-day ticket will cost £200 more. So I’d advise you to get your ticket now.

If you need to convince your boss, show them this list of reasons to attend.

See you there!

I have a feeling that 2025 is going to be a year of reflection for me. It’s such a nice round number, 25. One quarter of a century.

That’s also how long myself and Jessica have been married. Our wedding anniversary was last week.

Top tip: if you get married in year ending with 00, you’ll always know how long ago it was. Just lop off the first 2000 years and there’s the number.

As well as being the year we got married (at a small ceremony in an army chapel in Arizona), 2000 was also the year we moved from Freiburg to Brighton. I never thought we’d still be here 25 years later.

2005 was twenty years ago. A lot of important events happened that year. I went to South by Southwest for the first time and met people who became lifelong friends (including some dear friends no longer with us).

I gave my first conference talk. We had the first ever web conference in the UK. And myself, Rich, and Andy founded Clearleft. You can expect plenty of reminiscence and reflection on the Clearleft blog over the course of this year.

2010 was fifteen years ago. That’s when Jessica and I moved into our current home. For the first time, we were paying off a mortgage instead of paying a landlord. But I can’t bring myself to consider us “homeowners” at that time. For me, we didn’t really become homeowners until we paid that mortgage off ten years later.

2015 was ten years ago. It was relatively uneventful in the best possible way.

2020 was five years ago. It was also yesterday. The Situation was surreal, scary and weird. But the people I love came through it intact, for which I’m very grateful.

Apart from all these anniversaries, I’m not anticipating any big milestones in 2025. I hope it will be an unremarkable year.

The Session has been online for over 20 years. When you maintain a site for that long, you don’t want to be relying on third parties—it’s only a matter of time until they’re no longer around.

Some third party APIs are unavoidable. The Session has maps for sessions and other events. When people add a new entry, they provide the address but then I need to get the latitude and longitude. So I have to use a third-party geocoding API.

My code is like a lesson in paranoia: I’ve built in the option to switch between multiple geocoding providers. When one of them inevitably starts enshittifying their service, I can quickly move on to another. It’s like having a “go bag” for geocoding.

Things are better on the client side. I’m using other people’s JavaScript libraries—like the brilliant abcjs—but at least I can self-host them.

I’m using Leaflet for embedding maps. It’s a great little library built on top of Open Street Map data.

A little while back I linked to a new project called OpenFreeMap. It’s a mapping provider where you even have the option of hosting the tiles yourself!

For now, I’m not self-hosting my map tiles (yet!), but I did want to switch to OpenFreeMap’s tiles. They’re vector-based rather than bitmap, so they’re lovely and crisp.

But there’s an issue.

I can use OpenFreeMap with Leaflet, but to do that I also have to use the MapLibre GL library. But whereas Leaflet is 148K of JavaScript, MapLibre GL is 800K! Yowzers!

That’s mahoosive by the standards of The Session’s performance budget. I’m not sure the loveliness of the vector maps is worth increasing the JavaScript payload by so much.

But this doesn’t have to be an either/or decision. I can use progressive enhancement to get the best of both worlds.

If you land straight on a map page on The Session for the first time, you’ll get the old-fashioned bitmap map tiles. There’s no MapLibre code.

But if you browse around The Session and then arrive on a map page, you’ll get the lovely vector maps.

Here’s what’s happening…

The maps are embedded using an HTML web component called embed-map. The fallback is a static image between the opening and closing tags. The web component then loads up Leaflet.

Here’s where the enhancement comes in. When the web component is initiated (in its connectedCallback method), it uses the Cache API to see if MapLibre has been stored in a cache. If it has, it loads that library:

caches.match('/path/to/maplibre-gl.js')
.then( responseFromCache => {
    if (responseFromCache) {
        // load maplibre-gl.js
    }
});

Then when it comes to drawing the map, I can check for the existence of the maplibreGL object. If it exists, I can use OpenFreeMap tiles. Otherwise I use the old Leaflet tiles.

But how does the MapLibre library end up in a cache? That’s thanks to the service worker script.

During the service worker’s install event, I give it a list of static files to cache: CSS, JavaScript, and so on. That includes third-party libraries like abcjs, Leaflet, and now MapLibre GL.

Crucially this caching happens off the main thread. It happens in the background and it won’t slow down the loading of whatever page is currently being displayed.

That’s it. If the service worker installation works as planned, you’ll get the nice new vector maps. If anything goes wrong, you’ll get the older version.

By the way, it’s always a good idea to use a service worker and the Cache API to store your JavaScript files. As you know, JavaScript is unduly expensive to performance; not only does the JavaScript file have to be downloaded, it then has to be parsed and compiled. But JavaScript stored in a cache during a service worker’s install event is already parsed and compiled.

I wrote a book about service workers. It’s called Going Offline. It was first published by A Book Apart in 2018. Now it’s available to read for free online.

If you want you can read the book as a PDF, an ePub, or .mobi, but I recommend reading it in your browser.

Needless to say the web book works offline. Once you go to goingoffline.adactio.com you can add it to the homescreen of your mobile device or add it to the dock on your Mac. After that, you won’t need a network connection.

The book is free to read. Properly free. Not the kind of “free” where you have to supply an email address first. Why would I make you go to the trouble of generating a burner email account?

The site has no analytics. No tracking. No third-party scripts of any kind whatsover. By complete coincidence, the site is fast. Funny that.

For the styling of this web book, I tweaked the stylesheet I used for HTML5 For Web Designers. I updated it a little bit to use logical properties, some fluid typography and view transitions.

In the process of converting the book to HTML, I got reaquainted with what I had written almost seven years ago. It was kind of fun to approach it afresh. I think it stands up pretty darn well.

Ethan wrote about his feelings when he put two of his books online, illustrated by that amazing photo that always gives me the feels:

I’ll miss those days, but I’m just glad these books are still here. They’re just different than they used to be. I suppose I am too.

Anyway, if you’re interested in making your website work offline, have a read of Going Offline. Enjoy!

Is it too early to start planning for 2025 already? Perhaps. But you might want to add some dates to your calender:

June 10th, 11th, and 12th, 2025.

That’s when UX London will return!

It’ll be be back in CodeNode. That’s the venue we tried for the first time this year and it worked out really well.

You can look forward to three days of UX talks and workshops:

1. Tuesday, June 10th is Discovery Day—user research, content strategy, and planning.
2. Wednesday, June 11th is Design Day—interaction design, accessibility, and interface design.
3. Thursday, June 12th is Delivery Day—iteration, design ops, and cross-team collaboration.

I realise that the alliteration of discovery, design, and delivery is a little forced but you get the idea. The flow of the event will follow the process of a typical design project.

The best way to experience UX London is to come for all three days, but each day also works as a standalone event.

I’m now starting the process of curating the line-up for each day: a mix of inspiring talks and hands-on workshops. If you trust me, you can get your ticket already at the super early-bird price.

If you reckon you’d be a good addition to the line-up, here’s a form you can fill out.

Now, I’ll be up-front here: if you’re a typical white dude like me, you’re not going to be top of the pile. My priority for UX London is creating a diverse line-up of speakers.

So if you’re not a typical white dude like me and you’ve ever thought about giving a conference talk, fill out that form!

If you don’t fancy speaking, but you want to see your company represented at UX London, check out our sponsorship options.

If you don’t want to speak and you don’t want to sponsor, but you want to be at the best design conference of 2025, get your ticket now.

Looking back on ten years of codebar Brighton, I’m remembering how much I got out of being a coach.

Something that I realised very quickly is that there is no one-size-fits-all approach to coaching. Every student is different so every session should adapt to that.

Broadly speaking I saw two kinds of students: those that wanted to get results on screen as soon as possible without worrying about the specifics, and those who wanted to know why something was happening and how it worked. In the first instance, you get to a result as quickly as possible and then try to work backwards to figure out what’s going on. In the second instance, you build up the groundwork of knowledge and then apply it to get results.

Both are equally valid approaches. The only “wrong” approach as a coach is to try to apply one method to someone who’d rather learn the other way.

Personally, I always enjoyed the groundwork-laying of the second approach. But it comes with challenges. Because the results aren’t yet visible, you have to do extra work to convey why the theory matters. As a coach, you need to express infectious enthusiasm.

Think about the best teachers you had in school. I’m betting they displayed infectious enthusiasm for the subject matter.

The other evergreen piece of advice is to show, don’t tell. Or at the very least, intersperse your telling with plenty of showing.

Bret Viktor demonstrates this when he demonstrates scientific communication as sequential art:

This page presents a scientific paper that has been redesigned as a sequence of illustrations with captions. This comic-like format, with tightly-coupled pictures and prose, allows the author to depict and describe simultaneously — show and tell.

It works remarkably well. I remember how well it worked when Google first launched their Chrome web browser. They released a 40 page comic book illustrated by Scott McCloud. There is no way I would’ve read a document that long about how browser engines work, but I read that comic cover to cover.

This visual introduction to machine learning is another great example of simultaneous showing and telling.

So showing augments telling. But interactivity can augment showing.

Here are some great examples of interactive explainers:

• Cameras and Lenses by Bartosz Ciechanowski,
• An Interactive Guide to CSS Grid by Josh W Comeau,
• CSS :has() Interactive Guide by Ahmad Shadeed,
• Pizza Exchange Rate by Nathan Yau, and
• just about everything by Nicky Case.

Lea describes what can happen when too much theory comes before practice:

Observing my daughter’s second ever piano lesson today made me realize how this principle extends to education and most other kinds of knowledge transfer (writing, presentations, etc.). Her (generally wonderful) teacher spent 40 minutes teaching her notation, longer and shorter notes, practicing drawing clefs, etc. Despite his playful demeanor and her general interest in the subject, she was clearly distracted by the end of it.

It’s easy to dismiss this as a 5 year old’s short attention span, but I could tell what was going on: she did not understand why these were useful, nor how they connect to her end goal, which is to play music.

The codebar website has some excellent advice for coaches, like:

• Do not take over the keyboard! This can be off-putting and scary.
• Encourage the students to type and not copy paste.
• Explain that there are no bad questions.
• Explain to students that it’s OK to make mistakes.
• Assume that anyone you’re teaching has no knowledge but infinite intelligence.

Notice how so much of the advice focuses on getting the students to do things, rather than have them passively sit and absorb what the coach has to say.

Lea also gives some great advice:

1. Always explain why something is useful. Yes, even when it’s obvious to you.
2. Minimize the amount of knowledge you convey before the next opportunity to practice it. For non-interactive forms of knowledge transfer (e.g. a book), this may mean showing an example, whereas for interactive ones it could mean giving the student a small exercise or task.
3. Prefer explaining in context rather than explaining upfront.

It’s interesting that Lea highlights the advantage of interactive media like websites over inert media like books. The canonical fictional example of an interactive explainer is the Young Lady’s Illustrated Primer in Neal Stephenson’s novel The Diamond Age. Andy Matuschak describes its appeal:

When it wants to introduce a conceptual topic, it begins with concrete hands-on projects: Turing machines, microeconomics, and mitosis are presented through binary-coding iron chains, the cipher’s market, and Nell’s carrot garden. Then the Primer introduces extra explanation just-in-time, as necessary.

That’s not how learning usually works in these domains. Abstract topics often demand that we start with some necessary theoretical background; only then can we deeply engage with examples and applications. With the Primer, though, Nell consistently begins each concept by exploring concrete instances with real meaning to her. Then, once she’s built a personal connection and some intuition, she moves into abstraction, developing a fuller theoretical grasp through the Primer’s embedded books.

(Andy goes on to warn of the dangers of copying the Primer too closely. Its tricks verge on gamification, and its ultimate purpose isn’t purely to educate. There’s a cautionary tale there about the power dynamics in any teacher/student relationship.)

There’s kind of a priority of constituencies when it comes to teaching:

Consider interactivity over showing over telling.

Thinking back on all the talks I’ve given, I start to wonder if I’ve been doing too much telling and showing, but not nearly enough interacting.

Then again, I think that talks aren’t quite the same as hands-on workshops. I think of giving a talk as being more like a documentarian. You need to craft a compelling narrative, and illustrate what you’re saying as much as possible, but it’s not necessarily the right arena for interactivity.

That’s partly a matter of scale. It’s hard to be interactive with every person in a large audience. Marcin managed to do it but that’s very much the exception.

Workshops are a different matter though. When I’m recruiting hosts for UX London workshops I always encourage them to be as hands-on as possible. A workshop should not be an extended talk. There should be more exercises than talking. And wherever possible those exercises should be tactile, ideally not sitting in front of a computer.

My own approach to workshops has changed over the years. I used to prepare a book’s worth of material to have on hand, either as one giant slide deck or multiple decks. But I began to realise that the best workshops are the ones where the attendees guide the flow, not me.

So now I show up to a full-day workshop with no slides. But I’m not unprepared. I’ve got decades of experience (and links) to apply during the course of the day. It’s just that instead of trying to anticipate which bits of knowledge I’m going to need to convey, I apply them in a just-in-time manner as and when they’re needed. It’s kind of scary, but as long as there’s a whiteboard to hand, or some other way to illustrate what I’m telling, it works out great.