I mentioned placeholders before in the context of Dropbox Paper…

…and I wanted to share a response by Nikita Prokopov, because he had a great point about those Dropbox Paper placeholders that I didn’t consider:

For me it’s […] confusing placement. Like if somebody writes “Have a nice day” on a door instead of “Push” or “Pull”. I don’t mind seeing “Have a nice day” message somewhere neutral, in a place not occupied by any other function, but not where I expect very specific help.

I was reminded of Prokopov’s comment when I saw this at the airport yesterday:

I remember, eons ago, how impressed I was when one of the Chrome designers was telling me how all of these error pages were specifically designed to feel like liminal spaces and not like destinations. These were, in a way, placeholder content.

But “Press space to play” feels like a strange thing to put in here. (Previously, the message said “No internet” or “There is no Internet connection.”) I understand that this is Chrome’s popular mascot, but this is still an error page whose purpose is to tell me what’s wrong, rather than serve as an entry point to a minigame.

Also, just a few days ago, I just stumbled upon this fun example of a placeholder collapse – where a temporary text becomes permanent:

If you are curious, this is what it looks like if you don’t forget to set the message. And funnily enough, given where we started, it says “Have a nice day”:

To be fair, I am traveling and haven’t looked for solid evidence or citation that this works for people, but I personally like this approach: in lieu of a separate language selector button, each option here itself is both a language selector and a commit button.

The labels themselves are not the name of the language, but a call to action; I imagine recognizing the one label that means something to you should be easy if the other nine look like gibberish.

And, a thoughtful moment by one exhibit: Not only showing you where you are in the sequence of three videos, but even within the currently-playing video.

(I’m less of a fan of stretched type, though.)

Speaking of fly-by-wire… William Langewiesche is one of my favourite technical writers. He finds a way to explain complex aviation aspects really well, and then add a certain amount of beauty and poetry on top of that. His style was a big influence on my book, and I like him so much I once compiled links to his writing so that others could find it more easily.

Here’s Langewiesche’s essay from 2014 about the 2009 Air France Flight 447, where an implementation of fly-by-wire – which means disconnecting the flight stick and attendant levers from immediately controlling flight surfaces via physical linkage, and instead putting motors and software in between – caused a fatal accident, as the pilots’ mental model of the system diverged too far from what was happening:

The [Airbus] A330 is a masterpiece of design, and one of the most foolproof airplanes ever built. How could a brief airspeed indication failure in an uncritical phase of the flight have caused these Air France pilots to get so tangled up? And how could they not have understood that the airplane had stalled? The roots of the problem seem to lie paradoxically in the very same cockpit designs that have helped to make the last few generations of airliners extraordinarily safe and easy to fly.

It’s an interesting read today in the context of robotaxis and self-driving, but also AI changing software writing:

This is another unintended consequence of designing airplanes that anyone can fly: anyone can take you up on the offer. Beyond the degradation of basic skills of people who may once have been competent pilots, the fourth-generation jets have enabled people who probably never had the skills to begin with and should not have been in the cockpit. As a result, the mental makeup of airline pilots has changed. On this there is nearly universal agreement—at Boeing and Airbus, and among accident investigators, regulators, flight-operations managers, instructors, and academics. A different crowd is flying now, and though excellent pilots still work the job, on average the knowledge base has become very thin.

It seems that we are locked into a spiral in which poor human performance begets automation, which worsens human performance, which begets increasing automation.

I was devastated to discover, while writing this post, that Langewiesche died last year. Rest in peace.

One of my favourite genres is “I’m going to teach you something secretly while you’re having fun.”

This 2020 post by George Cave is ostensibly about Lego interface panels, but quietly sneaks in some stuff about shape coding and other kinds of coding:

The Lego interface panels seem to have a certain hold on people. Artist Love Hultén recreated some of them in a more human-compatible scale and even made them interactive:

It was fun to see one of the most well-crafted of early arcade games, Tempest, in this kind of a view, with the stud reimagined as a paddle controller:

Just earlier this month, designer Paul Stall announced his project M2x2 (the page itself is beautiful and interesting to visit – I paticularly loved the horizontal galleries):

The M2x2 is a functional homage to the classic Lego computer brick, upscaled and re-imagined as a high-performance workstation. […]

If our tools could look as playful as the things we built as kids, would we approach our work with more joy? The M2x2 is just the beginning of a workspace that feels less like an office and more like a laboratory for breakthroughs.

But both of these are enlarged Lego bricks. Three years ago, James Brown a.k.a. Ancient made an effort to embed an LCD screen in a regular-size Lego brick. It’s a fun 12-minute video of the construction process:

If you are into that kind of stuff, Brown followed it up 2 months later by putting a playable Doom inside a Lego brick:

But the most amazing to me outcome was this video, called “Busy little screens”:

A lot of diversity of the original bricks is gone, but it’s hard to expect Brown to recreate and animate them all. It’s a mesmerizing thing to watch nonetheless; one can almost taste a future where the technology will allow for Lego bricks to be animated, but look exactly as they originally did.

I know some of you are all whispering “he’s posting all of these hour-long YouTube videos, when am I supposed to find time to watch them”? I hear you loud and clear and I’m going to make it better…

…by sharing this four-plus-hour long YouTube video by Jenny Nicholson from May 2024 – just so those other videos will feel short in comparison:

Seriously, though, this is an extremely enjoyable deep dive into Disney’s failed Galactic Starcruiser hotel.

I don’t know much about Disney, but it was engrossing as half of the failures were actually software-related: from the flawed UI in various spaces in the hotel and screen-laden space windows in the rooms, to poor integration with physical elements of the scenery, an “immersive” interactive game that felt untested plus gave you poor feedback, and the general trends of laziness and cheapness that could never fully be remedied by the performers going above and beyond.

What Nicholson does a lot is trying to debug what actually happened to make her experience so miserable, and it’s really refreshing to see debugging in a different context than I usually see it.

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.

Old-school computing has a term “molly guard”: it’s the little plastic safety cover you have to move out of the way before you press some button of significance.

Anecdotally, this is named after Molly, an engineer’s daughter who was invited to a datacenter and promptly pressed a big red button, as one would.

Then she did it again later the same day.

You might recognize molly guards from any aerial combat movie you ever watched:

And some vestigial forms of molly guards exist everywhere in civilian hardware, too: from recessed buttons, through plastic ridges around keys, to something like a SIM card ejection hole.

Of course, molly guards happen in software, too: from the cheapest “are you sure?” dialogs (which sometimes move buttons around or disable keyboard activation to slow you down), through extra modifier keys (in Ctrl+Alt+Del, the Ctrl and Alt keys are the guards), to more elaborate interactions that introduce friction in places where it’s needed:

But it’s also worth thinking of reverse molly guards: buttons that will press themselves if you don’t do anything after a while.

I see them sometimes, and always consider them very thoughtful. This is the first example that comes to my mind:

Here’s what became a standard mobile pattern:

These feel important to remember, particularly if your computer is about to embark on a long process to do something complex – like an OS update or a long render.

There is no worse feeling than waking up, walking up to the machine that was supposed to work through the night, and seeing it did absolutely nothing, stupidly waiting for hours for a response to a question that didn’t even matter.

It’s good to think about designing and signposting those flows so people know when they can walk away with confidence, and I sometimes think a reverse molly guard could serve an important purpose: in a well-designed flow, once you see it, you know things will now proceed to completion.

After James Moylan’s death in December, we were reminded again of the Moylan Arrow, the little arrow telling you which side of your car has the little fuel door:

I started wondering: what would be the conceptual equivalent of this in software? My best guess would be iOS offering to fill the one-time code from a recent SMS:

This is what it has in common with the Moylan Arrow:

• everyone benefits from it
• it happens all the time
• it solves an actual little (but not too little) frustration
• it’s there at the right place at the right time
• it is relatively low-tech (it’s not an overdesigned or an overengineered solution)
• once you know it’s there, you will love it forever

Curtosis on Mastodon unearthed the original 2019 Twitter thread from one the creator of the iOS feature, Ricky Mondello (link to XCancel), which I‘m reproducing here:

The idea for Security Code AutoFill came out of a small group of software engineers working on what we thought was a much more ambitious project. It wasn’t a PM, it wasn’t just one person, and it wasn’t what we set out to do initially.

It started as a small side idea we had while designing something very different. We jotted it down, tabled it for weeks, and then picked it up after the “more ambitious” project wasn’t panning out. It was hard, but I’m so glad we changed focus.

Even with a gem of an idea, it was still just an idea. Ideas are obviously super important — they’re necessary, but not sufficient. Here, the end result came from the idea, teamwork, and execution.

Years later, I’m still so proud of the team for making this feature happen. The team combined expertise from several areas to ship magic that worked on day 1, while asking nothing of app and website developers, without giving anyone your text messages. This still inspires me!

To every one of the folks who made this happen, I’m still in awe. Y’all are the best. <3

Addendum: FAQs
- “SMS is bad.”
↪ I know.

- “MITM.”
↪ I know.

- “FIDO is better.”
↪ It’s complicated, but acknowledged; I totally get it.

- “Android did it first.”
↪ Nah. Details matter. Privacy matters. And clipboard != AutoFill.

- *negativity*
↪ Not now. :)

I asked others on social and here are some other contenders I liked:

• The indicator that alerts you of Caps Lock when typing passwords
• Underlined letters in Windows
• Return key as an equivalent of the default action in a dialog box
• Proportionally-sized scroll bar handles
• Showing the current folder at the prompt in the terminal
• The quick link to your post after you post it
• The preview of the outside of the frame from the wide angle lens in the Camera app
• Holding space to move your cursor in iOS
• iPod automatically pausing music when you unplug the headphone jack

You can check out Mastodon and Bluesky threads for more ideas, if you are interested.

When I was in Hong Kong a few months ago, I noticed that a lot of intercoms have this particular animation of a cat sleeping and chasing a fly, on a loop:

It was actually kind of fun to see it all over Hong Kong on LCDs of varying quality.

Turns out this was Neko! A “screenmate” application from the late 1980s that made its way to various software platforms and apps since.

I liked the idea that somewhere in the intercom factory someone wanted to add a little delight to a very pedestrian (no pun intended) surface, and that’s why now we have Neko all over Hong Kong.

(I liked it so much I recreated it and added to the bottom of my site.)

Even though this blog is about software, I might occasionally post some inspiration from real life. I saw this today outside of an RTA transit station in Cleveland. I have not seen it light up, but I imagine it would blink when the train is near the station, which would mean: hurry up if you want to catch the next train.

It reminded me of this disambiguation detail in Finder in a way: a tiny but thoughtful detail at the right moment can go a long way.

In Kraków last year, I saw a great variant of this: A tram waiting at the terminus would show exactly when it departs, so you can choose to rush when it’s close, or to run a quick errand if it’s not.

(I know a lot of countries have extremely user-friendly transit systems where those details were hot news 30 years ago, but I do not take them for granted.)

I have never before heard of this story of an absolutely botched deployment of a new accounting system at the British post office, and “the widest miscarriage of justice in UK history.” More on Wikipedia:

Between 2000 and 2015, 736 subpostmasters were prosecuted by the UK Post Office, with many falsely convicted and sent to prison. The subpostmasters were blamed for financial shortfalls which actually were caused by software defects in the Post Office’s Horizon accounting software.

Some of these bugs sound absolutely horrendous, and remind me of Therac-25:

The Horizon IT system contained “hundreds” of bugs. Some of those that came to light were named after the post offices where the bug first occurred. These bugs included: the “Dalmellington bug”, where the system would enter repeated withdrawals in the ledger every time the user pressed Enter at a frozen interface screen; and the “Callendar Square bug”, where the system would create duplicate database entries in the ledger.

This bit feels absolutely crucial and it seemed to me we have learned this lesson decades ago:

And while the technology had changed, the contract between the Post Office and subpostmasters, who owned their own businesses but were agents for the Post Office, remained the same. It stated that any accounting shortfalls were the responsibility of the subpostmasters unless they could prove otherwise. But without the chain of evidence created by paper-based accounting methods, proving the losses were not their fault was near impossible for many.

I hope it’s okay for me to link to my work once in a while.

Today, I published a photo essay about my favourite tech museums. A lot of it doesn’t have to do with software, but in general it’s about craft and good user experience in this specific context.

If you are interested specifically in software, the ACMI part has some of good examples of integration of software in invisible, delightful ways.

This still remains one of my favourite pieces of UI ever designed. I know this is is not software, but this to me is exactly the right kind of “delight” in this context.

(Apologies for a shoddy video.)

A 2021 article by David Hall about shape coding:

Chapanis began interviewing pilots who had crashed B-17s and B-25s and a pattern emerged that turned his attention to the controls within the cockpit. As Fitts said ‘the intense effort to produce new weapons, the race against time in industrial production, and the magnitude of the program required to train men to operate these new machines resulted inevitably in many instances in which the final man-machine combination failed to function effectively.’

What Chapanis found when inspecting the cockpits of these planes were two identical toggle switches side by side, one for the landing gear, the other for the landing flaps. These controls were also similar in size and shape. […]

He modified the landing gear control by adding a wheel-shaped knob and a wedge like shape to the wing flap control. Now pilots could feel and easily map the shape to the intended purpose. […] Chapanis had solved a real life and death issue with one brilliant insight.

Chapanis was a contemporary of Fitts of Fitts’s Law fame.

I forgot this was called “shape coding,” or perhaps I never knew that? I have employed and sometimes pushed for a similar thing, but I called it making sure things have “distinct visual signature” or something like this. I think “shape coding” would be a more appropriate term.

The article shows one simple UX example – I would love to learn more about who’s employing this deliberately. It is, after all, the opposite force to consistency, and I’m always interested in negotiating with consistency.

Ash K on Mastodon:

Computers Are Bad is an acquired taste and I’m acquiring it. This was an excellent post going deep into the myths and anti-myths of elevator close door buttons, and pedestrian crossing buttons. I love storytelling + rigor:

First, anyone who says that the “door close” buttons in elevators are routinely “not even hooked up” shouldn’t be trusted. The world is full of many elevators and I’m sure some can be found with mechanically non-functional door close buttons, but the issue should be infrequent. The “door close” button is required to operate the elevator in fire service mode, which disables automatic closing of the doors entirely so that the elevator does not leave a firefighter stranded. Fire service mode must be tested as part of the regular inspection of the elevator (ASME A17.1-2019, but implemented through various state and local codes). Therefore, elevators with a “door close” button that isn’t “hooked up” will fail their annual inspections.

Also, this bit was delightful:

The software, as I recall, came from the school of industrial software design where a major component of the interface was a large tree view of every option and discoverability came in the form of some items being in ALL CAPS.