1.

One day, as I was reading an essay on Medium, I saw an automatically inserted subscribe block:

But as I was exactly on top of it, a new thing popped in my view, an interruption on top of interruption, both saying the exact same thing:

2.

For a while now, whenever I try to follow a link to a site that no longer exists, Chrome shows a strange “This site doesn’t support a secure connection” flyout, just before hiding it itself, and then following it by a generic error page:

This feels truly eerie: either a bug where the flyout gets triggered too soon without having all the information, or the flyout is trying to warn you about Chrome’s very own internal page.

3.

Just this week, after already having been in Taiwan for five days, and after having used Apple Pay to pay for public many times on each of these days, Apple Maps helpfully told me that I can… use Apple Pay to pay for public transit:

4.

Some months ago, after finalizing my car reservation and moving my attention elsewhere, an automatic “keep the session warm or lose it” window appeared, suggesting my reservation might actually “expire”:

5.

Downloading is possible on YouTube Premium and actually helpful, allowing you to load up some videos ahead of a long flight. There even exists a section where it suggests some things to download.

However, download suggestions include member-only videos, and whenever you try to grab one of those, you get this result – a pretty poor “Video wasn’t downloaded” message:

6.

When I recently opened a dispute on PayPal for a keyboard I never received, at the end of the process, I saw these three screens in succession:

In effect the screens said, in order: we closed the case and decided in your favour, you haven’t finished filing the case, the case is open and we’ll update you.

7.

I feel uneasy bundling all these “the left hand doesn’t know what the right hand is doing” examples, because they’re not all the same.

Examples #1–3 from Medium, Chrome, and Apple Maps are frustrating and somewhat embarrassing, outbursts from badly-behaving software that doesn’t know that it’s not okay to throw pop-ups at the screen whenever you feel like it. I particularly dislike announcements of features that the user has already been using since they feel condescending to me, but I don’t want to assume it’ll be the same for everyone else.

Examples #4–6, however, are more insidious. Whether they happen because of plain old carelessness, or lack of imagination, or Conway’s Law – different teams not talking to each other – they can lead to people jumping to wrong conclusions or building entirely wrong mental models. Is my reservation truly done, or have I not actually finalized it? Is it possible to download member-only content, except I need to do something special to set it up? What is the status of my PayPal dispute?

The answers in this case: yes + no + the first screen was the one telling the truth. But each answer required extra effort for me to figure out, and that effort would be avoided if only someone tested the flows better.

Buttondown, a newsletter publisher, has a pretty standard CSS editor in its web app. You can edit the code and whenever you make any change, you can then press the Save button to make it go live:

The view also thoughtfully supports pressing ⌘S to do the same thing:

However, if there is nothing to save, ⌘S is ignored by the CSS editor, and falls back to the browser’s handling:

It feels logical: ⌘S only takes effect when the button is visible, otherwise why would a user press it? In a front-end sense, it might even seem thoughtful. We all witnessed web apps that greedily took over some interaction, and broke things in the process. Hell, I did that myself.

In theory, you – the user – take a careful look at the state of things, notice the button, and then press ⌘S.

But in practice? It’s none of the above. Fingers don’t look around. You might press ⌘S twice in a row. Or after an undo to an already saved state. Or after pressing another key so light it didn’t register. Or after just sitting down to an open document that’s already saved. Or because you weren’t sure if the previous ⌘S press worked. Or just to be sure. You might not know why, and you might not even notice. The beautiful raw power of ⌘S as a citizen of motor memory is that it’s automatic, mindless, habitual.

That’s why ⌘S here needs to be both deterministic and idempotent – if there is nothing to save, don’t let it fall back to the browser, don’t show an error message, don’t beep at the user. Just ignore the keystroke altogether.

It might feel funny, but there are tons of places in the UI that already look the other way. Off the top of my head:

• if you center align already center-aligned text in any writing app, the app just ignores you,
• if you press ⌘A to select all more than once, no one’s shouting at you,
• if you try to click a disabled button, the click gets quietly swallowed.

It gets a lot more interesting than these, but we’ll talk about more examples of “finger logic” in future posts.

Tangentially related to the previous post, this 8-minute video from CrowBranch is a fun tier list of various ways games try to keep you in bounds:

The limits here are I believe unrelated to precision, and rather to wanting to keep the player within a controlled, designed environment. (We once covered a story of this backfiring horribly, and also talked about skyboxes and streaming.)

The video also made me want to see people – especially designers with less experience slash less baggage than I have – doing a tier list of e.g. common interface elements. Or maybe I should make such a video…

A fun 16-minute video from PortalRunner with this premise:

This is an image file, containing a picture of my cat. But if I rename it to .MP4, it becomes a video file – also of my cat. If rename to .PDF, it becomes a text document containing the script for this video. It can also be a valid webpage, a .ZIP archive, or a PowerPoint presentation, all by simply changing the name. This kind of file is sometimes called a “polyglot” (although, usually that term refers to code that works in multiple programming languages).

This kind of a file is not something that you will realistically need, but it’s a fun look into various approaches to headers and structures of file formats – something we don’t usually get to think about a lot.

Buried inside the video is also an interesting digression: is the file extension just a method of delivering the file to the right application? If I rename .jpeg to .gif, and both are routed to Pixelmator, should Pixelmator do its best to detect it’s a JPEG file under the hood, or fail with a “this doesn’t look like a GIF file” message?

The web has a similar challenge in the form of MIME sniffing – “MIME” is sort of the web’s equivalent of extensions, “sniffing” means detecting the file from its contents alone, ignoring everything else – and that had some security considerations, as it allowed bad actors to sneak in some malicious code under the guise of something more innocuous… basically what the video is doing for fun, but now weaponized.

This is all pretty technical for this blog, but inside the Wikipedia entry for MIME sniffing is this passage that caught my attention:

[MIME sniffing is still used by some browsers. However,] by making sites which do not correctly assign MIME types to content appear to work correctly in those browsers, it fails to encourage the correct labeling of material, which in turn makes content sniffing necessary for these sites to work, creating a vicious circle of incompatibility with web standards and security best practices.

Decades before MIME sniffing, Jon Postel captured the essence of that line of thinking by coining Postel’s Law – “be conservative in what you send, be liberal in what you accept” – but as enticing as it is, that has challenges similar to the above quote:

A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. […] Ensuring interoperability in this environment is often referred to as aiming to be ”bug-for-bug compatible”.

While Postel’s Law was about data flowing in and out of computer systems, the premise is to me a more evergreen design question, applicable to so many other things. Feeling “liberal in what you accept” can feel helpful, but can teach users bad habits and have bigger consequences. For any project where this applies, it’s worth asking: should we go out of our way to help the user even if they mess up, or should we be more rigid and teach them to follow the rules more strictly, as it will benefit them in the future?

The Command Line Interface Guidelines I linked to before had a great example of that:

You can ask if they want to run the suggested command, but don’t force it on them. For example:

$ heroku pss
› Warning: pss is not a heroku command.
Did you mean ps? [y/n]:

Rather than suggesting the corrected syntax, you might be tempted to just run it for them, as if they’d typed it right in the first place. Sometimes this is the right thing to do, but not always.

Firstly, invalid input doesn’t necessarily imply a simple typo—it can often mean the user has made a logical mistake, or misused a shell variable. Assuming what they meant can be dangerous, especially if the resulting action modifies state.

Secondly, be aware that if you change what the user typed, they won’t learn the correct syntax. In effect, you’re ruling that the way they typed it is valid and correct, and you’re committing to supporting that indefinitely. Be intentional in making that decision, and document both syntaxes.

If there was one go-to example of an impenetrable error message in the 1980s, it must have been this – popping up, for example, if your disk drive was dirty:

On some technical level, the options made sense: “Abort” would stop whatever you were doing, “Retry” would try to repeat the action, and “Ignore” would proceed as if there was no error. But in the heat of a moment, or seeing it for the first time, this was a puzzling choice to be asked to make. Not only were the words weighted improperly (the seemingly most innocuous action here, “Ignore,” was actually the only one that could do actual lasting damage), but it also wasn’t entirely clear what’s the safe thing to do to get out of the situation.

(The redesign of “Abort, Retry, Ignore” was “Abort, Retry, Fail,” and it wasn’t really a huge improvement.)

Last night, I installed Google Photos on my iPhone, and the first message that greeted me was this:

This is really a matryoshka doll of bad dialog presentation.

First: any buttons in a dialog should be labeled with enough information to keep me going. Here, both have generic labels, so now I need to pay attention.

Second: Even after reading, I have no idea what is the choice I’m making. I see the pathway marked “yes, keep it the way I had it” and, sure – this would be generally what I want from any given computer on any given Sunday. But what’s the actual alternative?

But the third, and most important one, is this: this dialog has no safe escape hatch. By now, in UX design, we established quite a few canonical escape hatches:

• a Cancel button,
• a × close box,
• a “No, thanks” link,
• a press of an Escape key.

But you can’t × this dialog out. The main button seems positive, but it also feels like I’m taking an action with consequences, and I don’t want to deal with that. There is a “No, thanks,” but it doesn’t feel like the other “No, thankses” I have seen – it’s juxtaposed with copy that makes it seem… a dangerous thing to choose.

And this last bit makes it a pretty serious design offense, because you are now messing with foundational stuff. You need to protect those escape hatches for the future; the moment you introduce hesitation into the mix and taint “No, thanks” as a concept, really bad things will start happening all across your product.

In real life, fire doors have to open outwards when pushed with body weight, aircraft stick shakers are impossible to ignore, and anti-lock braking systems do smart things even after your brain turns off its smart parts.

I know seeing a dialog like this would never happen in a moment of true panic, but sometimes I think of the user in their most absent-minded moment: trying to get their kids to hurry up for school, on hold with an annoying cable provider, with a cat looking like it’s about to jump up directly into a running toaster. A dialog on their phone pops up. If that dialog absolutely has to happen, what is the escape hatch it can offer so they can dismiss it safely if they cannot think about it at all?

This Google Photos screen needs a lot more rethinking and rewriting, but in its current incarnation, it desperately needs a clear and trustworthy escape hatch I can tap absentmindedly, just so I can get to my photos.

Many of you have probably heard the repeated story of the first Moon landing in 1969 almost getting undone by a bunch of onboard computer glitches:

There could not be a worse time in the flight to have computer problems. At, the time the press gleefully reported how Armstrong seized manual control from a crippled and failing onboard computer and managed to heroically and single-handedly land the spaceship on the surface of the Moon against all odds.

Robert Wills argues against this narrative in this 2020 talk, wanting to shine a spotlight away from Neil Armstrong and toward people who designed the software (among them Margaret Hamilton), and the mission control’s Steve Bales, who made a decision not to abort the launch as the 1201 and 1202 errors were piling up.

The argument: the computer was working as intended, it fixed itself over and over again owing to its clever software, and it actually helped Buzz Aldrin understand (at least subconsciously) what led to the seemingly random and distracting computer errors.

The above is more of a traditional talk than the videos I usually share – a bit more technical, taking up an entire hour, and with generic slides – but it’s buoyed by Wills’s enthusiasm and knowledge.

Besides, it’s lunar landing! Did you know about DSKY and its fascinating keyboard and UI? Did you know the spacecraft’s window was part of the interface, too? Or that its software was woven into the hardware? Or that the Apollo 11 had a… guillotine in it?

Unaddressed in the talk, but also important:

An unsung hero of the decision not to abort the landing is Richard Koos, a NASA simulation supervisor who […] 11 days before the launch of Apollo 11, put the team of controllers including Bales […] through a simulation that intentionally triggered a 1201 alarm. […] Unable to figure out what the 1201 was, Bales aborted that simulated landing. He and Flight Director Gene Kranz were dressed down for it by Koos, who put the team through four more hours of training the next day specifically on program alarms. When the 1202 and 1201 alarms occurred during the actual landing, Garman, Bales, and even Duke recognized them immediately.

Fortune favors the prepared.

I still sometimes think of the miracle that is Undo Send in Gmail.

Michael Leggett announcing it in 2009:

This feature can’t pull back an email that’s already gone; it just holds your message for five seconds so you have a chance to hit the panic button. And don’t worry – if you close Gmail or your browser crashes in those few seconds, we’ll still send your message.

There’s so much cleverness hiding in here: recognizing that this particular flavour of l’esprit de l’escalier exists, shifting time from the past to the near future, the repurposing of the undo branding, the fallback if things go wrong.

There was, I imagine, even the challenge of having to forget about the previous version of this feature elsewhere, which were the awful emails with RECALL: in the title, which I think maybe only worked in Outlookk, if at all? (Everyone else suffered like green bubble people do today.) I don’t know. Sometimes the biggest hurdle to a great idea is blocking bad execution you already know from your head. On the other hand, sometimes someone else’s bad execution can be motivating.

I even think that not using ⌘Z for this was a clever idea. ⌘Z without text editing context/​focus can be really tricky. Do you remember when Safari had ⌘Z to bring back last closed tab before they came to their senses and used ⌘⇧T like Chrome?

It is sometimes harrowing when you want to click it Undo Send and just miss it – keyboard is more precise here – but not sure ⌘Z would register here. Even Esc would be tricky.

I miss when Gmail was in the “young and open to trying new things” phase.