1.
In last year’s essay at Tedium, Ernie Smith investigated the rise and fall of screensavers, those pieces of software that peaked in the 1990s, originally meant to prolong the life of your display by kicking in after a period of inactivity, but eventually becoming “self-contained art projects.”

As it always happens, what we thought was the first screensaver – Peter Socha’s SCRNSAVE – was far from the original idea:

The accepted answer is often the easy answer, and when doing a little research, you can bust past that to the point of truth. [… But] while Socha deserves credit for popularizing the technique with a broad audience, the idea wasn’t totally new. See, during the 1970s and early 1980s, numerous hardware and software developers attempted to build things in the same wheelhouse as Socha’s early screen saver. The difference was, they weren’t for the IBM PC or even for a computer at all. Rather, they were for dumb terminals or video game systems.

The prior art includes “attract mode” in arcade games, and is accompanied by the absolutely terrifying, jump-scare-adjacent photo of CRT burn-in you wouldn’t want to miss.

2.
This is an enthralling 1-hour-long video by Savvy Sage that talks about the immense popularity of After Dark, a collection of screensavers for Macs and PCs, of the “flying toasters” fame:

This video absolutely blew my mind. I had no idea the screensavers were so popular that they had their own (official) merch and (unofficial) guidebooks, and that the company that made them employed over 100 people – half of them artists – and had tens of millions of dollars in revenue.

There’s tons of inevitable scope creep – screensaver remixers! screensavers with sound! interactive screensavers! licensed screensavers? – but also attempts to branch out to new ideas.

The video is great in documenting everything so you actually see all that’s talked about, in copious detail. And since this is a blog about craft, obligatory caveat: most of these screensavers are absolutely garish, although one also has to account for state of the art of computer graphics at that time.

3.
After Dark had a fish aquarium and so did competing products from Microsoft and Fifth Generation Systems – but in a moment likely recognizable to many people reading this blog, one person got fed up with how bad they all looked and created his own screensaver that became as well known as the flying toasters.

This 16-minute video by LGR talks about the story of The Marine Aquarium Screensaver:

This, too, had a lot more going on than I expected, including the eventual appearance of a hall-of-fame checkbox “Starfish allowed on glass.”

4.
Another popular screensaver was Windows’s 3D Pipes, whose (much shorter) origin story is documented by Raymond Chen on his excellent and long-running The Old New Thing blog.

But it’s the first comment there that steals the show:

These were mesmerizing, but quite often IT folks would enable these on Windows Servers, and they would essentially “bring down the system.” See, they were CPU intensive and would take a tax on the system essentially stealing CPU time away from the business application running. […]

I can recall the first time getting a call on this – and back then things were remote, etc. sometimes using PCAnywhere – and then I saw 3D Pipes running. Just told them to turn it off – and done. From that point forward the first question asked of our customers was “are you running any screen savers?”

3D Pipes also had some interesting lore behind it:

A customer complained that they were losing productivity because employees were spending too much time running the 3D Pipes screen saver and waiting for teapots to appear. They requested an option to increase the likelihood of a teapot, so the employees would be placated more quickly and get back to their work.

If this doesn’t remind you of that scene from The Office with another famous screensaver…

5.
In Smith’s essay, he posts Socha’s recounting of the exact logic of his early screensaver:

How does Scrnsave do all this? The clock inside your PC ticks 18.2 times per second. Scrnsave contains a three-minute counter that starts at 3276—the number of clock ticks for three minutes. On each tick of the clock, Scrnsave subtracts one from this count, and it turns off the screen when it reaches zero. […]

Each time you push or release a key, the keyboard sends an interrupt signal to the PC. Scrnsave intercepts this interrupt; each time you push or release a key, Scrnsave resets its counter to 3276 (three minutes) before passing control to the ROM BIOS routines that read keystrokes. Scrnsave also resets its counter to 3276 every time a program sends characters to the screen. By intercepting these last two interrupts, Scrnsave can tell when you need to have the screen active, so it won’t shut out the lights unless you sit back or walk away for three minutes or more.

It’s a very simple algorithm, but I was amazed by it, because that’s exactly the same algorithm you would use – in reverse – for any sort of debouncing that’s crucial in good front-end engineering; there is something kind of beautiful about these universal algorithms floating around, kind of like math quietly ruling the world around us.

But on that note, one last video. Do you remember that well-known palette-cycling waterfall I posted some time ago?

This wasn’t as much a “prevent CRT burn in” screensaver as it was “a piece of standalone, repeating, interactive art” screensaver. It graced many an Atari ST display.

Well, in April, a YouTuber Techmoan unpacked sort of a “prior art” to that, too – a picture frame that simulates a waterfall (the relevant video segment starts at 6:04):

The art is (again) garish, and there is no screen to save here, but also curiously – there are no electronics at all, either. How was it made? I’ll let you click through to find out.

It was fun for me to revisit this strange moment in time and learn more. It’s not just that there were tons of shared ideas, repeated algorithms, independent reinventions, and one-upping each other. What stood out to me was also how many people engaged here did other things I used and admired – SCRNSAVE’s Peter Socha created the absolute 🐐 Norton Commander, Jim Sachs of the marine aquarium screensaver fame did graphics for the legendary Defender of the Crown game, a few people at After Dark also made the original zoom peek gesture before that, and the incredible The Incredible Machine after.

It seems like a fascinating time that attracted people equally interested in tech as they were in its creative uses.

Ever since I wrote a post about the molly guard, I have been on the lookout for those, and I think I collected enough to do a little follow-up.

First, some classic industrial molly guards from a museum in Germany:

This IBM electronic typewriter had a gorgeous perspex molly guard around the power button:

Other machines opted for “softer” quasi molly guards that still aimed to prevent you from pressing a button or switch by accident, but without having to get something out of the way first:

Even softer? This below is not a traditional molly guard, but the placement of “I’m writing to the SD card” red light was not accidental. Ejecting the card while the camera is writing to it might cause some damage, so the light was positioned right next to the card door and the card itself, making you more likely to spot it and wait:

This one is even more clever. You know how some old floppy drives have a handle that lowers the reading/​writing head so that the diskette can be used? That same handle also prevented you from pulling the disk once the head was lowered. It felt so natural, you might not have even realized it’s a molly guard doing its job:

On the other side, these following guards are more of a “you really shouldn’t do this” variety – much closer to a disabled state in graphical user interfaces:

Let’s jump into software.

This is a nice situational molly guard in Finder when you press ⌘O and have a lot of files selected:

iPhone’s “slide to unlock” no longer graces the home screen, with one exception – stopping the alarm:

There’s something about this treatment that doesn’t sit well with me. I’m not sure what it is: The text not feeling centered? The control being circular? The icon on the slider making it seem like it’s a stop button you can press?

Speaking of stuff I don’t love, you might recognize this molly guard from Chrome:

This one never felt pleasant to me. You might say “isn’t the point of the molly guard that it doesn’t feel pleasant”? But I think one needs to separate the intent and the mechanics. I don’t mind the intent here, but the styling is ugly, the message kind of confusing – you don’t really have to hold ⌘Q, just press it again – and you also don’t get any feedback during holding.

Contrast with this extremely skeuomorphic CD burning molly guard in early iTunes, suggested by one of the readers:

And lastly, something I didn’t expect to ever see. Per this issue (page 14) of an alumni magazine of University of Illinois, here’s the actual Molly with her father:

This is not italics. This is not even oblique. This is a side effect of how those displays work. Instead of a whole rectangle of pixels being changed at once, the display is updated line by line, starting from the top one. As it’s moving towards the bottom, the internal horizontal position might have already advanced, the subsequent lines will be drawn slightly to the left, and it all leads to a slanted appearance. (This is in effect the same problem as rolling shutter in photography.)

The interesting thing is that it could’ve gone the other way. Twice. In English or German, we treat scrolling left to be natural, and we consider only one direction of italic slant appropriate. The first has to do with the direction of reading. I believe the second is, like many things in typography, customary; there’s nothing inherently better than right-leaning letters, except we’re used to them since those are the only ones we ever see.

But, the person putting it all together could’ve just as well done it the other way: scrolling to the right, or slanting to the left (by updating the display bottom to top – not as unusual as you might think!). Were those intentional choices, or was it a default? I’m not sure, but it points to the value of knowing this stuff, or creating a culture where this stuff is treasured. Often, more craft will require more work. Sometimes, however, you will get it for free – but only if you choose the right fork in the road.

While we’re here, how about a few other examples of delightful moments in typography where I did not expect them? These, I believe, will be all intentional. But whether you consider them craft, or even good, I don’t know.

Here are some surprising small caps:

Here’s a cute depiction of a train carriage, somewhat hampered by the limitations of a similar workhorse 5×7 pixel font display:

But here’s something even better. This icon of a stadium cleverly leaned into the same limitations. It’s so delightful. These are, I believe, four characters side by side:

Here, someone added nice decoration to fill out the space:

Here, someone removed all the line height to create a fascinating vertical ligature. This is Gorton and the letters are carved into the plastic, so this required some effort!

Speaking of obliques, this NOT is too thick, and slightly too large, but you have to appreciate someone actually slanting the text rather than underlining it, or decorating in a simpler way:

Even if you underline, you can go a little… well, below and beyond:

Or, here, with maybe the most impressive, three-dimensional underline I’ve ever seen:

This I spotted on an old typesetting machine, and I would like to believe this is an intentional easter egg:

This was on a computer keyboard. You don’t expect hyphenation in this context…

…and you definitely don’t expect an old-fashioned contraction:

I witnessed this Siemens locomotive depart yesterday and for a second I thought I was losing my mind. Then, I smiled so hard:

Turns out, the startup melody was intentional in this particular model. The power converters have to adapt the current from the overhead line to convert it to the three-phase motors of the locomotive, and that generates a rising tone. The engineers decided to change the logic to increment the tone in precise few steps resembling a musical scale, rather than allowing it to rise continuously.

I debated whether to include this on Unsung. I guess it is software, even if it’s attached to the hardest of hardware. And sure, it’s “just” delightful, but it is still kind of nice to see someone go extra, adding a human touch atop a technical process that had to happen anyway.

But then, it reminded me of something. No, not the poor CSIRAC trying (and similarly struggling) to become a musician. Rather, a “musical road” built in Lancaster, California, where the engineers messed up the execution, creating a truly unpleasant, atonal melody. David Simmons-Duffin wrote a fun essay in 2008 analyzing the “bug” thoroughly, including useful visuals, and even replicating the problem. Subsequently, Tom Scott visited the road and made a video about it ten years later.

It won’t surprise you that the cause of the bug was bad hand-off between designers and engineers, but there can be no software patch for grooves you cut in asphalt – and so at least as of last year, the embarrassingly sounding road was still there.

I think I prefer my out-of-tune musical scale performed by a train. Given it’s easy to find compilation videos of Siemens locomotives booting up, it seems I’m not alone.

I found this 9-minute video from Rex Krueger about screwdriver handle design really interesting in the context of my post about Photoshop’s dialogs.

Screwdriver handles evolved over the decades in response to user needs and usage patterns, with a few clever affordances: some for everyone, some for specific use cases that might not be obvious.

I think by now all the basic onscreen UI elements – input fields, pop-up menus, checkboxes, buttons, top menus, sliders, and so on – have similar richness, as do all the core input devices like a keyboard, a mouse, a trackpad, or a touch screen.

That doesn’t mean that everything is set in stone, that no changes are possible, and that stuff that fell out of favour can ever be taken away – after all, computer usage, input devices, and conventions are evolving much faster than screws at this point – but that one has to be aware of the history so that the changes are intentional, not accidental.

A few select comments from under the video that I found interesting:

The Craftsman handles are also different colors for Phillips and slotted screwdrivers.

The fluted handle was patented. So anyone else wanting to make a screwdriver would have to pay the patent holder. So they tried alternatives to make more money. That is the real reason until the patent expired. Plus if they invented a “better” way and held the patent, others would have to pay THEM.

The Swedish word for screwdriver is “skruvmejsel” with literally translates as “screw chisel.”

What Version History, a YouTube show from The Verge, does really well is revisiting older tech products from today’s perspective without allowing nostalgia to take over.

This episode about the Western Electric 500 – the canonical American landline rotary phone – is worth watching by all UX designers. There is no software here, as the phone is entirely electromechanical. But there are a whole lot of details to admire and be inspired by: the shape of the handset, the interface to change the volume, the iconic ring, the balanced and improved rotary dial, the behaviour of the cable, even the weight and balance of the whole device.

It’s not only that phone calls should all sound as good as they did in the 1950s – in my experience FaceTime Audio comes close, sometimes, but it’s so unreliable – it’s that you should try to play with a Western Electric 500 because you want your modern interface to feel like that.

The hosts – David Pierce and Nilay Patel, helped by Tim Wu, author of the excellent The Master Switch – also weave into it an entirely different angle, of how that phone fit into (and reflected) a specific period of American tech history, and how it related to AT&T’s then monopoly, including the phone jack and third-party access we just discussed re: John Deere. Even the discussion whether this is or isn’t a “hall of fame” object is good fodder for thought.

The episode – and the entire show – is also just a really enjoyable watch. If you like this ep, it pairs nicely with the one about the iPhone 4, another phone that transcended its origins through good industrial design, exactly sixty years later.

The 2021 revision of the Mini Cooper ramped up its Britishness by introducing Union Jack flag-inspired turn signals. They looked okay when stationary:

But when actually indicating an intention to turn, people started realizing what happens when you have two types of mapping fight each other:

On one hand, the left-turn indicator was on the customary left side. On the other, the light looked like an arrow – and the arrow was pointing to the right.

I don’t know how many people were actually confused by it, but it made for a few spicy pieces with “stupidest turn signal ever” and “most annoying thing” in their titles. The company’s official response was:

Mini has chosen the Union Jack lights to highlight Mini’s British heritage, and has been using them for a while. With regard to the turn indicator light pattern, there should be no trouble at all for a driver to understand, when seeing the full rear of the car, which direction is being indicated.

Mini has not heard any concerns from customers regarding the rear turn indicators, and has in fact received positive feedback about the taillight design.

It didn’t help that one of the worst cars this side of the Cybertruck did something similar in the 1950s:

Drama aside, I did agree with this commenter (emphasis mine):

It doesn’t cause massive confusion, but taillights should cause no confusion for anyone.

I can think of one modern version of a similar issue. If you use the iPad in landscape mode, the volume buttons seem to go “the wrong way”:

Is this anything? Probably not. I imagine it’s better to be consistent and allow motor memory to develop between all the iPad orientations, and throw in the iPhones, too. But if you only ever use your iPad in landscape, this might feel, perhaps, like “the stupidest volume controls ever.”

Oh, and the subsequent Mini revamp in 2024 solved the issue by making the turn signals less like arrows:

A fun 24-minute video from Technology Connections about designed sounds in real life: elevator dings, airplane chimes, railway crossing dings, and so on.

While I am sympathetic to the notion that sound pollution is a thing we need to be concerned with, the choice between silence and sound pollution is a false choice. There’s a lot of those happening these days, probably because we’re so stuck in binary thinking. But as airplanes show us, we can design sounds which aren’t obtrusive, but which are helpful. And when you get yourself out of binary thinking, you can do things like make your most obnoxious apps be silent while your important ones make themselves known, and in ways which are meaningful to you and pleasant to everyone else.

It is an interesting parallel to the post about syntax highlighting from a while back, and one of the posts about cartography design I shared recently; they all explore how you can create a richer space capable of conveying more information without overwhelming people, by being intentional about the design.

Cory Doctorow, in 2022, wrote an essay about how John Deere – a farm tractor manufacturer – restrict repairs by owners or third-parties:

Deere is one of many companies that practice “VIN-locking,” a practice that comes from the automotive industry (“VIN” stands for “vehicle identification number,” the unique serial number that every automotive manufacturer stamps onto the engine block and, these days, encodes in the car’s onboard computers).

VIN locks began in car-engines. Auto manufacturers started to put cheap microcontrollers into engine components and subcomponents. A mechanic could swap in a new part, but the engine wouldn’t recognize it — and the car wouldn’t drive — until an authorized technician entered an unlock code into a special tool connected to the car’s internal network.

Big Car sold this as a safety measure, to prevent unscrupulous mechanics from installing inferior refurbished or third-party parts in unsuspecting drivers’ cars. But the real goal was eliminating the independent car repair sector, and the third-party parts industry, allowing car manufacturers to monopolize the repair and parts revenues, charging whatever the traffic would bear (literally).

The same tactic was used by John Deere, forcing farmers to hack the tractors they purchased just so they could repair them.

In a decision that bolsters right-to-repair movement, John Deere and farmers reached a settlement that has the company pay $99 million to repay prior inflated repair costs, and requires it to share software required for maintenance and repair with farmers.

Just because I was curious and you might be also, here’s an example of a modern tractor interface:

The story reminded me of an ongoing battle in Poland where a train manufacturer Newag used VIN locking and coupled it with GPS hardcoding in an even more brazen attempt to prevent third-party repair: if a train spent too much time at a location of another train repair company, it’d simply stop running – not by some hardware fault, but by a simple if condition in code.

“This is quite a peculiar part of the story—when SPS was unable to start the trains and almost gave up on their servicing, someone from the workshop typed “polscy hakerzy” (“Polish hackers”) into Google,” the team from Dragon Sector, made up of Jakub Stępniewicz, Sergiusz Bazański, and Michał Kowalczyk, told me in an email. “Dragon Sector popped up and soon after we received an email asking for help.”

The (white-hat) hackers helped unbrick the train, but since European law is stricter on DRM, the case gets murkier. The article above is from 2023, and contains this quote:

Newag said that they will sue us, but we doubt they will - their defense line is really poor and they would have no chance defending it, they probably just want to sound scary in the media.

However, in 2025, the manufacturer proceed to sue the hacker group and the train repair company. As far as I can tell, the case is still in courts.

The three hackers explained their work in this 45-minute conference talk. It’s honestly not the most polished presentation, but it goes into a lot of engrossing details and if the intersection of hacking and trains hardware interests you, check it out! I had fun looking double checking this presented code by punching in the lat/long coordinates into Google Maps and verifying they’re exactly the locations of competitive repair shops:

I’ve loved Chris Staecker’s videos about calculating devices and machinery for years now, and I finally have a reason to link to one here. This is a fascinating 12-minute review of The Kensington Adding Machine from 1993:

It’s a fun (as always) watch, but as a UX designer, it’s also interesting to try to figure out what are the underpinnings of the things Staecker lists as strange from today’s perspective.

I believe that “CE/T” (clearing and totaling) coexisting on one key is a nod to professional accounting use of adding machines where you wouldn’t want to accidentally enter something into the record twice – so totaling also automatically resets the value and prevents you from making a mistake.

I also believe the strange [+=] rule is only because the keypad has to look forward at the same time it is looking back: it needs to serve as a universal computer keypad where [+] and [=] are separate key, but it also needs to pretend to be an adding machine where one key served both purposes.

(You can spot that the back of the box just allows you to swap the [+] key to be something else.)

Overall, the video is a fascinating tale of an “in-betweener” product that was stuck not just in the middle of a transition from physical devices into apps, but also at the intersection of calculators and adding machines (once two very different lines of products), themselves trying to learn from each other. It also serves as a great reminder that skeuomorphism is not just about visuals and sounds, but also behaviours: tearing off the tape, details of specific keys, nuances of rounding.

It’s not a thing of the past, either. In my post about determinism I linked to Apple’s recent travails with the deterministic Clear button (part one, two, and three). A few years ago, Apple also changed the built-in iPhone calculator from its “desktop calculator” roots to a more modern model where you get to input the entire equation before you see the result. But that change had bigger consequences; for example the [=] key could no longer repeat an addition. People complained, and Apple added it back – but the change feels incompatible with the new system and potentially confusing:

Elsewhere, the entire iPhone is an in-betweener, as the keypad coming from calculators is incompatible with the keypad coming from phones.

At this point it seems the calculator keypad will win, but transition has been over a century in the making. Staecker’s video is a good reminder how important, but also hard it is when you try to make these transitions happen faster.

In the previous post, I wrote:

I understand that the best way to compare two things visually is to switch between them promptly in situ; our visual system is really good at spotting even small changes when aided this way.

I thought it would be fun to talk about it briefly, because it gives me a chance to show you a really fun device:

This is a blink comparator, an apparatus built for astronomers to easily flip between two images of the night sky, taken at the exact same position some time apart.

It makes it easy to spot a moving asteroid, like in this set of two photos:

Blink comparator was used in 1930 to spot Pluto:

(Pluto is the blinking dot a bit to the top and to the right from to the center – that dot moves to the left in the other frame. The fact that it moved at all made it an object of interest, but it didn’t traverse the sky like an asteroid or space debris would.)

This is why the “spot 10 differences” puzzles are always shown side by side…

…otherwise everything would be much, much easier to spot:

Today, this kind of stuff doesn’t require complex devices, but it’s useful to know the principle.

If you’re comparing a reference design with its implementation, instead of measuring things on both sides it can help to align them in two windows, and then switch between them using ⌘Tab.

If you’re working on an interface for users to see differences between two images – don’t (just) show them side by side, but also allow your users to flip between them this way. And, resist the very natural urge to add any transitions that would seem to be nicer and friendlier; it is sharply switching between images that is the most effective.

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 notlike 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.