Simon describes the pattern he uses for content sites to get all of the resilience of static site generators while keeping dynamic functionality.
Thursday, July 29th, 2021
Thursday, July 22nd, 2021
When we find remains of beavers, we assume they built beaver dams, even if we don’t immediately find remnants of such dams. The beaver dams are part of what biologists would call the animal’s extended phenotype, an unavoidable necessity of the ecological niche that the beaver occupies. When we find Homo sapiens skeletons, however, we instead imagine the people naked, feasting on berries, without shelter, and without social differentiation.
Tuesday, July 6th, 2021
Personally, I’m not convinced that a new element is needed but I’m open to the suggestion.
I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.
Tuesday, June 29th, 2021
Flat, minimalist, clean, material - whatever you want to call it - is an annoying antipattern. Computers are here to make life easier for humans. Removing affordances is just a nasty thing to do to your users.
Friday, June 25th, 2021
Tuesday, April 20th, 2021
A curated list of awesome framework-agnostic standalone web components.
Thursday, April 1st, 2021
An excellent explainer from Trys and James of their supersmart Utopia approach:
Utopia encourages the curation of a system small enough to be held in short-term memory, rather than one so sprawling it must be constantly referred to.
Wednesday, March 31st, 2021
Many, if not all, of our world’s most wicked problems are rooted in the excessive hiding of complexity behind illusions of simplicity—the relentless shielding of messy details in favor of easy-to-use interfaces.
But there’s always a tradeoff between complexity, truth, and control. The more details are hidden, the harder it is to understand how the system actually works. (And the harder it is to control). The map becomes less and less representative of the territory. We often trade completeness and control for simplicity. We’d rather have a map that’s easy to navigate than a map that shows us every single detail about the territory. We’d rather have a simple user interface than an infinitely flexible one that exposes a bunch of switches and settings. We don’t want to have to think too hard. We just want to get where we’re going.
Seamful and seamless design are reframed here as ethical and deceptive design:
Ethical design is like a glove. It obscures the underlying structure (i.e. your hand) but preserves some truth about its shape and how it works. Deceptive design is like a mitten. It obscures the underlying structure and also hides a lot about its shape and how it works.
Tuesday, March 30th, 2021
The principle of most availability
I’ve been thinking some more about the technical experience of booking a vaccination apointment and how much joy it brought me.
All of those technologies are platform-agnostic.
No matter what operating system I’m using, or what email software I’ve chosen, email works. It gets more complicated when you introduce HTML email. My response to that is the same as the old joke; you know the one: “Doctor, it hurts when I do this.” (“Well, don’t do that.”)
No matter what operating system my phone is using, SMS works. It gets more complicated when you introduce read receipts, memoji, or other additions. See my response to HTML email.
Then there’s the web. No matter what operating system I’m using on a device that could be a phone or a tablet or a laptop or desktop tower, and no matter what browser I’ve chosen to use, the World Wide Web works.
It feels like the principle of least power in action.
But another way of rephrasing “least power” is “most availability.” Technologies that are old, simple, and boring tend to be more widely available.
I remember when software used to come packaged in boxes and displayed on shelves. The packaging always had a list on the side. It looked like the nutritional information on a food product, but this was a list of “system requirements”: operating system, graphics card, sound card, CPU. I never liked the idea of system requirements. It felt so …exclusionary. And for me, the promise of technology was liberation and freedom to act on my own terms.
Alas, many developers don’t build with this mindset. I mean, I understand why: it means thinking about users with the most boring, least powerful technology. It’s simpler and more exciting to assume that everyone’s got a shared baseline of newer technology. But by doing that, you’re missing out on one of the web’s superpowers: that something served up at the same URL with the same underlying code can simultaneously serve people with older technology and also provide a whizz-bang experience to people with the latest and greatest technology.
Anyway, I’ve been thinking about the kind of communication technologies that are as universal as email, SMS, and the web.
QR codes are kind of heading in that direction, although I still have qualms because of their proprietary history. But there’s something nice and lo-fi about them. They’re like print stylesheets in reverse (and I love print stylesheets). A funky little bridge between the physical and the digital. I just wish they weren’t so opaque: you never know if scanning that QR code will actually take you to the promised resource, or if you’re about to rickroll yourself.
Telephone numbers kind of fall into the same category as SMS, but with the added option of voice. I’ve always found the prospect of doing something with, say, Twilio’s API more interesting than building something inside a walled garden like Facebook Messenger or Alexa.
I know very little about chat apps or voice apps, but I don’t think there’s a cross-platform format that works with different products, right? I imagine it’s like the situation with native apps which require a different codebase for each app store and operating system. And so there’s a constant stream of technologies that try to fulfil the dream of writing once and running everywhere: React Native, Flutter.
They’re trying to solve a very clear and obvious problem: writing the same app more than once is really wasteful. But that’s the nature of the game when it comes to runtime-specific apps. The only alternative is to either deliberately limit your audience …or apply the principle of least power/most availability.
The wastefulness of having to write the same app for multiple platforms isn’t the only thing that puts me off making native apps. The exclusivity works in two directions. There’s the exclusive nature of the runtime that requires a bespoke codebase. There’s also the exclusive nature of the app store. It feels like a return to shelves of packaged software with strict system requirements. You can’t just walk in and put your software on the shelf. That’s the shopkeeper’s job.
There is no shopkeeper for the World Wide Web.
Monday, March 22nd, 2021
Vitaly has rounded up a whole load of accessibility posts. I think I’ve linked to most of them at some point, but it’s great to have them all gathered together in one place.
Wednesday, March 17th, 2021
Tuesday, March 9th, 2021
One of my roles at Clearleft is “content buddy.” If anyone is writing a talk, or a blog post, or a proposal and they want an extra pair of eyes on it, I’m there to help.
Sometimes a colleague will send a link to a Google Doc where they’ve written an article. I can then go through it and suggest changes. Using the “suggest” mode rather than the “edit” mode in Google Docs means that they can accept or reject each suggestion later.
But what works better—and is far more fun—is if we arrange to have a video call while we both have the Google Doc open in our browsers. That way, instead of just getting the suggestions, we can talk through the reasoning behind each one. It feels more like teaching them to fish instead of giving them a grammatically correct fish.
Some of the suggestions are very minor; punctuation, capitalisation, stuff like that. Where it gets really interesting is trying to figure out and explain why some sentence constructions feel better than others.
A fairly straightforward example is long sentences. Not all long sentences are bad, but the longer a sentence gets, the more it runs the risk of overwhelming the reader. So if there’s an opportunity to split one long sentence into two shorter sentences, I’ll usually recommend that.
Here’s an example from Chris’s post, Delivering training remotely – the same yet different. The original sentence read:
I recently had the privilege of running some training sessions on product design and research techniques with the design team at Duck Duck Go.
There’s nothing wrong with that. But maybe this is a little easier to digest:
I recently had the privilege of running some training sessions with the design team at Duck Duck Go. We covered product design and research techniques.
Perhaps this is kind of like the single responsibility principle in programming. Whereas the initial version was one sentence that conveyed two pieces of information (who the training was with and what the training covered), the final version has a separate sentence for each piece of information.
I wouldn’t take that idea too far though. Otherwise you’d end up with something quite stilted and robotic.
Speaking of sounding robotic, I’ve noticed that people sometimes avoid using contractions when they’re writing online: “there is” instead of “there’s” or “I am” instead of “I’m.” Avoiding contractions seems to be more professional, but actually it makes the writing a bit too formal. There’s a danger of sounding like a legal contract. Or a Vulcan.
Sometimes a long sentence can’t be broken down into shorter sentences. In that case, I watch out for how much cognitive load the sentence is doling out to the reader.
Here’s an example from Maite’s post, How to engage the right people when recruiting in house for research. One sentence initially read:
The relevance of the people you invite to participate in a study and the information they provide have a great impact on the quality of the insights that you get.
The verb comes quite late there. As a reader, until I get to “have a great impact”, I have to keep track of everything up to that point. Here’s a rephrased version:
The quality of the insights that you get depends on the relevance of the people you invite to participate in a study and the information they provide.
Okay, there are two changes there. First of all, the verb is now “depends on” instead of “have a great impact on.” I think that’s a bit clearer. Secondly, the verb comes sooner. Now I only have to keep track of the words up until “depends on”. After that, I can flush my memory buffer.
Here’s another changed sentence from the same article. The initial sentence read:
You will have to communicate at different times and for different reasons with your research participants.
I suggested changing that to:
You will have to communicate with your research participants at different times and for different reasons.
To be honest, I find it hard to explain why that second version flows better. I think it’s related to the idea of reducing dependencies. The subject “your research participants” is dependent on the verb “to communicate with.” So it makes more sense to keep them together instead of putting a subclause between them. The subclause can go afterwards instead: “at different times and for different reasons.”
Here’s one final example from Katie’s post, Service Designers don’t design services, we all do. One sentence initially read:
Understanding the relationships between these moments, digital and non-digital, and designing across and between these moments is key to creating a compelling user experience.
That sentence could be broken into shorter sentences, but it might lose some impact. Still, it can be rephrased so the reader doesn’t have to do as much work. As it stands, until the reader gets to “is key to creating”, they have to keep track of everything before that. It’s like the feeling of copying and pasting. If you copy something to the clipboard, you want to paste it as soon as possible. The longer you have to hold onto it, the more uncomfortable it feels.
So here’s the reworked version:
The key to creating a compelling user experience is understanding the relationships between these moments, digital and non-digital, and designing across and between these moments.
As a reader, I can digest and discard each of these pieces in turn:
- The key to creating a compelling user experience is…
- understanding the relationships between these moments…
- digital and non-digital…
- designing across and between these moments.
Maybe I should’ve suggested “between these digital and non-digital moments” instead of “between these moments, digital and non-digital”. But then I worry that I’m intruding on the author’s style too much. With the finished sentence, it still feels like a rousing rallying cry in Katie’s voice, but slightly adjusted to flow a little easier.
I must say, I really, really enjoy being a content buddy. I know the word “editor” would be the usual descriptor, but I like how unintimidating “content buddy” sounds.
I am almost certainly a terrible content buddy to myself. Just as I ignore my own advice about preparing conference talks, I’m sure I go against my own editorial advice every time I blurt out a blog post here. But there’s one piece I’ve given to others that I try to stick to: write like you speak.
Sunday, March 7th, 2021
This is easily my favourite use of a machine learning algorithm.
Thursday, February 11th, 2021
The problem with developing front end projects isn’t that it’s harder or more complicated, it’s that you made it harder and more complicated.
Web development did not change. Web development grew. There are more options now, not different options.
You choose complexity. You can also choose simplicity.
Wednesday, February 10th, 2021
I can relate to the sentiment.
Starting a new project? Make sure to write your project idea down because by the time you are finished setting up the vast boilerplate you have probably forgotten it.
Thursday, February 4th, 2021
Sounds like some convergent thinking with the ideas behind Utopia.
I think that the idea that that any typographic attribute (including variable font parameters) can be a function (linear, exponential, stepped, Bezier, random, or otherwise) of any given input variable (user preference, screen dimensions, connection speed, time of day, display language, or whatever else) is an incredibly powerful one, and worth exploring as an aesthetic as well as a technical proposition.
Here’s a demo you can play with.
Monday, February 1st, 2021
Thursday, January 28th, 2021
Sunday, January 3rd, 2021
My stack requires no maintenance, has perfect Lighthouse scores, will never have any security vulnerability, is based on open standards, is portable, has an instant dev loop, has no build step and… will outlive any other stack.