Tags: medium



Tuesday, September 20th, 2022

Accessibility is systemic

I keep thinking about this blog post I linked to last week by Jacob Kaplan-Moss. It’s called Quality Is Systemic:

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.

I think he’s on to something. I also think this applies to design just as much as development. Maybe more so. In design, there’s maybe too much emphasis placed on the talent and skill of individual designers and not enough emphasis placed on creating and nurturing a healthy environment where anyone can contribute to the design process.

Jacob also ties this into hiring:

Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct some of that effort towards building a system that produces great results out of a wider spectrum of individual performance.

I couldn’t agree more! It just one of the reasons why the smart long-term strategy can be to concentrate on nurturing junior designers and developers rather than head-hunting rockstars.

As an aside, if you think that the process of nurturing junior designers and developers is trickier now that we’re working remotely, I highly recommend reading Mandy’s post, Official myths:

Supporting junior staff is work. It’s work whether you’re in an office some or all of the time, and it’s work if Slack is the only office you know. Hauling staff back to the office doesn’t make supporting junior staff easier or even more likely.

Hiring highly experienced designers and developers makes total sense, at least in the short term. But I think the better long-term solution—as outlined by Jacob—is to create (and care for) a system where even inexperienced practitioners will be able to do good work by having the support and access to knowledge that they need.

I was thinking about this last week when Irina very kindly agreed to present a lunch’n’learn for Clearleft all about inclusive design.

She answered a question that had been at the front of my mind: what’s the difference between inclusive design and accessibility?

The way Irina put it, accessibility is focused on implementation. To make a website accessible, you need people with the necessary skills, knowledge and experience.

But inclusive design is about the process and the system that leads to that implementation.

To use that cliché of the double diamond, maybe inclusive design is about “building the right thing” and accessibility is about “building the thing right.”

Or to put it another way, maybe accessibility is about outputs, whereas inclusive design is about inputs. You need both, but maybe we put too much emphasis on the outputs and not enough emphasis on the inputs.

This is what made me think of Jacob’s assertion that quality is systemic.

Imagine someone who’s an expert at accessibility: they know all the details of WCAG and ARIA. Now put that person into an organisation that doesn’t prioritise accessibility. They’re going to have a hard time and they probably won’t be able to be very effective despite all their skills.

Now imagine an organisation that priorities inclusivity. Even if their staff don’t (yet) have the skills and knowledge of an accessibility expert, just having the processes and priorities in place from the start will make it easier for everyone to contribute to a more accessible experience.

It’s possible to make something accessible in the absence of a system that prioritises inclusive design but it will be hard work. Whereas making sure inclusive design is prioritised at an organisational level makes it much more likely that the outputs will be accessible.

Thursday, September 15th, 2022

Let’s get logical

I was refactoring some CSS on The Session over the weekend. I thought it would be good to switch over to using logical properties exclusively. I did this partly to make the site more easily translatable into languages with different writing modes, but mostly as an exercise to help train me in thinking with logical properties by default.

All in all, it went pretty smoothly. You can kick the tyres by opening up dev tools on The Session and adding a writing-mode declaration to the body or html element.

For the most part, the switchover was smooth. It mostly involved swapping out property names with left, right, top, and bottom for inline-start, inline-end, block-start, and block-end.

The border-radius properties tripped me up a little. You have to use shorthand like border-start-end-radius, not border-block-start-inline-end-radius (that doesn’t exist). So you have to keep the order of the properties in mind:

border-{{block direction}}-{{inline-direction}}-radius

Speaking of shorthand, I also had to kiss some shorthand declarations goodbye. Let’s say I use this shorthand for something like margin or padding:

margin: 1em 1.5em 2em 0.5em;

Those values get applied to margin-top, margin-right, margin-bottom, and margin-left, not the logical equivalents (block-start, inline-end, block-end, and inline-start). So separate declarations are needed instead:

margin-block-start: 1em;
margin-inline-end: 1.5em;
margin-block-end: 2em;
margin-inline-start: 0.5em;

Same goes for shorthand like this:

margin: 1em 2em;

That needs to be written as two declarations:

margin-block: 1em;
margin-inline: 2em;

Now I’ve said it before and I’ll say it again: it feels really weird that you can’t use logical properties in media queries. Although as I said:

Now you could rightly argue that in this instance we’re talking about the physical dimensions of the viewport. So maybe width and height make more sense than inline and block.

But along comes the new kid on the block (or inline), container queries, ready to roll with container-type values like inline-size. I hope it’s just a matter of time until we can use logical properties in all our conditional queries.

The other place where there’s still a cognitive mismatch is in transforms and animations. We’ve got a translateX() function but no translate-inline(). We’ve got translateY() but no translate-block().

On The Session I’m using some JavaScript to figure out the details of some animation effects. I’m using methods like getBoundingClientRect(). It doesn’t return logical properties. So if I ever want to adjust my animations based on writing direction, I’ll need to fork my JavaScript code.

Oh, and one other thing: the aspect-ratio property takes values in the form of width/height, not inline/block. That makes sense if you’re dealing with images, videos, or other embedded content but it makes it really tricky to use aspect-ratio on elements that contain text. I mean, it works fine as long as the text is in a language using a top-to-bottom writing mode, but not for any other languages.

Tuesday, September 13th, 2022

That was dConstruct 2022

dConstruct 2022 happened last Friday, September 9th.

And what an event it was! All eight talks were superb. To have eight speakers and not a single dud is pretty great. To have eight speakers and each one be absolutely brilliant is more than I could’ve hoped for.

Hidde has written a summary of the talks. I loved each and every one. I got to sit there in the front row of the beautiful Duke of York’s cinema and watch these supersmart people blow my mind.

With six of the eight speakers having spoken at previous dConstructs, there was a lot of nostalgia in the air on Friday.

It was the last dConstruct.

A lot of people seemed surprised by this even though I kept saying it was a one-off event. Really, the last dConstruct happened in 2015. This year’s event was a one-time-only anniversary event.

Obviously because the day was so great, people expressed sadness and disappointment that there wouldn’t be another. But like I said, if a band like The Velvet Underground reforms to do one last gig, that’s pretty cool; but if a band like The Velvet Underground reforms to go on endless tours, that’s kind of sad. It’s time to move on. Have one last blow-out and go out in style.

And who knows? Maybe there’ll be some other kind of dConstructy gathering in a different format. Perhaps an evening salon event is more suited to this kind of interdisciplinary mish-mash. But as a one-day conference, dConstruct is now officially over.

To be honest, there was never any doubt that dConstruct 2022 would be an excellent day of talks. I knew that each of the speakers would deliver the goods. I played it somewhat safe with the line-up. Because this was a kind of “best of” event, I could draw upon speakers from previous years who were guaranteed to be mesmerising.

In a weird way, that also highlights the biggest problem with this year’s dConstruct. Even though every individual talk was terrific, when you pull back and look at the line-up in aggregate, you can’t help but notice its lack of diversity.

That’s on me.

I could show you the list of people I tried to get. I could talk you through the spots that fell through. But all I’d be doing is giving you excuses. I could show that my intentions were good, but intentions don’t matter as much as actions. The proof of the pudding is in the eating, and what we ate last Friday was wonderful but also sadly representative of dConstruct’s homogenous history. For that reason alone, it’s time to draw a line under dConstruct.

It was a bittersweet send-off. On the one hand, I got to enjoy a day of brilliant talks. On the other hand, I’m pretty disappointed in myself that the line-up wasn’t more diverse. I can make all the claims I want about valuing diversity, but they’re hollow without meaningful results.

So that’s enough looking to the past. I’m bidding farewell to dConstruct and setting my sights on the future, a future that features more and different voices.

If you came along to dConstruct 2022, thank you! If you enjoyed attending dConstruct just half as much as I enjoyed hosting it …well, then I enjoyed it twice as much as you.

Monday, September 12th, 2022


I’m taking a nice long weekend break after dConstruct on Friday (I will of course have more to say on that—I’m collecting my thoughts still—but it was a wonderful day).

On Saturday I did absolutely nothing. It was just as well really, considering that I may have over-indulged in the pub on Friday evening after dConstruct was done. So a day of lounging around idly playing mandolin was just the ticket.

Yesterday, Sunday, I had one of those perfect leisurely days.

It began with a good bout of lazing about in the morning. Then, as lunchtime approached, Jessica and I went to a nearby pub for a Sunday Roast. In this case it was the Dover Castle. It turned out to be an excellent choice—top notch roasts!

While we were enjoying our lunch, Jessica spotted a poster on the wall for Bark In The Park, a local fun day of dog-centred activities. We were sure it had already happened earlier in Summer, but the poster said it was rescheduled to …yesterday!

A beautiful black and white collie dressed as a pirate with a cape and a hat.

So after lunch we went to the park and spent the next few hours in the sunshine, petting very good dogs and enjoying the spectacle of such catgories as “fancy dress”, “best rescue”, and “sausage catching.” We left shortly before the announcement of “best in show”—my money was on Mayhem—so I could nip home, grab my mandolin, and head to The Bugle pub for the weekly 4pm Irish music session.

Checked in at The Bugle Inn. Sunday session 🎻🎶☘️

After two hours of jigs’n’reels, I headed home. The weather was still lovely. The forecast was for cloudy weather, but it was unexpectedly sunny. So I fired up the outdoor grill.

We grilled: one aubergine, halved and scored; one yellow courgette, halved; one green courgette, halved; half a hispe cabbage, quartered. Once they were nicely charred outside and soft within, we ate them with a drizzle of tahini sauce, accompanied by a green salad.

By that time the sun had gone down and it was time for a nice evening spent watching the latest episode of The Rings Of Power and drinking a nice cup of tea.

Like a said, a perfect leisurely day.

Thursday, September 8th, 2022

One day to dConstruct

Just one more sleep until dConstruct—squee!

Not that I anticipate getting much sleep. My sleepnessness will partly be like that of a child on the night before Christmas. But my sleepnessness will also inevitably be that of an adult neurotically worrying about trifling details.

In reality, everything is all set. Thanks to the stellar Clearleft events team, I don’t need to lose any sleep. But my stupid brain can’t help but run a conveyer belt of potential problems through my mind: what about dongles? Power? Timings? What if there’s an impromptu rail strike? A deluge? Other emergencies you can’t even imagine?

I try to ignore those pestering pointless questions and instead think about the fantastic talks we’re going to get. I’m genuinely excited about each and every speaker. I’m pretty sure that once the day begins, I’ll forget all my worries and bliss out to the mind-expanding presentations.

The day before a conference feels kind of like the build-up to a battle. All the strategic decisions have been made, everything is in place, and now there’s nothing to do but wait.

I’ve communicated (or maybe over-communicated) all the relevant details to the speakers. And one week ago I sent one final email to the attendees with details of the schedule and some suggestions for lunch.

I also included this request:

Could you do me a favour? Would you mind getting a hold of a Covid test sometime in the next week and taking a test a day or two before dConstruct? (And if you test positive, please don’t come to the event.)

If you can’t get hold of a test (I know it can be tricky), then could you please bring a mask to wear when inside the venue?

I think asking everyone to take a test is a reasonable request, and nobody has objected to it. I worry that it’s yet another form of hygiene theatre (like providing anti-bacterial handwash for an airborne virus). After all, the antigen tests are most effective when you’ve already got symptoms. Taking a test when you don’t have symptoms might well give a negative result, but it doesn’t necessarily mean you don’t have Covid. Still, it’s a little intervention that might catch an infection that otherwise would’ve spread further.

I’m assuming that everyone coming to dConstruct is vaccinated. Maybe that’s naive on my part, but I figure if you’re intelligent enough to get a dConstruct ticket, you’re intelligent enough to protect yourself and others. So we won’t be requesting proof of vaccination. I hope my naivety aligns with reality.

See, this is all one more thing for my brain to gnaw on when I should be thinking about what a fantastic day of talks I’ve got ahead of me. Roll on tomorrow!

Tuesday, August 30th, 2022

dConstruct update

Not long now until the last ever dConstruct. It’s on Friday of next week, that’s the 9th of September. And there are still a few tickets available if you haven’t got yours yet.

I have got one update to the line-up to report. Sadly, Léonie Watson isn’t going to be able to make it after all. That’s a shame.

But that means there’s room to squeeze in one more brilliant speaker from the vaults of the dConstruct archive.

I’m very pleased to announce that Seb Lee-Delisle will be returning, ten years after his first dConstruct appearance.

Back then he was entertaining us with hardware hacking and programming for fun. That was before he discovered lasers. Now he’s gone laser mad.

Don’t worry though. He’s fully qualified to operate lasers so he’s not going to take anyone’s eye out at dConstruct. Probably.

Tuesday, August 23rd, 2022

Work ethics

If you’re travelling around Ireland, you may come across some odd pieces of 19th century architecture—walls, bridges, buildings and roads that serve no purpose. They date back to The Great Hunger of the 1840s. These “famine follies” were the result of a public works scheme.

The thinking went something like this: people are starving so we should feed them but we can’t just give people food for nothing so let’s make people do pointless work in exchange for feeding them (kind of like an early iteration of proof of work for cryptobollocks on blockchains …except with a blockchain, you don’t even get a wall or a road, just ridiculous amounts of wasted energy).

This kind of thinking seems reprehensible from today’s perspective. But I still see its echo in the work ethic espoused by otherwise smart people.

Here’s the thing: there’s good work and there’s working hard. What matters is doing good work. Often, to do good work you need to work hard. And so people naturally conflate the two, thinking that what matters is working hard. But whether you work hard or not isn’t actually what’s important. What’s important is that you do good work.

If you can do good work without working hard, that’s not a bad thing. In fact, it’s great—you’ve managed to do good work and do it efficiently! But often this very efficiency is treated as laziness.

Sensible managers are rightly appalled by so-called productivity tracking because it measures exactly the wrong thing. Those instruments of workplace surveillance measure inputs, not outputs (and even measuring outputs is misguided when what really matters are outcomes).

They can attempt to measure how hard someone is working, but they don’t even attempt to measure whether someone is producing good work. If anything, they actively discourage good work; there’s plenty of evidence to show that more hours equates to less quality.

I used to think that must be some validity to the belief that hard work has intrinsic value. It was a position that was espoused so often by those around me that it seemed a truism.

But after a few decades of experience, I see no evidence for hard work as an intrinsically valuable activity, much less a useful measurement. If anything, I’ve seen the real harm that can be caused by tying your self-worth to how much you’re working. That way lies burnout.

We no longer make people build famine walls or famine roads. But I wonder how many of us are constructing little monuments in our inboxes and calendars, filling those spaces with work to be done in an attempt to chase the rewards we’ve been told will result from hard graft.

I’d rather spend my time pursuing the opposite: the least work for the most people.

Wednesday, August 17th, 2022

The schedule for dConstruct 2022

The last ever dConstruct will happen just over three weeks from now, on Friday, September 9th.

That’s right—if you don’t have your ticket for this event, you won’t get another chance. The conference with its eye on the future will become a thing of the past.

dConstruct is going to go out with a bang, a veritable fireworks display of mind bombs. A calligrapher, a writer, a musician, and a nueroscientist will be on the line-up alongside designers and technologists.

Here’s the schedule for the day:

8:30Registration begins
9:50Opening remarks
10:00George Oates
10:30Lauren Beukes
11:30Seb Lester
12:00Daniel Burka
14:00Sarah Angliss
14:30Matt Webb
15:30Léonie Watson
16:00Anil Seth
16:30Closing remarks

So the first talk starts at 10am and the last talk finishes at 4:30pm—all very civilised. Then we can all go to the pub.

There isn’t an official after-party but we can collectively nominate a nearby watering hole—the Unbarred taproom perhaps, or maybe The Hare And Hounds or The Joker—they’re all within cat-swinging distance of The Duke Of York’s.

Lunch isn’t provided but there are some excellent options nearby (and you’ll have a good hour and a half for the lunch break so there’s no rush).

The aforementioned Joker has superb hot wings from Lost Boys Chicken (I recommed the Rufio sauce if you like ‘em spicy, otherwise Thuddbutt is a good all ‘rounder).

The nearby Open Market has some excellent food options, including Casa Azul for superb Mexican food, and Kouzina for hearty Greek fare.

And the famous Bardsley’s fish’n’chips is just ‘round the corner too.

So there’ll be plenty of food for the soul to match the food for your brain that’ll be doled up at dConstruct 2022.

Tuesday, August 16th, 2022

No code

When I wrote about democratising dev, I made brief mention of the growing “no code” movement:

Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.

But I didn’t describe what no-code is, as I understand it.

I’m taking the term at face value to mean a mechanism for creating a website—preferably on a domain you control—without having to write anything in HTML, CSS, JavaScript, or any back-end programming language.

By that definition, something like WordPress.com (as opposed to WordPress itself) is a no-code tool:

Create any kind of website. No code, no manuals, no limits.

I’d also put Squarespace in the same category:

Start with a flexible template, then customize to fit your style and professional needs with our website builder.

And its competitor, Wix:

Discover the platform that gives you the freedom to create, design, manage and develop your web presence exactly the way you want.

Webflow provides the same kind of service, but with a heavy emphasis on marketing websites:

Your website should be a marketing asset, not an engineering challenge.

Bubble is trying to cover a broader base:

Bubble lets you create interactive, multi-user apps for desktop and mobile web browsers, including all the features you need to build a site like Facebook or Airbnb.

Wheras Carrd opts for a minimalist one-page approach:

Simple, free, fully responsive one-page sites for pretty much anything.

All of those tools emphasise that don’t need to need to know how to code in order to have a professional-looking website. But there’s a parallel universe of more niche no-code tools where the emphasis is on creativity and self-expression instead of slickness and professionalism.


Create your own free website. Unlimited creativity, zero ads.


Make a website in 5 minutes. Messy encouraged.


unique tool for web publishing & internet samizdat

I’m kind of fascinated by these two different approaches: professional vs. expressionist.

I’ve seen people grapple with this question when they decide to have their own website. Should it be a showcase of your achievements, almost like a portfolio? Or should it be a glorious mess of imagery and poetry to reflect your creativity? Could it be both? (Is that even doable? Or desirable?)

Robin Sloan recently published his ideas—and specs—for a new internet protocol called Spring ’83:

Spring ‘83 is a protocol for the transmission and display of something I am calling a “board”, which is an HTML fragment, limited to 2217 bytes, unable to execute JavaScript or load external resources, but otherwise unrestricted. Boards invite publishers to use all the richness of modern HTML and CSS. Plain text and blue links are also enthusiastically supported.

It’s not a no-code tool (you need to publish in HTML), although someone could easily provide a no-code tool to sit on top of the protocol. Conceptually though, it feels like it’s an a similar space to the chaotic good of neocities.org, mmm.page, and hotglue.me with maybe a bit of tilde.town thrown in.

It feels like something might be in the air. With Spring ’83, the Block protocol, and other experiments, people are creating some interesting small pieces that could potentially be loosely joined. No code required.

Alternative stylesheets

My website has different themes you can choose from. I don’t just mean a dark mode. These themes all look very different from one another.

I assume that 99.99% of people just see the default theme, but I keep the others around anyway. Offering different themes was originally intended as a way of showcasing the power of CSS, and specifically the separation of concerns between structure and presentation. I started doing this before the CSS Zen Garden was created. Dave really took it to the next level by showing how the same HTML document could be styled in an infinite number of ways.

Each theme has its own stylesheet. I’ve got a very simple little style switcher on every page of my site. Selecting a different theme triggers a page refresh with the new styles applied and sets a cookie to remember your preference.

I also list out the available stylesheets in the head of every page using link elements that have rel values of alternate and stylesheet together. Each link element also has a title attribute with the name of the theme. That’s the standard way to specify alternative stylesheets.

In Firefox you can switch between the specified stylesheets from the View menu by selecting Page Style (notice that there’s also a No style option—very handy for checking your document structure).

Other browsers like Chrome and Safari don’t do anything with the alternative stylesheets. But they don’t ignore them.

Every browser makes a network request for each alternative stylesheet. The request is non-blocking and seems to be low priority, which is good, but I’m somewhat perplexed by the network request being made at all.

I get why Firefox is requesting those stylesheets. It’s similar to requesting a print stylesheet. Even if the network were to drop, you still want those styles available to the user.

But I can’t think of any reason why Chrome or Safari would download the alternative stylesheets.

Wednesday, August 10th, 2022

Democratising dev

I met up with a supersmart programmer friend of mine a little while back. He was describing some work he was doing with React. He was joining up React components. There wasn’t really any problem-solving or debugging—the individual components had already been thoroughly tested. He said it felt more like construction than programming.

My immediate thought was “that should be automated.”

Or at the very least, there should be some way for just about anyone to join those pieces together rather than it requiring a supersmart programmer’s time. After all, isn’t that the promise of design systems and components—freeing us up to tackle the meaty problems instead of spending time on the plumbing?

I thought about that conversation when I was listening to Laurie’s excellent talk in Berlin last month.

Chatting to Laurie before the talk, he was very nervous about the conclusion that he had reached and was going to share: that the time is right for web development to be automated. He figured it would be an unpopular message. Heck, even he didn’t like it.

But I reminded him that it’s as old as the web itself. I’ve seen videos from very early World Wide Web conferences where Tim Berners-Lee was railing against the idea that anyone would write HTML by hand. The whole point of his WorldWideWeb app was that anyone could create and edit web pages as easily as word processing documents. It’s almost an accident of history that HTML happened to be just easy enough—but also just powerful enough—for many people to learn and use.

Anyway, I thoroughly enjoyed Laurie’s talk. (Except for a weird bit where he dunks on people moaning about “the fundamentals”. I think it’s supposed to be punching up, but I’m not sure that’s how it came across. As Chris points out, fundamentals matter …at least when it comes to concepts like accessibility and performance. I think Laurie was trying to dunk on people moaning about fundamental technologies like languages and frameworks. Perhaps the message got muddled in the delivery.)

I guess Laurie was kind of talking about this whole “no code” thing that’s quite hot right now. Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.

The problem is that unless they work 100%, and always produce good accessible performant code, then they’re going to be another example of the law of leaky abstractions. If a no-code tool can get someone 90% of the way to what they want, that seems pretty good. But if that person than has to spend an inordinate amount of time on the remaining 10% then all the good work of the no-code tool is somewhat wasted.

Funnily enough, the person who coined that law, Joel Spolsky, spoke right after Laurie in Berlin. The two talks made for a good double bill.

(I would link to Joel’s talk but for some reason the conference is marking the YouTube videos as unlisted. If you manage to track down a URL for the video of Joel’s talk, let me know and I’ll update this post.)

In a way, Joel was making the same point as Laurie: why is it still so hard to do something on the web that feels like it should be easily repeatable?

He used the example of putting an event online. Right now, the most convenient way to do it is to use a third-party centralised silo like Facebook. It works, but now the business model of Facebook comes along for the ride. Your event is now something to be tracked and monetised by advertisers.

You could try doing it yourself, but this is where you’ll run into the frustrations shared by Joel and Laurie. It’s still too damn hard and complicated (even though we’ve had years and years of putting events online). Despite what web developers tell themselves, making stuff for the web shouldn’t be that complicated. As Trys put it:

We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.

And yet here we are. You can either have the convenience of putting something on a silo like Facebook, or you can have the freedom of doing it yourself, indie web style. But you can’t have both it seems.

This is a criticism often levelled at the indie web. The barrier to entry to having your own website is too high. It’s a valid criticism. To have your own website, you need to have some working knowledge of web hosting and at least some web technologies (like HTML).

Don’t get me wrong. I love having my own website. Like, I really love it. But I’m also well aware that it doesn’t scale. It’s unreasonable to expect someone to learn new skills just to make a web page about, say, an event they want to publicise.

That’s kind of the backstory to the project that Joel wanted to talk about: the block protocol. (Note: it has absolutely nothing to do with blockchain—it’s just an unfortunate naming collision.)

The idea behind the project is to create a kind of crowdsourced pattern library—user interfaces for creating common structures like events, photos, tables, and lists. These patterns already exist in today’s silos and content management systems, but everyone is reinventing the wheel independently. The goal of this project is make these patterns interoperable, and therefore portable.

At first I thought that would be a classic /927 situation, but I’m pleased to see that the focus of the project is not on formats (we’ve been there and done that with microformats, RDF, schema.org, yada yada). The patterns might end up being web components or they might not. But the focus is on the interface. I think that’s a good approach.

That approach chimes nicely with one of the principles of the indie web:

UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols and formats sufficient to support that UX, and nothing more. AKA UX before plumbing.

That said, I don’t think this project is a cure-all. Interoperable (portable) chunks of structured content would be great, but that’s just one part of the challenge of scaling the indie web. You also need to have somewhere to put those blocks.

Convenience isn’t the only thing you get from using a silo like Facebook, Twitter, Instagram, or Medium. You also get “free” hosting …until you don’t (see GeoCities, MySpace, and many, many more).

Wouldn’t it be great if everyone had a place on the web that they could truly call their own? Today you need to have an uneccesary degree of technical understanding to publish something at a URL you control.

I’d love to see that challenge getting tackled.

Tuesday, August 2nd, 2022

Directory enquiries

I was talking to someone recently about a forgotten battle in the history of the early web. It was a battle between search engines and directories.

These days, when the history of the web is told, a whole bunch of services get lumped into the category of “competitors who lost to Google search”: Altavista, Lycos, Ask Jeeves, Yahoo.

But Yahoo wasn’t a search engine, at least not in the same way that Google was. Yahoo was a directory with a search interface on top. You could find what you were looking for by typing or you could zero in on what you were looking for by drilling down through a directory structure.

Yahoo wasn’t the only directory. DMOZ was an open-source competitor. You can still experience it at DMOZlive.com:

The official DMOZ.com site was closed by AOL on February 17th 2017. DMOZ Live is committed to continuing to make the DMOZ Internet Directory available on the Internet.

Search engines put their money on computation, or to use today’s parlance, algorithms (or if you’re really shameless, AI). Directories put their money on humans. Good ol’ information architecture.

It turned out that computation scaled faster than humans. Search won out over directories.

Now an entire generation has been raised in the aftermath of this battle. Monica Chin wrote about how this generation views the world of information:

Catherine Garland, an astrophysicist, started seeing the problem in 2017. She was teaching an engineering course, and her students were using simulation software to model turbines for jet engines. She’d laid out the assignment clearly, but student after student was calling her over for help. They were all getting the same error message: The program couldn’t find their files.

Garland thought it would be an easy fix. She asked each student where they’d saved their project. Could they be on the desktop? Perhaps in the shared drive? But over and over, she was met with confusion. “What are you talking about?” multiple students inquired. Not only did they not know where their files were saved — they didn’t understand the question.

Gradually, Garland came to the same realization that many of her fellow educators have reached in the past four years: the concept of file folders and directories, essential to previous generations’ understanding of computers, is gibberish to many modern students.

Dr. Saavik Ford confirms:

We are finding a persistent issue with getting (undergrad, new to research) students to understand that a file/directory structure exists, and how it works. After a debrief meeting today we realized it’s at least partly generational.

We live in a world ordered only by search:

While some are quite adept at using labels, tags, and folders to manage their emails, others will claim that there’s no need to do because you can easily search for whatever you happen to need. Save it all and search for what you want to find. This is, roughly speaking, the hot mess approach to information management. And it appears to arise both because search makes it a good-enough approach to take and because the scale of information we’re trying to manage makes it feel impossible to do otherwise. Who’s got the time or patience?

There are still hold-outs. You can prise files from Scott Jenson’s cold dead hands.

More recently, Linus Lee points out what we’ve lost by giving up on directory structures:

Humans are much better at choosing between a few options than conjuring an answer from scratch. We’re also much better at incrementally approaching the right answer by pointing towards the right direction than nailing the right search term from the beginning. When it’s possible to take a “type in a query” kind of interface and make it more incrementally explorable, I think it’s almost always going to produce a more intuitive and powerful interface.

Directory structures still make sense to me (because I’m old) but I don’t have a problem with search. I do have a problem with systems that try to force me to search when I want to drill down into folders.

I have no idea what Google Drive and Dropbox are doing but I don’t like it. They make me feel like the opposite of a power user. Trying to find a file using their interfaces makes me feel like I’m trying to get a printer to work. Randomly press things until something happens.

Anyway. Enough fist-shaking from me. I’m going to ponder Linus’s closing words. Maybe defaulting to a search interface is a cop-out:

Text search boxes are easy to design and easy to add to apps. But I think their ease on developers may be leading us to ignore potential interface ideas that could let us discover better ideas, faster.

Tuesday, July 26th, 2022

The line-up for dConstruct 2022 …revealed!

Alright, I’ve kept you in suspense for long enough. It’s time to reveal the magnificent line-up for dConstruct 2022.

I’ll now put names to the teasing list of descriptions I previously provided

A technologist, product designer, and writer who defies categorisation. They’ve headed up a design studio, co-founded a start-up, and now consult on super-clever machine learning stuff. Their blog is brilliant.

This is Matt Webb. Matt previously spoke at dConstruct back in 2007, when he gave a talk called The Experience Stack

An award-winning author from South Africa whose work has recently been adapted for television. Some of their work is kind of sci-fi, some of it is kind of horror, some of it is kind of magical realism, and all of it is great.

This is Lauren Beukes. Lauren previously spoke at dConstruct in 2012, when she gave a talk called Imagined Futures.

An artist and designer who has created logos and illustrations for NASA, Apple, and Intel as well as custom typefaces for British Airways and Waitrose. A lover of letterforms, they are now one of the world’s highest-profile calligraphers posting their mesmerising work on Instagram.

This is Seb Lester.

A Canadian digital designer who has previously worked in the agency world, at Silicon Valley startups, and even venture capital. But now they’re doing truly meaningful work, designing for busy healthcare workers in low-income countries.

This is Daniel Burka. Daniel previously spoke at dConstruct back in 2008, when he gave a talk called Designing for Interaction.

A multi-instrumentalist musician, producer and robotic artist who composes for film, theatre and the concert stage. They play a mean theremin.

This is Sarah Angliss. Sarah previously spoke at dConstruct in 2013, when she gave a talk called Tech and the Uncanny.

An Australian designer and entrepreneur. They work in the cultural heritage sector and they’re an expert on digital archives. Their latest challenge is working out how to make an online photography archive last for 100 years.

This is George Oates. George previously spoke at dConstruct back in 2007, where she and Denise Wilton had a conversation called Human Traffic.

A tireless defender of web standards and co-author of the Inclusive Design Principles. They’re a member of the W3C Advisory Board and of the BIMA Inclusive Design Council. Expect some thoughtful takes on the intersection of accessibility and emerging technologies.

This is Léonie Watson.

A professor of neuroscience who is also a bestselling author. They conduct experiments on people’s brains and then talk about it afterwards. Their talks have been known to be mind-altering.

This is Anil Seth.

That’s quite a line-up, isn’t it?

Deducing the full line-up just from those descriptions wasn’t easy, but Hidde de Vries managed it. So Hidde gets a free ticket to dConstruct 2022 …or, at least, he would if it weren’t for the fact that he already has a ticket (because Hidde is smart; be like Hidde). So a friend of Hidde’s is getting a free ticket instead (because Hidde is generous; be like Hidde).

If you’ve been putting off getting a ticket for dConstruct 2022 until you knew what the line-up would be, well, put off no longer.

You’ll want to be at the Duke of York’s in Brighton on Friday, September 9th. With this line-up of eight supersmart speakers, you know it’s going to be a fantastic day!

Monday, July 25th, 2022


In two of my recent talks—In And Out Of Style and Design Principles For The Web—I finish by looking at three different components:

  1. a button,
  2. a dropdown, and
  3. a datepicker.

In each case you could use native HTML elements:

  1. button,
  2. select, and
  3. input type="date".

Or you could use divs with a whole bunch of JavaScript and ARIA.

In the case of a datepicker, I totally understand why you’d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.

In the case of a dropdown, it’s less clear-cut. Personally, I’d use a select element. While it’s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That’s good enough for me.

Still, I can understand why that wouldn’t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you’re going to have to break out the JavaScript and ARIA.

Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling select elements. That’s one of the reasons why the work being done by the Open UI group is so important.

But there’s one more component: a button.

Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.

Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.

I’ve been trying to understand the mindset of a developer who wouldn’t use a native button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.

I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.

When I hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).

But I now understand that someone else might hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.

I get it. I don’t agree. But I get it.

If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren’t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.

But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It’s not what I would do, but I think I understand the motivation a bit better now.

Thursday, July 21st, 2022


A few years back, Jessica got a ceiling fan for our living room. This might seem like a strange decision, considering we live in England. Most of the time, the problem in this country is that it’s too cold.

But then you get situations like this week, when the country experienced the hottest temperatures ever recorded. I was very, very grateful for that ceiling fan. It may not get used for most of the year, but on the occasions when it’s needed, it’s a godsend. And it’s going to get used more and more often, given the inexorable momentum of the climate emergency.

Even with the ceiling fan, it was still very hot in the living room. I keep my musical instruments in that room, and they all responded to the changing temperature. The strings on my mandolin, bouzouki, and guitar went looser in the heat. The tuning dropped by at least a semitone.

I tuned them back up, but then I had to be careful when the extreme heat ended and the temperature began to drop. The strings began to tighten accordingly. My instruments went up a semitone.

I was thinking about this connection between sound and temperature when I was tuning the instruments back down again.

The electronic tuner I use shows the current tone in relation to the desired note: G, D, A, E. If the string is currently producing a tone that’s lower than, say, A, the tuner displays the difference on its little screen as lines behind the ideal A position. If the string is producing a tone higher than A, the lines appear in front of the desired note.

What if we thought about temperature like this? Instead of weather apps showing the absolute temperature in degrees, what if they showed the relative distance from a predefined ideal? Then you could see at a glance whether it’s a little cooler than you’d like, or a little hotter than you’d like.

Perhaps an interface like that would let you see at a glance how out of the tune the current temperature is.

Wednesday, July 20th, 2022

Subscribing to newsletters

I like reading RSS feeds. I’ve written before about how my feed reader feels different to my email client:

When I open my RSS reader to catch up on the feeds I’m subscribed to, it doesn’t feel like opening my email client. It feels more like opening a book. And, yes, books are also things to be completed—a bookmark not only marks my current page, it also acts as a progress bar—but books are for pleasure. The pleasure might come from escapism, or stimulation, or the pursuit of knowledge. That’s a very different category to email, calendars, and Slack.

Giles put it far better when described what using RSS feeds feels like :

To me, using RSS feeds to keep track of stuff I’m interested in is a good use of my time. It doesn’t feel like a burden, it doesn’t feel like I’m being tracked or spied on, and it doesn’t feel like I’m just another number in the ads game.

To me, it feels good. It’s a way of reading the web that better respects my time, is more likely to appeal to my interests, and isn’t trying to constantly sell me things.

That’s why I feel somewhat conflicted about email newsletters. On the one hand, people are publishing some really interesting things in newsletters. On the hand, the delivery mechanism is email, which feels burdensome. Add tracking into the mix, and they can feel downright icky.

But never fear! My feed reader came to the rescue. Many newsletter providers also provide RSS feeds. NetNewsWire—my feed reader of choice—will try to find the RSS feed that corresponds to the newsletter. Hurrah!

I get to read newsletters without being tracked, which is nice for me. But I also think it would be nice to let the authors of those newsletters know that I’m reading. So here’s a list of some of the newsletters I’m currently subscribed to in my feed reader:

The Whippet by McKinley Valentine:

A newsletter for the terminally curious.

Sentiers by Patrick Tanguay:

A carefully curated selection of articles with thoughtful commentary on technology, society, culture, and potential futures.

The Fitzwilliam:

Policy, ethics and applied rationality with an Irish slant.

The Science Of Fiction:

How science shapes stories about the future and how stories about the future shape science.

Adjacent Possible by Steven Johnson:

Exploring where good ideas come from—and how to keep them from turning against us.

Faster, Please! by James Pethokoukis:

Discovering, creating, and inventing a better world through technological innovation, economic growth, and pro-progress culture.

undefended / undefeated by Sara Hendren:

Ideas at the heart of material culture—the everyday stuff in all our lives

Today in Tabs by Rusty Foster:

Your favorite newsletter’s favorite newsletter.

Tuesday, July 19th, 2022

The line-up for dConstruct 2022

The line-up for dConstruct 2022 is complete!

If you haven’t yet got your ticket, it’s not too late.

Now here’s the thing…

When I announced the event back in May, I said:

I’m currently putting the line-up together. I’m not revealing anything just yet, but trust me, you will want to be there.

I still haven’t revealed anything, and I’m kind of tempted to keep it that way. Imagine showing up at an event and not knowing who’s going to be speaking. Is this is the best idea or the worst idea?

I suspect I’m going to have to announce the line-up at some point, but today is not that day. I’m going to string it out a bit longer.

But I am going to describe the line-up. And I’m going to throw in a challenge. The first person to figure out the complete line-up gets a free ticket. Send a tweet to the @dConstruct Twitter account with your deductions.

Ready? Here’s who’s speaking at dConstruct 2022 on Friday, September 9th in The Duke Of Yorks in Brighton…

  1. A technologist, product designer, and writer who defies categorisation. They’ve headed up a design studio, co-founded a start-up, and now consult on super-clever machine learning stuff. Their blog is brilliant.
  2. An award-winning author from South Africa whose work has recently been adapted for television. Some of their work is kind of sci-fi, some of it is kind of horror, some of it is kind of magical realism, and all of it is great.
  3. An artist and designer who has created logos and illustrations for NASA, Apple, and Intel as well as custom typefaces for British Airways and Waitrose. A lover of letterforms, they are now one of the world’s highest-profile calligraphers posting their mesmerising work on Instagram.
  4. A Canadian digital designer who has previously worked in the agency world, at Silicon Valley startups, and even venture capital. But now they’re doing truly meaningful work, designing for busy healthcare workers in low-income countries.
  5. A multi-instrumentalist musician, producer and robotic artist who composes for film, theatre and the concert stage. They play a mean theremin.
  6. An Australian designer and entrepreneur. They work in the cultural heritage sector and they’re an expert on digital archives. Their latest challenge is working out how to make an online photography archive last for 100 years.
  7. A tireless defender of web standards and co-author of the Inclusive Design Principles. They’re a member of the W3C Advisory Board and of the BIMA Inclusive Design Council. Expect some thoughtful takes on the intersection of accessibility and emerging technologies.
  8. A professor of neuroscience who is also a bestselling author. They conduct experiments on people’s brains and then talk about it afterwards. Their talks have been known to be mind-altering.

Sounds pretty freaking great, right?

Some further clues…

Many of these people have spoken at dConstruct in the past. After all, this year’s one-off event is going to be a kind of “best of.” So you might want to have a nose around the dConstruct archive.

Also, I’ve mentioned some nationalities like Australian, Canadian, and South African, but my self-imposed carbon footprint policy for this event forbids me from flying anyone in. So that’s a clue too.

The game is afoot! Tweet your deductions to the @dConstruct Twitter account or, even better, write a blog post and tweet the link, mentioning @dConstruct. The first correct answer gets a free ticket.

For everyone else, you can still get a ticket.

Thursday, June 30th, 2022


I no longer have Covid. I am released from isolation.

Alas, my negative diagnosis came too late for me to make it to UX London. But that’s okay—by the third and final day of the event, everything was running smooth like buttah! Had I shown up, I would’ve just got in the way. The Clearleft crew ran the event like a well-oiled machine.

I am in the coronaclear just in time to go away for a week. My original thinking was this would be my post-UX-London break to rest up for a while, but it turns out I’ve been getting plenty of rest during UX London.

I’m heading to the west coast of Ireland for The Willie Clancy Summer School, a trad music pilgrimage.

Jessica and I last went to Willie Week in 2019. We had a great time and I distinctly remember thinking “I’m definitely coming back next year!”

Well, a global pandemic put paid to that. The event ran online for the past two years. But now that it’s back for real, I wouldn’t miss it for the world.

My mandolin and I are bound for Miltown Malbay!

Wednesday, June 29th, 2022

Two books

I’ve mentioned before that I like to read a mixture of fiction of non-fiction. In fact, I try to alternate between the two. If I’ve just read some non-fiction, then I’ll follow it with a novel and I’ve just read some fiction, then I’ll follow it with some non-fiction.

But those categorisations can be slippery. I recently read two books that were ostensibly fiction but were strongly autobiographical and didn’t have the usual narrative structure of a novel.

Just to clarify, I’m not complaining! Quite the opposite. I enjoy the discomfort of not being able to pigeonhole a piece of writing so easily.

Also, both books were excellent.

The first one was A Ghost In The Throat by Doireann Ní Ghríofa. It’s sort of about the narrator’s obsessive quest to translate the Caoineadh Airt Uí Laoghaire. But it’s also about the translator’s life, which mirrors the author’s. And it’s about all life—life in its bodily, milky, bloody, crungey reality. The writing is astonishing, creating an earthy musky atmosphere. It feels vibrant and new but somehow ancient and eternal at the same time.

By contrast, No One Is Talking About This by Patricia Lockwood is rooted in technology. Reading the book feels like scrolling through Twitter, complete with nervous anxiety. Again, the narrator’s life mirrors that of the author, but this time the style has more of the arch detachment of the modern networked world.

It took me a little while at first, but then I settled into the book’s cadence and vibe. Then, once I felt like I had a handle on the kind of book I was reading, it began to subtly change. I won’t reveal how, because I want you to experience that change for yourself. It’s like a slow-building sucker punch.

When I started reading No One Is Talking About This, I thought it might end up being the kind of book where I would admire the writing, but it didn’t seem like a work that invited emotional connection.

I couldn’t have been more wrong. I can’t remember the last time a book had such an emotional impact on me. Maybe that’s because it so deliberately lowered my defences, but damn, when I finished reading the book, I was in pieces.

I’m still not quite sure how to classify A Ghost In The Throat or No One Is Talking About This but I don’t care. They’re both just great books.

Tuesday, June 28th, 2022


Today is the first day of UX London 2022 …and I’m not there. Stoopid Covid.

I’m still testing positive although I’m almost certainly near the end of my infection. But I don’t want to take any chances. Much as I hate to miss out on UX London, I would hate passing this on even more. So my isolation continues.

Chris jumped in at the last minute to do the hosting duties—thanks, Chris!

From the buzz I’m seeing on Twitter, it sounds like everything is going just great without me, which is great to see. Still, I’m experiencing plenty of FOMO—even more than the usual levels of FOMO I’d have when there’s a great conference happening that I’m not at.

To be honest, nearly all of my work on UX London was completed before the event. My number one task was putting the line-up together, and I have to say, I think I nailed it.

If I were there to host the event, it would mostly be for selfish reasons. I’d get a real kick out of introducing each one of the superb speakers. I’d probably get very tedious, repeatedly saying “Oh, you’re going to love this next one!” followed by “Wasn’t that great‽”

But UX London isn’t about me. It’s about the inspiring talks and practical workshops.

I wish I were there to experience it in person but I can still bask in the glow of a job well done, hearing how much people are enjoying the event.