Journal tags: work

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.

My stint as one of the hosts of CSS Day went very well indeed. I enjoyed myself and people seemed to like the cut of my jib.

During the event there was a real buzz on Mastodon, which was heartening to see. I was beginning to worry that hashtagging events was going to be collatoral damage from Elongate, but there was plenty of conference-induced FOMO to be experienced on the fediverse.

The event itself was, as always, excellent. Both in terms of content and organisation.

Some themes emerged during CSS Day, which I always love to see. These emergent properties are partly down to curation and partly down to serendipity.

The last few years of CSS Day have felt like getting a firehose of astonishing new features being added to the language. There was still plenty of cutting-edge stuff this year—masonry! anchor positioning!—but there was also a feeling of consolidation, asking how to get all this amazing new stuff into our workflows.

Matthias’s opening talk on day one and Stephen’s closing talk on the same day complemented one another perfectly. Both managed to inspire while looking into the nitty-gritty practicalities of the web design process.

It was, astoundingly, Matthias’s first ever conference talk. I have no doubt it won’t be the last—it was great!

I gave Stephen a good-natured roast in my introduction, partly because it was his birthday, partly because we’re old friends, but mostly because it was enjoyable for me to watch him squirm. Of course his talk was, as always, superb. Don’t tell him, but he might be one of my favourite speakers.

The topic of graphic design tools came up more than once. It’s interesting to see how the issues with them have changed. It used to be that design tools—Photoshop, Sketch, Figma—were frustrating because they were writing cheques that CSS couldn’t cash. Now the frustration is the exact opposite. Our graphic design tools aren’t capable of the kind of fluid declarative design we can now accomplish in web browsers.

But the biggest rift remains not with tools or technologies, but with people and mindsets. Our tools can reinforce mindsets but the real divide happens in how different people approach CSS.

Both Josh and Kevin get to the heart of this in their tremendous tutorials, and that was reflected in their talks. They showed the difference between having the bare minimum understanding of CSS in order to get something done as quickly as possible, and truly understanding how CSS works in order to open up a world of possibilities.

For people in the first category, Sarah Dayan was there to sing the praises of utility-first CSS AKA atomic CSS. I commend her bravery!

During the Q&A, I restrained myself from being too Paxmanish. But I did have l’esprit d’escalier afterwards when I realised that the entire talk—and all the answers afterwards—depended on two mutually-incompatiable claims:

1. The great thing about atomic CSS is that it’s a constrained vocabulary so your team has to conform, and
2. The other great thing about it is that it’s utility-first, not utility-only so you can break out of it and use regular CSS if you want.

Insert .gif of character from The Office looking to camera.

Most of the questions coming in during the Q&A reflected my own take: how about we use utility classes for some things, but not all things. Seems sensible.

Anyway, regardless of what I or anyone else thinks about the substance of what Sarah was saying, there was no denying that it was a great presentation. They were all great presentations. That’s unusual, and I say that as a conference organiser as well as an attendee. Everyone brings their A-game to CSS Day.

Mind you, it is exhausting. I say it every year, but it always feels like one talk too many. Not that any individual talk wasn’t good, but the sheer onslaught of deep dives into the innards of CSS has my brain exploding before the day is done.

A highlight for me was getting to introduce Fantasai’s talk on the design principles of CSS, which was right up my alley. I don’t think most people realise just how much we owe her for her years of work on standards. The web would be in a worse place without the Herculean work she’s done behind the scenes.

Another highlight was getting to see some of the students I met back in March. They were showing some of their excellent work during the breaks. I find what they’re doing just as inspiring as the speakers on stage.

In fact, when I was filling in the post-conference feedback form, there was a question: “Who would you like to see speak at CSS Day next year?” I was racking my brains because everyone I could immediately think of has already spoken at some point. So I wrote, “It would be great to see some of those students speaking about their work.”

I think it would be genuinely fascinating to get their perspective on what we consider modern CSS, which to them is just CSS.

Either way I’ll back next year for sure.

It’s funny, but usually when a conference is described as “inspiring” it’s because it’s tackling big galaxy-brain questions. But CSS Day is as nitty-gritty as it gets and I found it truly inspiring. Like, I couldn’t wait to open up my laptop and start writing some CSS. That kind of inspiring.

After I wrote positively about the speculation rules API I got an email from David Cizek with some legitimate concerns. He said:

I think that this kind of feature is not good, because someone else (web publisher) decides that I (my connection, browser, device) have to do work that very often is not needed. All that blurred by blackbox algorithm in the browser.

That’s fair. My hope is that the user will indeed get more say, whether that’s at the level of the browser or the operating system. I’m thinking of a prefers-reduced-data setting, much like prefers-color-scheme or prefers-reduced-motion.

But this issue isn’t something new with speculation rules. We’ve already got service workers, which allow the site author to unilaterally declare that a bunch of pages should be downloaded.

I’m doing that for Resilient Web Design—when you visit the home page, a service worker downloads the whole site. I can justify that decision to myself because the entire site is still smaller in size than one article from Wired or the New York Times. But still, is it right that I get to make that call?

So I’m very much in favour of browsers acting as true user agents—doing what’s best for the user, even in situations where that conflicts with the wishes of a site owner.

Going back to speculation rules, David asked:

Do we really need this kind of (easily turned to evil) enhancement in the current state of (web) affairs?

That question could be asked of many web technologies.

There’s always going to be a tension with any powerful browser feature. The more power it provides, the more it can be abused. Animations, service workers, speculation rules—these are all things that can be used to improve websites or they can be abused to do things the user never asked for.

Or take the elephant in the room: JavaScript.

Right now, a site owner can link to a JavaScript file that’s tens of megabytes in size, and the browser has no alternative but to download it. I’d love it if users could specify a limit. I’d love it even more if browsers shipped with a default limit, especially if that limit is related to the device and network.

I don’t think speculation rules will be abused nearly as much as client-side JavaScript is already abused.

UX London runs for three days, from June 18th to 20th. If you can, you should get a ticket for all three days. But if you can’t, you can get a one-day ticket. Think of each individual day as being its own self-contained conference.

The flow of the three-day event kind of mimics the design process itself. It starts with planning and research. Then it gets into the nitty-gritty product design details. Then it gets meta…

Day three, Thursday, June 20th is about design systems and design ops.

Maintenance matters, not just for the products and services you’re designing, but for the teams you’re designing with. You can expect a barrage of knowledge bombs on alignment and collaboration.

The bombardment commences with four great talks in the morning.

1. Brad Frost kicks things off with the question is atomic design dead? Brad will show you how to imagine what a global design system might look like.
2. Alicia Calderón is going to be talking about unlocking collaboration . Alicia will show you how to use a framework for creating lasting aligment between developers and designers.
3. Benaz Irani will be speaking about empathy overload. Benaz will show you how to strike a balance between compassion and confidence within your team.
4. Kara Kane is going to talk about why UX building blocks need standards. Kara will show you how to use standards to enable adoption and contribution to design systems.

After the lunch break you’ll have your pick of four superb workshops. It’s not an easy choice.

1. Brad Frost is not only giving a talk in the morning, he’s also leading an afternoon workshop on the design system ecosystem. Brad will show you how to unpack the many layers of the design system layer cake so you can deliver sturdy user interfaces and help teams work better together.
2. Stéphanie Walter is running a workshop on designing adaptive reusable components and pages . Stéphanie will show you how to plan your content and information architecture to help build more reusable components.
3. Tom Kerwin will be giving a workshop on multiverse mapping. Tom will show you how to pin down your product strategy and to align your team around the stuff that matters.
4. Luke Hay is running a workshop on bridging the gap between Research and Design. Luke will show you how to take practical steps to ensure that designers and researchers are working as a seamless team.

Finally we’ll finish the whole event with one last closing keynote. I’m very excited to announce who that’s going to be—I’ll only keep you on tenterhooks for a short while longer.

When step back and look at what’s on offer, day three of UX London looks pretty unmissable. If you work with a design system or heck, if you just work with other people, this is the day for you. So get your ticket now.

But be sure to use this discount code I’ve prepared just for you to get a whopping 20% off the ticket price: JOINJEREMY.

If you can’t make it to all three days of this year’s UX London, there’s always the option to attend a single day.

Day two is focused on product design. You know, the real meat’n’potatoes of working at the design coalface (to horribly mix my metaphors).

The day begins with four back-to-back practical talks.

1. John V Willshire gets the ball rolling with a big-picture talk on the product of design. John will show you how to think about futures rather than features.
2. Tshili Ndou follows on with her talk aboutvalidating features. Tschili will show you how to create high value products and avoid wasting money.
3. Wioleta Maj is up after the break with a talk on understanding the impact of design choices. Wioleta will show you how to identify who we are creating our designs for (and who we are not).
4. Harry Brignull closes out the morning with his call to action, Do Not Pass Go. Harry will show you how to get to grips with our industry’s failure to self-regulate when it comes to harmful design patterns.

After lunch, it’s decision time. Whereas the morning talks are sequential, the afternoon’s workshops run in parallel. You’ve got four excellent workshops to choose from.

1. Ben Sauer will be giving a workshop on the storytelling bridge . Ben will show you how to find your inner storyteller to turn your insights into narratives your stakeholders can understand quickly and easily.
2. Tom Kerwin will be giving a workshop on multiverse mapping. Tom will show you how to pin down your product strategy and to align your team around the stuff that matters.
3. Serena Verdenicci will be giving a workshop on behavioural intentions . Serena will show you how to apply a behavioural mindset to your work so you can create behaviour-change interventions.
4. Brad Frost will be giving a workshop on the design system ecosystem. Brad will show you how to unpack the many layers of the design system layer cake so you can deliver sturdy user interfaces and help teams work better together.

Finally there’s one last keynote talk at the end of the day. All will be revealed very soon, but believe me, it’s going to be a perfect finisher.

If a day of outstanding talks and workshops on product design sounds good to you, get your ticket now.

And just between you and me, here’s a discount code to get 20% of the ticket price: JOINJEREMY.

UX London is just two months away!

The best way to enjoy the event is to go for all three days but if that’s not doable for you, each individual day is kind of like a mini-conference with its own theme.

The theme on day one, Tuesday, June 18th is design research.

In the morning there are four fantastic talks.

1. Tom Kerwin kicks things off with his talk on pitch provocations. Tom will show you how to probe for what the market really wants with his fast, counterintuitive method.
2. Clarissa Gardner is giving a talk about ethics and safeguarding in UX research . Clarissa will show you how to uphold good practice without compromising delivery in a fast-paced environment.
3. Aleks Melnikova’s talk is all about demystifying inclusive research. Aleks will show you how to conduct research for a diverse range of participants, from recruitment and planning through to moderation and analysis.
4. Emma Boulton closes out the morning with her talk on meeting Product where they are. Emma will show you how to define a knowledge management strategy for your organisation so that you can retake your seat at the table.

After lunch you’ll take part in one of four workshops. Choose wisely!

1. Luke Hay is running a workshop on bridging the gap between research and design. Luke will show you how to take practical steps to ensure that designers and researchers are working as a seamless team.
2. Serena Verdenicci is running a workshop on behaviorual intentions. Serena will show you how to apply a behavioural mindset to your work so you can create behaviour-change interventions.
3. Stéphanie Walter is running a workshop on designing adaptive reusable components and pages. Stéphanie will show you how to plan your content and information architecture to help build more reusable components.
4. Ben Sauer is running a workshop on the storytelling bridge. Ben will show you how to find your inner storyteller to turn your insights into narratives your stakeholders can understand quickly and easily.

After your workshop there’s one final closing keynote to bring everyone back together. I’m keeping that secret for just a little longer, but trust me, it’s going to be inspiring—plenty to discuss at the drinks reception afterwards.

That’s quite a packed day. If design research is what you’re into, you won’t want to miss it. Get your ticket now.

Just to sweeten the deal and as a reward for reading all the way to the end, here’s a discount code you can use to get a whopping 20% off: JOINJEREMY.

Just look at who’s speaking at UX London this year! That’s a damned fine line-up, if I do say so myself. Which I do.

If you haven’t procured a ticket yet, allow me to gently remind you that early-bird ticket sales finish on March 14th. So if you want to avail of that bargain of a price, get in there now.

The event will be three days long. You can buy a ticket for all three days, or you can buy individual day tickets (but buying a three-day ticket works out cheaper per day).

The first day, Tuesday, June 18th, focuses on UX research.

The second day, Wednesday, June 19th, focuses on product design.

The third day, Thursday, June 20th, focuses on design ops and design systems.

Each day features a morning of inspiring talks and an afternoon of brilliant workshops. I’ll be adding titles and descriptions for all of them soon, but in the meantime, don’t dilly dally—get your ticket today!

Jessica and I spent last week working remotely. We always work remotely in the sense of not being in an office, but I mean we were remote from home too.

We’ve done this twice before. Once in Ortigia, Sicily and once in Cáceres, Spain. This time we were in Turin.

We had one day at the start of the trip to explore the city and do touristy things, checking out museums and such. After that we hunkered down in a very lovely and cosy AirBnB working each day.

I found it very productive. Maybe it’s a similar effect to going to a coffee shop to write—something about the change of scene encourages more of a flow state. The apartment was nice and quiet too so it wasn’t a problem when I needed to be on a call.

Best of all was what awaited at the end of each working day. We were staying in the Quadrilatero neighbourhood, famed for its aperitivo scene. Heck, there was a wonderful Vermouth bar literally across the street.

And after an aperitivo? Time to sample some Piedmontese cuisine. Bagna càuda! Vitello tonnato! Agnolotti! Panna cotta! We had some wonderful meals at restaurants like Consorzio, L’Acino, and Pautasso (a neighbourhood spot we went to on our last night that had the most perfectly convivial atmosphere you could imagine).

They say a change is as good as a rest. I certainly enjoyed this change of scene.

There’s something about going somewhere for a working week that feels very different to going somewhere primarily as a tourist. You get a different flavour of a place.

Cory has published the transcript of his talk at the Transmediale festival in Berlin. It’s all about enshittification, and what we can collectively do to reverse it.

He succinctly describes the process of enshittification like this:

First, platforms are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die.

More importantly, he describes the checks and balances that keep enshittification from happening, all of which have been dismantled over time: competition, regulation, self-help, and workers.

One of the factors that allows enshittification to proceed is a high switching cost:

Switching costs are everything you have to give up when you leave a product or service. In Facebook’s case, it was all the friends there that you followed and who followed you. In theory, you could have all just left for somewhere else; in practice, you were hamstrung by the collective action problem.

It’s hard to get lots of people to do the same thing at the same time.

We’ve seen this play out over at Twitter, where people I used to respect are still posting there as if it hasn’t become a cesspool of far-right racist misogyny reflecting its new owner’s values. But for a significant amount of people—including myself and anyone with a modicum of decency—the switching cost wasn’t enough to stop us getting the hell out of there. Echoing Robin’s observation, Cory says:

…the difference between “I hate this service but I can’t bring myself to quit it,” and “Jesus Christ, why did I wait so long to quit? Get me the hell out of here!” is razor thin.

If users can’t leave because everyone else is staying, when when everyone starts to leave, there’s no reason not to go, too.

That’s terminal enshittification, the phase when a platform becomes a pile of shit. This phase is usually accompanied by panic, which tech bros euphemistically call ‘pivoting.’

Anyway, I bring this up because I recently read something else about switching costs, but in a very different context. Jake Lazaroff was talking about JavaScript frameworks:

I want to talk about one specific weakness of JavaScript frameworks: interoperability, or the lack thereof. Almost without exception, each framework can only render components written for that framework specifically.

As a result, the JavaScript community tends to fragment itself along framework lines. Switching frameworks has a high cost, especially when moving to a less popular one; it means leaving most of the third-party ecosystem behind.

That switching cost stunts framework innovation by heavily favoring incumbents with large ecosystems.

Sounds a lot like what Cory was describing with incumbents like Google, Facebook, Twitter, and Amazon.

And let’s not kid ourselves, when we’re talking about incumbent client-side JavaScript frameworks, we might mention Vue or some other contender, but really we’re talking about React.

React has massive switching costs. For over a decade now, companies have been hiring developers based on one criterion: do they know React?

“An expert in CSS you say? No thanks.”

“Proficient in vanilla JavaScript? Don’t call us, we’ll call you.”

Heck, if I were advising someone who was looking for a job in front-end development (as opposed to actually being good at front-end development; two different things), I’d tell them to learn React.

Just as everyone ended up on Facebook because everyone was on Facebook, everyone ended up using React because everyone was using React.

You can probably see where I’m going with this: the inevitable enshittification of React.

Just to be clear, I’m not talking about React getting shittier in terms of what it does. It’s always been a shitty technology for end users:

React is legacy tech from 2013 when browsers didn’t have template strings or a BFCache.

No, I’m talking about the enshittification of the developer experience …the developer experience being the thing that React supposedly has going for it, though as Simon points out, the developer experience has always been pretty crap:

Whether on purpose or not, React took advantage of this situation by continuously delivering or promising to deliver changes to the library, with a brand new API being released every 12 to 18 months. Those new APIs and the breaking changes they introduce are the new shiny objects you can’t help but chase. You spend multiple cycles learning the new API and upgrading your application. It sure feels like you are doing something, but in reality, you are only treading water.

Well, it seems like the enshittification of the React ecosystem is well underway. Cassidy is kind of annoyed at React. Tom is increasingly miffed about the state of React releases, and Matteo asks React, where are you going?

Personally, I would love it if more people were complaining about the dreadful user experience inflicted by client-side React. Instead the complaints are universally about the developer experience.

I guess doing the right thing for the wrong reasons is fine. It’s just a little dispiriting.

I sometimes feel like I’m living that old joke, where I’m the one in the restaurant saying “the food here is terrible!” and most of my peers are saying “I know! And such small portions!”

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!

I try to get back to Ireland a few times a year to see my mother. At some point in each trip there’s a social gathering with her friends or family. Inevitably the talk turns to ailments, illnesses, and complaints. I sit there quietly and nod politely.

2023 was the year I joined in.

If it wasn’t relaying my experience of visits to the emergency room, it was talk of my sinuses acting up and keeping me awake at night with their noises. Nasal polyps perhaps? And lately I’ve been having this wheezy asthma-like issue at night, what with this chesty cough I’ve been trying to sha… you get how uninteresting this is, right?

So I’ve got some nagging health issues. But I consider myself lucky. In the grand scheme of things, they aren’t big deals. Even the allergy which requires me to carry an epi-pen is to the easily-avoidable Ibuprofun, not to some ubiquitous foodstuff.

In fact I’ve had just enough health issues to give me a nice dose of perspective and appreciate all the times when my body is functioning correctly. I often think of what Maciej wrote about perspective:

The good news is, as you get older, you gain perspective. Perspective helps alleviate burnout.

The bad news is, you gain perspective by having incredibly shitty things happen to you and the people you love. Nature has made it so that perspective is only delivered in bulk quantities. A railcar of perspective arrives and dumps itself on your lawn when all you needed was a microgram. This is a grossly inefficient aspect of the human condition, but I’m sure bright minds in Silicon Valley are working on a fix.

Hence my feeling fortunate. 2023 was a perfectly grand year for me.

I went on some great adventures with Jessica. In the middle of the year we crossed the Atlantic on the Queen Mary II with our friends Dan and Sue, then we explored New York, and then we relaxed on Saint Augustine Beach for a week. Lovely!

The week in Ortigia, Sicily was great. So was the week in Cáceres, Spain. And the week spent playing music in Belfast during the trad festival was a blast.

There was lots of music closer to home too. Brighton is blessed with plenty of Irish music sessions and I’m doing my best to get to all of them. Playing mandolin in a session is my happy place.

Other music is also available. The band had an excellent year with the addition of our brilliant drummer, Matthew. We made such fast progress on new material that we managed to get into the studio to record an album’s worth of songs. Expect a new Salter Cane album in 2024!

On the work front, my highlights were event-based. I curated and hosted UX London. I spoke at a bunch of other events, and I think I did a good job. I spoke at no online events, and that’s the way I’d like to keep it. I thrive on giving talks at in-person gatherings. I hope I can continue to do that in 2024.

I very much enjoyed having a four-day work week in 2023. I don’t think I could ever go back to a five-day week. In fact, for 2024 I’m dabbling with a three-day work week. I’m luckily I can afford to do this. Given the choice, I’d rather have more time than more money. I know not everyone has that choice.

My hope for 2024 is for pretty much more of the same as I got in 2023. More music. More travel. But fewer health issues.

When I was summarising 2022, I said:

I’ve got my health. That’s something I don’t take for granted.

I’ve still (mostly) got my health. I definitely don’t take it for granted. Here’s to a happy and healthy 2024.

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.

Put the dates in your dairy: UX London 2024 will be on June 18th, 19th, and 20th.

Better yet, grab a ticket right now. There are super early-bird tickets available until this Friday.

If you want a flavour of what to expect, check out the speakers that are already confirmed: Brad!, Ben!, Tshili!, and more!

It’s early days but I can tell you what to expect from each day. The first day will be themed around research. The second will have a focus on product design. The third day will be themed around design systems and design ops.

As usual, there’ll be a mix of talks and workshops: a single track of inspirational talks in the morning, followed by a choice of practical workshops in the afternoon.

We’ll be in a new venue next year too—right in the heart of London.

See you there!

Web components have been around for quite a while, but it feels like they’re having a bit of a moment right now.

It turns out that the best selling point for web components was “wait and see.” For everyone who didn’t see the benefit of web components over being locked into a specific framework, time is proving to be a great teacher.

It’s not just that web components are portable. They’re also web standards, which means they’ll be around as long as web browsers. No framework can make that claim. As Jake Lazaroff puts it, web components will outlive your JavaScript framework.

At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to build on React are doing it largely out of habit.

Others are making more sensible judgements and, having been bitten by lock-in in the past, are now giving web components a go.

If you’re one of those people making the move from React to web components, there’ll certainly be a bit of a learning curve, but that would be true of any technology change.

I have a suggestion for you if you find yourself in this position. Try not to bring React’s mindset with you.

I’m talking about the way React components are composed. There’s often lots of props doing heavy lifting. The actual component element itself might be empty.

If you want to apply that model to web components, you can. Lots of people do. It’s not unusual to see web components in the wild that look like this:

<my-component></my-component>

The custom element is just a shell. All the actual power is elsewhere. It’s in the JavaScript that does all kinds of clever things with the shadow DOM, templates, and slots.

There is another way. Ask, as Robin does, “what would HTML do?”

Think about composibility with existing materials. Do you really need to invent an entirely new component from scratch? Or can you use HTML up until it reaches its limit and then enhance the markup?

Robin writes:

I don’t think we should see web components like the ones you might find in a huge monolithic React app: your Button or Table or Input components. Instead, I’ve started to come around and see Web Components as filling in the blanks of what we can do with hypertext: they’re really just small, reusable chunks of code that extends the language of HTML.

Dave talks about how web components can be HTML with superpowers. I think that’s a good attitude to have. Instead of all-singing, all-dancing web components, it feels a lot more elegant to use web components to augment your existing markup with just enough extra behaviour.

Where does the shadow DOM come into all of this? It doesn’t. And that’s okay. I’m not saying it should be avoided completely, but it should be a last resort. See how far you can get with the composibility of regular HTML first.

Eric described his recent epiphany with web components. He created a super-slider custom element that wraps around an existing label and input type="range":

You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS!  Everything’s of the Light Side of the Web.  No need to pierce the Vale of Shadows or whatever.

When you wrap some existing markup in a custom element and then apply some new behaviour with JavaScript, technically you’re not doing anything you couldn’t have done before with some DOM traversal and event handling. But it’s less fragile to do it with a web component. It’s portable. It obeys the single responsibility principle. It only does one thing but it does it well.

Jim created an icon-list custom element that wraps around a regular ul populated with li elements. But he feels almost bashful about even calling it a web component:

Maybe I shouldn’t be using the term “web component” for what I’ve done here. I’m not using shadow DOM. I’m not using the templates or slots. I’m really only using custom elements to attach functionality to a specific kind of component.

I think what Eric and Jim are doing is exemplary. See also Zach’s web components.

At the end of his post, Eric says he’d like a nice catchy term for these kinds of web components. In Dave’s catalogue of web components, they’re called “element extensions.” I like that. It’s pretty catchy.

Or we could call them “HTML web components.” If your custom element is empty, it’s not an HTML web component. But if you’re using a custom element to extend existing markup, that’s an HTML web component.

React encouraged a mindset of replacement: “forgot what browsers can do; do everything in a React component instead, even if you’re reinventing the wheel.”

HTML web components encourage a mindset of augmentation instead.

The bedrock of the World Wide Web is solid. Built atop the protocols of the internet (TCP/IP), its fundamental building blocks remain: URLs of HTML files transmitted over HTTP. Baldur Bjarnason writes:

Even today, the web is like living fossil, a preserved relic from a different era. Anybody can put up a website. Anybody can run a business over it. I can build an app or service, send the URL to anybody I like, and most people in the world will be able to run it without asking anybody’s permission.

Still, the web has evolved. In fact, that evolution is something that’s also built into its fundamental design. Rather than try to optimise the World Wide Web for one particular use-case, Tim Berners-Lee realised the power of being flexible. Like the internet, the World Wide Web is deliberately dumb.

(I get very annoyed when people talk about the web as being designed for scientific work at CERN. That was merely the first use-case. The web was designed for everything …and nothing in particular.)

Robin Berjon compares the web’s evolution to the ship of Theseus:

That’s why it’s been so hard to agree about what the Web is: the Web is architected for resilience which means that it adapts and transforms. That flexibility is the reason why I’m talking about some mythological dude’s boat. Altogether too often, we consider some aspects of the Web as being invariants when they’re potentially just as replaceable as any other part. This isn’t to say that there are no invariants on the Web.

The web can be changed. That’s both a comfort and a warning. There’s plenty that we should change about today’s web. But there’s also plenty—at the root level—that we should fight to preserve.

And if you want change, the worst way to go about it is to promulgate the notion of burning everything down and starting from scratch. As Erin says in the fourth and final part of her devastating series on Meta in Myanmar:

We don’t get a do-over planet. We won’t get a do-over network.

Instead, we have to work with the internet we made and find a way to rebuild and fortify it to support the much larger projects of repair—political, cultural, environmental—that are required for our survival.

Though, as Robin points out, that doesn’t preclude us from sharing a vision:

Proceeding via small, incremental changes can be a laudable approach, but even then it helps to have a sense for what it is that those small steps are supposed to be incrementing towards.

I’m looking forward to reading what Robin puts forward, particularly because he says “I’m no technosolutionist.”

From a technical perspective, the web has never been better. We have incredible features in HTML, CSS, and JavaScript, all standardised and with amazing interoperability between browsers. The challenges that face the web today are not technical.

That’s one of the reasons why I have no patience for the web3 crowd. Apart from the ridiculous name, they’re focusing on exactly the wrong part of the stack.

Listening to their pitch, they’ll point out that while yes, the fundamental bedrock of the web is indeed decentralised—TCP/IP, HTTP(S)—what’s been constructed on that foundation is increasingly centralised; the power brokers of Google, Meta, Amazon.

And what’s the solution they propose? Replace the underlying infrastructure with something-something-blockchain.

Would that it were so simple.

The problems of today’s web are not technical in nature. The problems of today’s web won’t be solved by technology. If we’re going to solve the problems of today’s web, we’ll need to do it through law, culture, societal norms, and co-operation.

(Feel free to substitute “today’s web” with “tomorrow’s climate”.)

August was a month of travels. You can press play on that month’s map to follow the journey.

But check out the map for September too because the travels continue. This time my adventures are confined to Europe.

I’m in Spain. Jessica and I flew into Madrid on Saturday. The next day we took a train ride across the Extremaduran landscape to Cáceres, our home for the week.

This is like the sequel to our Sicilian trip. We’re both working remotely. We just happen to do be doing it from a beautiful old town with amazing cuisine.

We’re in a nice apartment that—crucially—has good WiFi. It’s right on the main square, but it’s remarkably quiet.

There’s a time difference of one hour with Brighton. Fortunately everything in Spain happens at least an hour later than it does at home. Waking up. Lunch. Dinner. Everything is time-shifted so that I’m on the same schedule as my colleagues.

I swear I’m more productive working this way. Maybe it’s the knowledge that tapas of Iberican ham await me after work, but I’m getting a lot done this week.

And when the working week is done, the fun begins. Cáceres is hosting its annual Irish fleadh this weekend.

I’ve always wanted to go to it, but it’s quite a hassle to get here just for a weekend. Combining it with a week of remote work makes it more doable.

I’m already having a really nice time here and the tunes haven’t even started yet.

I received this email recently:

Subject: multi-page web apps

Hi Jeremy,

lately I’ve been following you through videos and texts and I’m curious as to why you advocate the use of multi-page web apps and not single-page ones.

Perhaps you can refer me to some sources where your position and reasoning is evident?

Here’s the response I sent…

Hi,

You can find a lot of my reasoning laid out in this (short and free) online book I wrote called Resilient Web Design:

https://resilientwebdesign.com/

The short answer to your question is this: user experience.

The slightly longer answer…

For most use cases, a website (or multi-page app if you prefer) is going to provide the most robust experience for the most number of users. That’s because a user’s web browser takes care of most of the heavy lifting.

Navigating from one page to another? That’s taken care of with links.

Gathering information from a user to process on a server? That’s taken care of with forms.

This frees me up to concentrate on the content and the design without having to reinvent the wheels of links and form fields.

These (let’s call them) multi-page apps are stateless, and for most use cases that’s absolutely fine.

There are some cases where you’d want a state to persist across pages. Let’s say you’re playing a song, or a podcast episode. Ideally you’d want that player to continue seamlessly playing even as the user navigates around the site. In that situation, a single-page app would be a suitable architecture.

But that architecture comes at a cost. Now you’ve got stop the browser doing what it would normally do with links and forms. It’s up to you to recreate that functionality. And you can’t do it with HTML, a robust fault-tolerant declarative language. You need to reimplement all that functionality in JavaScript, a less tolerant, more brittle language.

Then you’ve got to ship all that code to the user before they can use your site. It might be JavaScript code you’ve written yourself or it might be a third-party library designed for building single-page apps. Either way, the user pays a download tax (and a parsing tax, and an execution tax). Whereas with links and forms, all of that functionality is pre-bundled into the user’s web browser.

So that’s my reasoning. At least nine times out of ten, a multi-page approach is leaner, more robust, and simpler.

Like I said, there are times when a single-page approach makes sense—it all comes down to whether state needs to be constantly preserved. But these use cases are the exceptions, not the rule.

That’s why I find the framing of your question a little concerning. It should be inverted. The default approach should be to assume a multi-page approach (which is the way the web works by default). Deciding to take a JavaScript-driven single-page approach should be the exception.

It’s kind of like when people ask, “Why don’t you have children?” Surely the decision to have a child should require deliberation and commitment, rather than the other way around.

When it comes to front-end development, I’m worried that we’ve reached a state where the more complex over-engineered approach is viewed as the default.

I may be committing a fundamental attribution error here, but I think that we’ve reached this point not because of any consideration for users, but rather because of how it makes us developers feel. Perhaps building an old-fashioned website that uses HTML for navigations feels too easy, like it’s beneath us. But building an “app” that requires JavaScript just to render text on a screen feels like real programming.

I hope I’m wrong. I hope that other developers will start to consider user experience first and foremost when making architectural decisions.

Anyway. That’s my answer. User experience.

Cheers,

Jeremy

I just described prototype code as code to be thrown away. On that topic…

I’ve been observing how people are programming with large language models and I’ve seen a few trends.

The first thing that just about everyone agrees on is that the code produced by a generative tool is not fit for public consumption. At least not straight away. It definitely needs to be checked and tested. If you enjoy debugging and doing code reviews, this might be right up your street.

The other option is to not use these tools for production code at all. Instead use them for throwaway code. That could be prototyping. But it could also be the code for those annoying admin tasks that you don’t do very often.

Take content migration. Say you need to grab a data dump, do some operations on the data to transform it in some way, and then pipe the results into a new content management system.

That’s almost certainly something you’d want to automate with bespoke code. Once the content migration is done, the code can be thrown away.

Read Matt’s account of coding up his Braggoscope. The code needed to spider a thousand web pages, extract data from those pages, find similarities, and output the newly-structured data in a different format.

I’ve noticed that these are just the kind of tasks that large language models are pretty good at. In effect you’re training the tool on your own very specific data and getting it to do your drudge work for you.

To me, it feels right that the usefulness happens on your own machine. You don’t put the machine-generated code in front of other humans.

My week at the Belfast TradFest culminated in a cathedral.

Everyone who has been taking classes during the week made their way to Belfast cathedral for a communal finish. Every class played a short piece to round out their week of workshops.

The whole experience was quite lovely. At one point, I was unexepectedly moved to tears by the performance of the cello class (not a common instrument in Irish traditional music).

When I got home, I decided to send a message to Neil Martin who taught that class. It was just a quick line or two to tell him how special it was.

He responded, saying he found the whole experience of the closing concert very moving and powerful.

I was glad I sent that note of thanks.

Then, a day later, I received my own note of thanks. It wasn’t music-related. Someone I had met and chatted with at a conference last year told me that they had just watched the video of my talk, The State Of The Web. They were very moved by it. Then they took the time to send me an email to tell me. As you can imagine, I was really touched to be on the receiving end of that.

I resolved that I would do it more myself. Whether it’s a piece of music, writing, or anything else, I’m going to try to remember to pass on my appreciation more often.

That’s a good place to end, isn’t it? A nice heart-warming reminder that small acts of thoughtfulness can make a big difference to someone else’s well-being.

But there’s a corollary to that lesson. Acts of thoughtlessness will almost certainly make a very big difference to someone else’s well-being.

This is something I know in theory but struggle with in practice. I’ve experienced the regret of wishing I hadn’t acted so stupidly in my dealings with work colleagues, for example.

There’ll be some discussion happening on a topic that I might have strong feelings about, and I let those strong feelings take over my behaviour. Quite frankly, I act like a dickhead.

Sure, I can analyse it in hindsight and identify what causes this unintended behaviour, but that sounds an awful lot like excusing it. In the end, it doesn’t matter what my intentions were or what the circumstances were. It’s my actions that matter. More specifically, it’s the effect of my actions on other people that matter.

So, yeah, I am going to try to do more of those small thoughtful acts, like sending thank-you messages to people. But frankly, that’s a stretch goal. The shamefully low bar I first have to pass is to simply treat people with the respect they deserve. To paraphrase the Hypocratic oath: first, don’t be an asshole.

There’s an oft-quoted adage:

They may forget what you said, but they will never forget how you made them feel.

This is usually applied in the inspirational, positive sense: get out there and make people feel good! But it works equally well as a warning.

Social networks come and social networks go.

Right now, there’s a whole bunch of social networks coming (Blewski, Freds, Mastication) and one big one going, thanks to Elongate.

Me? I watch all of this unfold like Doctor Manhattan on Mars. I have no great connection to any of these places. They’re all just syndication endpoints to me.

I used to have a checkbox in my posting interface that said “Twitter”. If I wanted to add a copy of one of my notes to Twitter, I’d enable that toggle.

I have, of course, now removed that checkbox. Twitter is dead to me (and it should be dead to you too).

I used to have another checkbox next to that one that said “Flickr”. If I was adding a photo to one of my notes, I could toggle that to send a copy to my Flickr account.

Alas, that no longer works. Flickr only allows you to post 1000 photos before requiring a pro account. Fair enough. I’ve actually posted 20 times that amount since 2005, but I let my pro membership lapse a while back.

So now I’ve removed the “Flickr” checkbox too.

Instead I’ve now got a checkbox labelled “Mastodon” that sends a copy of a note to my Mastodon account.

When I publish a blog post like the one you’re reading now here on my journal, there’s yet another checkbox that says “Medium”. Toggling that checkbox sends a copy of my post to my page on Ev’s blog.

At least it used to. At some point that stopped working too. I was going to start debugging my code, but when I went to the documentation for the Medium API, I saw this:

This repository has been archived by the owner on Mar 2, 2023. It is now read-only.

I guessed I missed the memo. I guess Medium also missed the memo, because developers.medium.com is still live. It proudly proclaims:

Medium’s Publishing API makes it easy for you to plug into the Medium network, create your content on Medium from anywhere you write, and expand your audience and your influence.

Not a word of that is accurate.

That page also has a link to the Medium engineering blog. Surely the announcement of the API deprecation would be published there?

Crickets.

Moving on…

I have an account on Bluesky. I don’t know why.

I was idly wondering about sending copies of my notes there when I came across a straightforward solution: micro.blog.

That’s yet another place where I have an account. They make syndication very straightfoward. You can go to your account and point to a feed from your own website.

That’s it. Syndication enabled.

It gets better. Micro.blog can also cross-post to other services. One of those services is Bluesky. I gave permission to micro.blog to syndicate to Bluesky so now my notes show up there too.

It’s like dominoes falling: I post something on my website which updates my RSS feed which gets picked up by micro.blog which passes it on to Bluesky.

I noticed that one of the other services that micro.blog can post to is Medium. Hmmm …would that still work given the abandonment of the API?

I gave permission to micro.blog to cross-post to Medium when my feed of blog posts is updated. It seems to have worked!

We’ll see how long it lasts. We’ll see how long any of them last. Today’s social media darlings are tomorrow’s Friendster and MySpace.

When the current crop of services wither and die, my own website will still remain in full bloom.