I linked to a bunch of speedrunning videos before, but this 43-minute video by hbomberguy from 2018 is a good introduction to the whole concept and why people care:

It’s really funny, romantic (maybe a bit too romantic), and it has a few great examples and explanations of the different kinds of speedruns that exist.

John Gruber on Daring Fireball:

Perhaps the worst UI crime in MacOS 26 Tahoe was the inexplicable decision to add inscrutable, distracting icons next to every item in the menu bar. You will recall Jim Nielsen writing about it, rightly describing it as exactly the sort of thing that Mac users look down upon in platforms like Google Docs and Windows. You will also recall Nikita “Tonsky” Prokopov writing about it, illustrating that the bad idea wasn’t even implemented well, with different Apple apps using entirely different icons for the same menu items. […]

Top third-party developers rightly rejected the design, adopting open source code from Brent Simmons to disable the default “icons in all standard menu items” behavior. […]

Wonderful news in MacOS 27 Golden Gate: the icons are gone. It’s like Tahoe’s menu item icons never happened.

Kudos to Nielsen and Prokopov for pushing on this and explaining the problem so well. This wasn’t about ugly icons. This was about improper use and misunderstanding of iconography.

(Also may I try to manifest something:) Looking forward to reading the oral history of macOS 26 Tahoe and Liquid Glass some time in the 2030s!

A reader sent me this screenshot from PowerPoint, with one of the menus looking the best it’s ever looked, and the other one showing to work with what we could charitably call “a UI hangover”:

It’s obviously bad craft and crossing over to the “embarrassing” territory, but I thought it’s an interesting question: what happened?

The main piece of the puzzle is that the first menu shows the name of the font in San Francisco, but the second asks to render the font name in itself, serving as a font preview.

Font previews are fascinating because they are the perfect showcase of how tricky fonts can be at scale.

Some time ago, I wrote an essay called Typography is impossible. TL; DR: It’s actually impossible to left align or center text. Ever. Not just because each font does whatever it wants – font size is a number that doesn’t really give you anything to hang a hat on, and the font can place itself in its box however it desires, too – and not just because fonts often lie (via bad metrics) about what they store inside, but also because aligning and centering are really in the eye of the license holder, and have more than one definition.

So, every time you align text to anything, in whatever way, it’s only an approximation. Most of the time that’s good enough. Here it is not.

I worked on font previews at Figma, and wanted to show you three screenshots of what we did.

This first one shows the default attempt: we ask the fonts to render themselves in the same size (16px), vertically centered in a box that’s always 28px tall… and they oblige on paper, but it really doesn’t feel like they are:

The second take shows what happens if you nudge the fonts up and down so they’re aligned to their baselines. This at least creates vertical rhythm; in effect, we need to make the fonts uneven to make them feel even.

And this is the final result, with extra adjustments:

What do we do in the final version? Too many small things to mention, but in essence:

• We literally measure the fonts (programmatically) by rendering them and looking at them, and make adjustments. We blow them up (but not too much) if they’re optically too small, or reduce them (but not too much) if they’re too big.
• We have a multiplier for scripty fonts and monospace fonts, where the traditional measurements are likely to be off.
• We even special-case specific fonts by name. That feels like bad practice, but fonts are so varied and all over the place, that I think it’s perfectly fine to make exceptions for particular individual fonts that are popular or otherwise very important to your users.

These adjustments are all in the same category: getting off math balance to get to optical balance.

Here, you can compare before (the naïve version) with after (the final version):

If it feels subtle, imagine it applied to a much wilder menagerie of very thin, very huge, or very strange fonts. (The go-to example? Open a Mac and try typing in Zapfino.)

I’m not showing this to brag about my work – okay, fine, to some extent I am, we’re all human – and I truly believe this could be so much better, still. There are icon fonts, color fonts, and non-Western fonts so rich in variety and tradition that this category itself is basically a fractal.

Mostly, I wanted to share this lesson: dealing with fonts is hard, and dealing with fonts as a system even more so. Whether it’s the printing press, paper, or Illustrator, it takes people years or even decades to fully learn the craft of setting type, and to believe their eyes instead of only relying on math. But here, what’s needed is manufactured craft: we have to teach the machine to trust its eyes (which it doesn’t have) over math (which it can’t escape).

Now if you’re wondering why font previews look bad in so many apps, I believe it’s because people working on those did not allocate enough time to deal with all that.

But I’ve used the word “embarrassing” as there’s one more thing that the original did poorly, and something the reader identified immediately. The makers of PowerPoint allowed the font to escape its containment:

This is another big lesson: fonts will ignore their bounds at every single opportunity. That infamous CSS IS AWESOME graphic? That’s CSS underestimating text. That naked URL or code snippet pushing the mobile site past the viewport and making it scroll? That’s the creators of the site not building up enough imagination of what fonts can do when they’re not watching. Zalgo text? A joke, but based in reality.

Fonts are so much more feral than you think. Are you ready for it?

Thank you to Giovanni Lanzani for sending in the original PowerPoint screenshots.

A nice little old-school moment from Flickr: When you accidentally type the name of the new photo album in the search field instead of the “new album name” field, Flickr just passes on that value to save you from having to retype it:

(I bet you witness a version of this all the time when dealing with “I forgot my password” flows which should pass on your login from one field to another, but they don’t.)

I’m not saying this dialog is beyond reproach; one way to reduce this problem would be to make those two treatments different enough visually to reduce the chance of confusion. But it doesn’t matter, because the truth is that often there is no dividing line between the problems and the symptoms, and both overlap to a scary degree.

As a designer, I think it’s sometimes good to simply face this truth: no matter what I do, the user might type something into a wrong field. Anything I can do to help then?

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.

John Gruber at Daring Fireball talks about a problem in SwiftUI-based macOS and iOS apps where undo is completely broken during text editing:

Basic stuff that’s worked reliably for decades — some things that heretofore had worked forever — are dangerously broken. If you’re running MacOS 26 Tahoe, open Journal and make a new dummy entry. Type something like “The quick brown fox.” Then double-click on the word “brown” and delete it. Now invoke Undo.

What you expect is for the word “brown” to reappear. What happens is ... the whole sentence disappears. Gone. Invoke Redo and you only get back to “The quick fox.” The word “brown” is just gone forever. It’s nowhere in the Undo stack. That’s just profoundly fucked up.

I couldn’t believe it, but I reproduced it myself just now on my phone (my backup Tahoe-running Mac is in a closet not responding to pings, I am now assuming out of embarrassment):

Gruber adds:

Apple’s developer message used to be that it was not just easy to develop apps for their platforms, but that it was easy to develop good idiomatically native apps. You got the correct complex behavior — for things like Undo/​Redo — out of the box. That’s still true for AppKit and UIKit, but it’s never been true for SwiftUI, and SwiftUI is now seven years old. That’s too long for any excuses to hold water.

I don’t want to automatically assume that this problem has existed for seven years (vs. being a more recent deterioration), and I don’t know exactly which native apps use SwiftUI, but either way, this reflects very poorly on Apple.

Software engineering typically has some categories of bugs and failures that result in immediate action – a night shift, a war room, “sevs,” and so on. Those are, in my experience, things like:

• the app crashes,
• the site doesn’t load,
• there is data loss.

Depending on what you work on, this list will also likely include security problems, regulatory considerations, privacy-leaking bugs, and so on. In a more mature organization, these are all well documented, but even in early startups there is some shared understanding that some bugs are bigger than life and they take immense priority over pretty much anything else.

At any company, a version of this list needs to exist for front-end and user-experience problems, and undo should be on top of that list. If you break undo, you drop what you’re doing to fix it.

Nick Heer’s analysis of Apple’s Pages interface over time is a nice counterpart to the recent post about Sinofsky doing the same for the early years of Microsoft Office. Here is the key comparison, 2011–2025:

I’ll let you read the whole excellent analysis and Heer poking at the notion of “content over chrome” which feels dogmatically attractive, but needs deeper thinking which usually doesn’t follow.

The interesting thing to me about that last screenshot above is that the team didn’t want a toolbar separated from content – and yet, they walked themselves into recreating a de facto toolbar anyway, just uglier and with more problems. (Just like designers who use all-white for complex surfaces, and arrive at visual hierarchy challenges that now require more work.)

We’re a few hours away from WWDC. I don’t imagine we will see any direct response to the criticism of Liquid Glass as Apple doesn’t work that way, but it will be interesting to spot any indirect signs of reactions or course corrections.

A nice blog post by Nathan Manceaux-Panot on Pending Design about the subtle design of the tabs underneath the search results in the programming editor Nova:

Through buttons right below its text field, the bar also lets you filter results: only show files, only show symbols, or only show symbols in current tabs. Here’s the thing, though: each one of these buttons has four distinct purposes. They’re not just for clicking.

The tabs are clickable as they normally are, but they’re also a treasure map (to tell you something is possible), a cheat sheet (to remind you how to do it again), and an onramp for faster keyboard navigation.

I’d add two more things to the celebration:

• I myself often forget onboarding is not just about the first run, but also about reinforcement. Here, this UI does a lot of reinforcing over time, helping you build the habit. Pressing the key highlights the tab. Clicking on the tab adds a key as if you pressed it, and so does using an advanced shortcut (e.g. ⌃⌘O instead of ⇧⌘O). Even slash as a symbol comes from path names, so you might naturally associate it with files.

• The search pop-up always has a nice contrasty appearance: dark when the background is light, or vice versa. Many modern interfaces go for white background for every UI element and surface. This seems like solely an aesthetic choice, but has more consequences when it comes to visibility of things, and even hierarchy. I am personally always excited when I see a duochrome app these days, because it feels like the team knows what they’re doing and isn’t just chasing visual trends. (Below is an example from Bear.)

★★★★☆ (as a book)
★★★☆☆ (for the purposes of this blog)

There are as many books about Steve Jobs as there were Quadra models, but they focus mostly on two phases:

• 1955–1985 – Steve Jobs befriending Wozniak, the early days of Apple, Lisa, and the Mac
• 1997–2011 – Steve Jobs’s “second act” at Apple, and the creation of the iMac, iPod, iPhone, and so on

Steve Jobs in Exile by Geoffrey Cain is a just-released, rare volume that focuses on the “in-between years” – starting with Steve Jobs founding NeXT and Pixar after his Apple ouster, and ending with him coming back to Apple under the absolutely strangest of circumstances. It’s a doubly interesting phase, both because we see Jobs maturing as a leader and actually learning from his many mistakes, and because the early technical NeXT decisions eventually became underpinnings for modern macOS and iOS.

I do not see this as a book of new immense insight, technical depth, or design details, but that doesn’t mean it doesn’t go beyond surface level. What I appreciated most was Cain not shying away from pointing at some of Steve Jobs’s mistakes: hiring wrong people he happened to like, almost driving the company to the ground through obstinance, inability to focus on things he considered uninteresting, and a profound dose of duplicity coming into the NeXT/​Apple merger.

Other things that stood out: focus on people around Jobs, spotlight on Jobs’s disappointing moral flexibility around working with government (or befriending Larry Ellison, for that matter), and a really fun pizza ordering story that serves as a prelude to the Starbucks call during the iPhone 2007 keynote.

Some learnings:

• Craft and taste alone are not enough; you can spend your talents and energy on things that don’t “matter” given some definition of the word. That could be okay if that’s a choice you make – “impact” is ill-defined and often overrated, anyway – but you need to approach it clear-eyed, which Jobs didn’t initially know how to do.
• Confidence, like everything, needs to be practiced, and focused, and influenced back by feedback and reactions. (Witness the negotiating acumen of a certain Jean-Louis Gassée!)
• It’s really hard to create a culture of hard and honest and deep conversations that’s also not a culture of abuse and toxicity.

The one thing I didn’t like about the book was that the few photos inside are only perfunctory; there’s a lot of chatter about a beautiful, symbolic NeXT lobby staircase, top-of-the-landline phones, and expensive chairs, but we never get to see them. Many of the photos are by Doug Menuez – which you can also see online – but the problem is that those photos are generally not that interesting.

That aside, it’s still a breezy and entertaining read that filled in some gaps and provoked new thoughts.

Welcome to another Super Mario Sunday!

This is an 11-minute video from gruz talking about the fascinating world of South Korean bootleg Marios, such as Super Boy, Super Bros World, and Super Bio Man – existing solely because of Korea’s subpar copyright law of that era:

In short: The code was copyrighted, but the IP was not, so many companies rebuilt Mario for the dominant game console of the region, in the process stripping it of all of the original game’s actual craft – with “levels feeling assembled rather than built” and “getting the [visuals] right and missing almost everything underneath” – and as such become interesting as a reflection of the details that actually made Mario great.

However, as the time moves on, some of the bootleg games actually get better and better, and come into their own. It’s interesting to compare this to Nintendo’s own “clone” I mentioned before.

What I wouldn’t give for some oral history of what looks like an absolutely fascinating time and place for software.

A nice moment in the iOS emoji keyboard – after selecting an emoji from the grid, its name shows up for a second:

I have small reservations here, as reusing a placeholder like this trips up my “this is cheap” alarm. But otherwise I like that this – just like keyboard shortcuts in menus or tooltips – ambiently teaches you the alternative representation of the emoji that you can use later to get to it faster.

(Another way of looking at it: This is a tooltip in a place where tooltips cannot exist.)

Two nice follow-ups to topics we covered before.

In February, Nobert Heger did some analysis of precisely which pixels in Tahoe are intercepted by mouse when trying to resize a window. In April, Steve Ruiz, author of tldraw, did this more extensively for all the drawing apps like Canva, Figma, Illustrator, and so on:

When a user has one or more shapes selected, we display an interactive overlay that allows the user to transform their selection: a drag inside the box will translate the selection; a drag on the edges will resize along that axis; a drag from the corner will resize along both axes; and a drag from further out on the corners will rotate the selection.

Like many features in tldraw, my design here was meant to follow the conventions of design tools. This meant a broad survey of other applications, both new and old, reconciling differences between them, and picking a design that I felt best served the user while remaining conventional.

Remember the “if you put the Apple icon in reverse” joke from January? Last month, Jim Nielsen on his blog pulled on that thread and showed a few more examples:

Some 3rd-party apps continue to fight a good fight, even as Apple’s definition of what an icon should be — or what’s even possible — shrinks all around them.

One finding from this blog post for me was that things changed. In Big Sur, the squircle form factor was encouraged, but not enforced. Well, it is enforced now, when even shapes very similar to the squircle are now inside “the gray box of hell”:

These gray boxes are not some pedestal for icons. They’re the actual icons.

Anyway, I always appreciate efforts of people methodically documenting things so we can all learn and notice patterns and/or continue the work from the best possible starting point.

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:

In 2021 and 2022, product manager Steven Sinofsky wrote a…

…first-person account of what I saw at the PC revolution from the perspective of joining Microsoft as a newly hired software design engineer fresh from graduate school working on developer tools, through my time as a program manager and ultimately leading Office, and then moving to Windows, and everything in between.

Sinofsky called the series Hardcore Software: Inside the Rise and Fall of the PC Revolution. It covers 1989–2012 and somewhere inside over 100 chapters, there is a fascinating six parter about the “ribbon” redesign of Office 2007.

• What is Software Bloat, Really?
• A Tour of “Ye Olde Museum Of Office Past”
• Competing Designs, Better Design
• Progress From Vision to Beta
• First Feedback and a Surprise
• Defying Conventional Wisdom to Finish Office

The first part covers the challenge of the team in 2007, taking stock of Office after almost 25 years of its evolution. (Number of toolbars in 1983: one. Number of toolbars in 2003: 31.) The second part shows great screenshots of all the Office versions from 1.0 until then, and the remaining four cover the Ribbon redesign process.

Regardless of how you feel about Microsoft Office today, and whether you consider the Ribbon interface a success, it’s a perfect weekend read as it covers universal challenges of software complexity and change management.

It’s such a potent series I’m sure we’ll come back to it. It covers a lot, including – in the first part – wrestling with a definition of bloat or complexity, which in the context of Office was less about the number of functions available, and more about mastery:

[…] In practice, bloat comes from the fact […] that Office does so many things that customers just assume the product can do whatever they need it to do. Despite that fact, customers have no idea how to make the product do what they need. This feeling of helplessness that leads to frustration. […]

Bloat is owning a product that you cannot master.

This below is a great observation about the perils of an idea of a “simple mode,” which Sinofsky argues is always a leaky abstraction:

We tried reducing bloat by hiding features […], but that only added to the mystery of the product. Mac, Windows, and Office all went through periods of “simple means fewer” and tried mechanisms such as short menus, simple mode, or adaptive toolbars. But that frustrated or confused people. No one really wanted to use a simple mode and there was always one command missing that was needed, so simple mode became a complicated way to do that one thing that made someone’s work unique.

It was great to see this argument for a broad definition of a bug, as it slides exactly into my post from a while back:

Ages ago in ancient Microsoft history there was a debate on the original apps team about what it means for something to be a bug. Is it a crash? Is it data loss? Is it a typo in an error message and so on? Out of that was created a notion of bug severity, a measure for how serious a bug might be from losing all data all the way to simple cosmetic issues. However, when it came to talking about bugs with product support or ultimately customers the definition of a bug was very simple “a bug is any time the software does not do what a customer expects”. This definition created a discipline of documenting everything reported about the product and always making sure every issue was looked at, even if a code change did not result. The key lesson was how helpful an expansive definition was.

There are also observations and research about how users “debug” the product to make it achieve something they know is possible, but they don’t know how:

We called the futzing document debugging, and it created a frustration that the product was powerful yet overwhelming. People believed a specific result was achievable but getting from point A to B seemed impossible or unlearnable.

And some about the challenges of figuring out what features people use:

[…] Most people didn’t know or care what buttons they clicked on or menus they chose so long as it was working for them—and that meant when asked, “Did you use X?” most people couldn’t recall. To a skeptical press or IT manager (and they all were) that meant unused features.

I should stop quoting and let you read in peace. But, check this out. Lisa wasn’t the only one having linguistic fun:

Early keyboard shortcuts were simple, like using Ins(ert) key to copy text from the scrap (clipboard).

Scrap!?

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:

Interactive explainers are one of my favourite things about the web: people passionate about things introduce them to others, for free, with care, and often using some interesting interactive or educational approaches in the process.

I picked a few I particularly liked for this post. These aren’t just explaining things useful to know as a designer, but also themselves contain inspiring/​unique interactive moments worth knowing about:

1.
Curves and Surfaces, Bartosz Ciechanowski

• Every example has draggable points, but it also pops up an undo button once you start messing around, so you can feel safe experimenting:

• Specific ideas and definitions are color coded between text and the interactive pieces:

• For complex three-dimensional shapes, you can simply rotate them around to orient yourself better:

• I liked this trick of claiming something is impossible, but leaving a door open to try it anyway – I bet it will get some people more engaged, in the “but I’m sure I can lick my elbow” sense:

2.
ASCII Characters Are Not Pixels, Alex Harri

• I think the traditional “drag a divider to swap between two representations” interaction is actually kind of bad, but this essay subverts it by allowing you to toggle between representation A, representation B, or both side by side:

• A button to copy code to clipboard is always appreciated:

• I don’t know, I liked these minimalistic sliders:

3.
Tab Roving, Niklas Gadermann

• It’s hard to know what to do with complex interactivity, for example a specific sequence of keystrokes… let alone the fact that mobile phones don’t have easily accessible arrow or Tab keys. Here, a brilliant solution: not just on-screen soft keys, but also automatic playback!

Also, kudos to all three creators for their explainers working equally well on phones as they do on desktop computers.

The otherwise excellent note-taking app Bear has an interesting bug that’s worth talking about while it’s still here.

When you’re around to-do items, you can press ⌘. (period) to toggle any task complete or incomplete. It’s actually a really fun shortcut in practice:

But when you have a larger selection with a mixed state (some checkmarks are on, others off), this is what happens:

This feels like an obvious thing to implement, and this is also where the code itself wants to go when left alone.

But this is not great. The rule is: When you have a mixed state, changing it should collapse (or: normalize) the entire selection to one state or the other, rather than perform individual inversion. Try ⌘B in your text editor on partially bolded text, and you can see that collapse in action:

It feels strange to recommend that, particularly as it seems like it loses data. So, what gives?

The first argument is “do not make the user jump through hoops” or maybe “respect a large selection.” If, as a user, I want to actually make sure all my tasks are done, the shortcut not being idempotent means that I now have to go through tasks one by one, and that’s a lot of work – especially since we’re talking about text selection, which is famously unpleasant.

The second reason is that even the UI layer has an opinion here. In the above bolding example, Pages collapsing the selection to bold when you press the B toggle, makes the toggle UI behave exactly as it normally would with a simple selection:

Elsewhere, in Figma, typing a number on top of a “mixed” state changes all the properties of relevant objects to that number:

Imagine how awful it would feel mechanically in both the above examples if your action would still leave the text in the “mixed” state. It would simply appear like the UI broke, since the change didn’t fully “stick” – kind of like those tiny hated moments when you close the door, but it doesn’t latch on and reopens on its own, or when you engage the turn signal stalk, but it refuses to stay put and snaps right back.

There is also one last reason. It’s the simplest one that I sometimes have to remind myself to put in my head before I jump too deep into the mechanics, or details, or technical nuances. Let’s say the toggles invert individually on a large selection. Who would ever benefit from it behaving this way?

I hate lorem ipsum with passion, but guess what? There’s more intentionality in it than I assumed, and even easter eggs, as this fun 25-minute mini documentary from Emily Zhang/​Rabbit Hole shows:

You can tell that this was not the work of an amateur. The garbled text is done with a lot of care and knowledge. You can see a lot of rational decisions about why it looks the way it does in there. They are making very careful additions, such as adding letters… the “-and”s and the “-ng”s… The “y” got stuck in because that’s an English letter. […] I think the fact that it is garbled Latin text, and that it has those other letters in a fairly Latin-based alphabet amount of frequency, speaks to that it was done very, very carefully.

Just a fun watch all around.

In last week’s post, I made an off-hand comment about Vercel’s Geist Pixel announcement, and I thought it might be interesting to turn this into more of a full-fledged critique.

I don’t think it’s a good announcement, but its flaws are pretty universal, so I want to put words to these flaws. This will extend to a lot of other writing about design, not even necessary even just about typography.

Here’s my advice that I believe would make announcements like this better:

• Write like a human being would. This is famously hard, and takes practice. Here, we see stuff like “unapologetically digital,” “a functional tool within a broader typographical system,” “the result feels both nostalgic and contemporary,” and “constraints weren’t a limitation, they were the design tool.” No one talks like this. I think people believe font releases have to use these kinds of words and phrases, as a way to bring legitimacy to the project. I do not subscribe to that way of thinking. I think it leads to writing that’s optimized only for admiration, which is not as much fun for anyone.
• Show a specific example of a problem you solved. This page hints at some things – “They don’t scale properly across viewports, their metrics conflict with existing typography, or they’re purely decorative.” – but that feels altogether too vague to be useful or even interesting. These are actually fascinating and hard challenges, yet I know as much at the bottom of the page as I did at the top.
• Show details you are proud of. Zoom in literally or figuratively. “Each glyph was manually refined to avoid visual noise, uneven weight distribution, and awkward diagonals.” I would love to see a few examples.
• Show work in progress! Show stuff you discarded. This will be hard, but why not? It’s good practice and I believe this, more than anything else, will have people appreciate what you did. Plus, everybody loves a blooper reel.
• Related: talk about struggle. But don’t just motion in the direction of challenges, or performatively announce that this was the hardest project of your life. Actually talk about something that was hard, and why. Be vulnerable. Be honest. People didn’t care that Rocky lost in the first movie, because people cared about Rocky.
• Talk about your inspiration or history. What we all do here is part of something much bigger. Why a pixel font to begin with? Why is this interesting to you? Is that because Vercel is filled with nerds, or because you got bored with bold and italic, or because it just seems visually interesting in a new way?
• Let me type! Immediately and on every relevant page. I don’t think any modern font announcement/​tester can exist without this. This is the easiest way to getting to know the font and explore specific things that matter to you. (To do this here, you have to go to the font page, switch to Geist Pixel at the top, and then scroll all the way to the bottom. This feels entirely too far away.)
• Show, don’t tell, generally. The Geist Pixel announcement feels rife for an avalanche of “show,” but has so little. I mentioned above wishing to see examples of manual refinements. There is a visual for “seamless mixing,” but it’s really a marketing photo, not a real-use example – it visualizes what, but you want to visualize what and why at the same time. I would love to see the spread of variants, specific examples of how the font is not “breaking in production” and “scaling properly across viewports.” I don’t know what is a “semi-mono approach” and I would like to learn.
• Motion is okay, but it has zero nutritional value. If you have limited resources, don’t spend it on motion. Anything interactive is better. (But again, the best interactive thing is letting you type.)
• The “Already shaping what’s next” is a narratively unsatisfying section, as it promises stuff that you cannot see yet. Either show those, or skip the tease altogether.

I know the elephant in the room here is “how big companies do things.” A lot of redesign announcements and font unveils exist chiefly to make the execs who championed them happy, and perhaps as fodder for future promotion – I bet the whole “Already shaping what’s next” section isn’t really written for external audience – and they get chewed by the big PR machine that often files away whatever personality and quirkiness might have been there. Your job is to fight that machine! But I acknowledge that it might be hard.

However, I’ve also seen all this seeping into personal font announcements, which is unfortunate. (I don’t want to link to specific examples, since that’d be punching down.)

Also, this is not just about the joy of reading or some general notion of “craft” – although they are important, too. This is also purely informational. I feel I haven’t learned enough from the Geist Pixel announcement for the amount of time I spent with it. I don’t understand “multiple variants for different densities and use cases” or “semi-mono approach” or what stylistic sets are included. (My general goal is to write in a way that people can learn something new from any design announcement, even if they don’t have any prior context, and if they never actually use the font.)

It‘s a shame, because the work itself seems thoughtful and excellent, deserves a better intro, and could help others interested in typography as a jumping off point, particularly because this feels like a typeface off the beaten path.

Just to round up this post, some recent counterexamples:

• Fran Sans announcement post by Emily Sneddon (complements the font page) – personal, distinctive, talks about the process, shows interesting artifacts.
• I feel that every small essay from David Jonathan Ross’s Font Of The Month Club teaches me something new – pick a font you like on that page, then click Notes next to it.
• Departure Mono font page by Helena Zhang doesn’t use a lot of words, but still says a lot.
• Shantell Sans process post by Shantell Martin (complements the font page) – already talked about it before.

A nice moment in Google Maps – if you are travelling by public transit, an indicator shows not just the current stop on the list in real time, but also exactly where you are in between stops:

It’s not just something traditionally delightful, a cute big icon moving smoothly. I also think it’s very helpful. Travelling in a new place can be stressful and station names look similar; it’s nice to orient yourself without having to go back to the map, and if the indicator only always pointed to a station, it would introduce off-by-one errors (“was it the last station, or is it the next one”)?

Plus, I think any design features that help your brain transition between abstract (list) and physical (map) views are very welcome.

My suggestion would be to consider making it pulsating and/or blue to tie it better together with the current GPS position, which has had the same visual signature since 2007.

I know I just mentioned the Google Search app, but I’m also in the process of disentangling myself from Google and Gmail after last week’s Google I/O revelations.

On that note, this is an interesting, meandering essay by Ernie Smith at Tedium, reflecting on the enshittification of Google and the two-year anniversary of &udm=14, a simple site that removes AI from Google’s search results:

I spent two hours of my life building a thing. Google has probably spent thousands, if not millions, of collective employee hours building all their AI innovations. And for a surprisingly large number of people, the two-hour workaround I built wins out. There’s a lesson in that.

Somewhere in the middle, the essay transitions into talking about the value of good tools and single-serving websites:

Our world needs more, smaller tools that speak the same language, where everyone makes a little money, but nobody dominates the industry. In the 1980s, the software industry was kind of like this. Oh, sure, Microsoft and Apple were still out front, sucking up all the oxygen. But there were lots of little companies, selling software on disks. The bigger ones put them in boxes in stores. The smaller ones realized that they could just ship software through the mail and let the software spread naturally among user communities.

Shareware didn’t really survive the internet era—but, at least for a while, its spirit did. More recently, that spirit has taken a backseat to the larger companies that realize, if they’re big enough, they can shape how we interact with our world.

In 1991, if you wanted to start a software company, you had to hope that your product was good enough that word of mouth and a P.O. Box could push it around. That’s exactly what happened when Tim Sweeney released ZZT. It became the starting point for Epic Games, the kind of company that today is big enough that, thanks to its Unreal Engine and the success of Fortnite, it can dictate terms to much of the gaming industry.

If you ask me, I want a world where more software is like ZZT than it is like Fortnite, because more people have a chance to succeed in the former environment.

Previously in this general category, we covered Keyhole and (Gmail) Simplify. If you have a favourite small tool or a simple tool-like website, I’d love to hear from you!

Do you know those “Are you still here” screens? In some cases – like banking – they are ostensibly there to improve security. In public transit ticket or similar machines, on the other hand, they exist just so the machine can easily reset itself ahead of a future customer.

Resetting to default state happens on your phone, too. I’ve been thinking about it this past week and found a few examples.

The Google Search app comes back how you left it, except if you abandon it for longer than 45 minutes. If that‘s the case, it returns to a pristine, deterministic homepage. (You can always come back to the previous session, though.)

When you pause a podcast or music, at least in my setup, it will be on the home screen for 5 subsequent minutes – you can then resume it by simply tapping on your AirPods. But leave it dormant for longer than that, and the home screen forgets about it and resuming is impossible:

My favourite: if you swipe through the apps back and forth on the iPhone in a touch UI equivalent of command-tabbing, there needs to be a specific moment where the app you switch to becomes the “current” app. On desktop, it’s easy – you can reset the state at the next invocation of ⌘⇥. But there is no such obvious moment on mobile.

When there is no obvious moment, timeout can be a great answer. And so it is here, and it seems to be set at about 5–6 seconds:

I understand the Google Search and the app switching examples. But I am not sure I know why a podcast resets so soon. A challenge when talking about this without seeing the code – as it is with many things on Unsung – is that I don’t know if this is carelessness, a technical limitation, a design consideration I’m unaware of, or just something that’s intentional, but I happen to disagree with. Even testing this has been hard if the delays are longer than seconds.

The extra challenge for Google Search, as it is for many other apps, is that they also reset when iOS itself purges it to make room for other apps. This isn’t great, and can be avoided if you care; we talked before about Bear and how it remembers its precise state even after the system evicts it from its memory.

Whether you want your app to remember you forever, or whether you want some deliberate forgetfulness, it could be important to take ownership of that. My go-to example of a miss in this category is Google Maps, which completely throws away its current trip-in-progress status whenever the iOS kicks it to the metaphorical curb – and returning to that status later again as a user is a really complicated sequence of steps including rewinding back the time, on top of travel already being stressful.

By the way, I can think of fewer examples on the desktop, but that makes sense given desktop apps are less tactical, and given that ⌘Q exists.

But Spotlight does freshen itself up after about 7 or 8 minutes…

…and Raycast actually offers an option to set its short-term memory from between 0 seconds and three minutes, with the default being 90 seconds:

I absolutely love Jimmy Maher’s body of work. He’s been writing about older games and software in general since 2011; it’s always solid, always an enjoyable read, and always providing new perspectives even on stuff I thought I knew well. (Maher also goes by The Digital Antiquarian.)

I linked to his work once before, and today I wanted to share a recent essay about the disaster that was the 1999’s game Ultima IX.

I have never played any Ultima games, but this was a gripping read.

[…] Richard Garriott, the motivating force behind Ultima from first to last, has done his level best to write the aforementioned last out of history entirely. Ultima IX is literally never mentioned at all in his autobiography.

But, much though I may be tempted to, I can’t similarly sweep under the rug the eminently unsatisfactory denouement to the Ultima series. I have to tell you how this unfortunate last gasp fits into the broader picture of the series’s life and times, and do what I can to explain to you how it turned out so darn awful.

In some sense software projects always fail for one of the few obvious reasons, and it’s just details that change. Here, the details are fascinating. The Ultima series started in the very early 1980s as a series of small games made by one person, and ended ignominiously as an almost-AAA title rushed to market that no longer wanted it:

They met the deadline — what other choice did they have? — but the playable game eluded them.

It’s not just the deadline. There’s also a studio past its prime, a fascinating but deeply flawed leader, the market forces and trends, and perhaps even some enshittification long before the word’s invention.

It is also a story of the first two decades of the videogame industry itself. It happened so long ago that it almost feels like a fairytale itself, although one with a sad ending.

Maher also lists some learnings that are universal enough to apply to a lot of other projects:

• No game can be all things to all people.
• Development teams need a clear leader with a clear vision.
• Checking off a list of bullet points sent down from marketing does not a good game make.
• When the design goals do change radically, it’s often better to throw everything out and start over from scratch than to keep retro-fitting bits and pieces onto the Frankenstein’s monster.
• It’s better to release a good game late than a bad game on time.

And, in case you want more, here are handy links to all of Maher’s Ultima essays: I (3 parts!), II (3 parts), III, IV, Multima, V, VI, Worlds, Underworld (2 parts), VII, and VIII. I haven’t personally read them in order, and I’m better for it.

The biggest smallest GUI design schism between Apple’s platforms and Windows isn’t the black vs. white cursor or where to put the menu bar. It’s the presentation of keyboard shortcuts.

On a Mac, the shortcuts are iconographic. Command is ⌘. Option is ⌥. Shift is ⇧. Control is ⌃. Fn is 🌐. There are also icons for all the other non-printing keys, from the relatively well-known Tab (⇥), through the perennially confusable End and PgDn (⤓ and ⇟), to the absolutely cryptic Esc (⎋).

On Windows, the keyboard legends are mostly text. PC lost the icon battle in the early 1980s – IBM had them on their 1970s computers, worldwide, but apparently American users of the early IBM PC hated them – and the names are spelled out (Shift and Enter and Home), or close to it (Ctrl, Esc, PgDn, Prt Sc).

Why did Apple go this way? My speculation is the revered Braun and generally hi-fi hardware: a lot of stuff sold in Europe defaults to iconography in part because that makes exporting easier. Icons are also more compact – putting ⇧⌘C in a menu or a tooltip takes up a lot less space than Shift+Ctrl+C – and more beautiful when done well. Here’s Figma’s right click menu on Mac and Windows:

But there are also challenges, as icons are more cryptic and confusing. “Command” tells you something about itself out of the box, but “⌘” is completely abstract. (Arguably, only arrow keys and symbols like ⇥ and ↵ explain themselves visually.) The attendant issue is that icons are hard to talk about if you don’t know their names, hence tons of jargon like “propeller,” “splat,” or “beanie” for ⌘, for example.

It’s a hard situation. Here is one of Mac’s own menus being thoroughly inconsistent, and an example of CleanShot using both the icon and the label to be sure:

“Why not both” seems to be the best way in places you can afford it. Apple started doing that on the keyboards too, but it took them decades to get there for modifier keys alone. Even on the 2026 computers, many other keys like Esc and Tab are still single-legended:

With all that in mind, I want to show you what I saw the other day in Google Docs, on my Mac:

This is one of those cryptic things that I would love to understand the thinking behind. Because, on the surface, this breaks so many rules:

• A strange hybrid of Mac and Windows styling: some modifier keys are spelled out, and the others are iconographic. (It’s very strange to see ⌘ conjoined with others using a plus!)
• Complex and generally uncommon dual key shortcuts – to collapse the sidebar, you really need to press ⌃⌘A and then press ⌃⌘H, in sequence.
• Three-modifier-shortcuts are in general really unpleasant and Google Docs does not seem complicated enough to warrant them.
• (You can’t see that, but they’re also unreliable! ⌃⌘A ⌃⌘H doesn’t always work and seems to depend on where the focus is.)

There is also a visual argument that cannot be ignored. We’ve been there once before; if in your menu keyboard shortcuts start overwhelming the commands themselves, you are probably doing something wrong.

The only explanation for this I can think of off the top of my head is this: these were invented somewhere else (Word?) and inherited by Docs to respect motor memory of the users transition from the older app. That still doesn’t cover the presentation, plus there is a way for Docs to redesign the shortcuts to be better for people who are starting anew.

Ultimately, I think all of this also breaks a cardinal rule: it makes keyboard operation feel more scary and intimidating than it needs to be. Shortcuts are scary enough on their own, and they don’t need any help in this area.

Do you remember the video I once shared about making a song in Strudel?

I recently stumbled upon this 20-minute YouTube video by iSongs of someone recreating Eminem’s “Lose Yourself” in GarageBand on their iPhone:

Like the previous video, I believe this is so tight as it was previously rehearsed/​prepared, which makes for an interesting watch if you even just check out a fragment of the video.

I can’t speak for the verisimilitude/​quality of the composition, but it was fascinating to witness because The. UI. Just. Kept. Coming. I had no idea Garage Band is so fully-featured on the iPhone, and that there is so much going on!

Maybe my fascination is this: it’s amazing that “power users” come in various shapes and forms. Would I recommend using the iPhone to do this? Not really. Is it cool that this is possible, for people who might not have access to other platforms? Yeah.

(The channel has a lot more different songs if this one is not to your liking.)

I generally avoid think pieces about AI because a) a lot of them are boring, and b) they rarely match the pragmatic posture of this blog.

But this essay on a new No One’s Happy blog was really interesting to read, and feels different in a few ways.

First, it examines what happens as AI slop spreads in the context that is less discussed – in a workplace:

This is a new form of slop, and it is more expensive than the public kind, because the people producing it are being paid a salary to do so. […]

The cost of producing a document has fallen to nearly zero; the cost of reading one has not, and is in fact rising, because the reader must now sift the synthetic context for whatever the document was originally about.

A lot in the essay feels pertinent to Unsung as real craft is not feelings or fluffiness. Real craft is deep expertise:

Generative AI can produce work that looks expert without being expert, and the failure arrives in two shapes. The first is when novices in a field are able to produce work that resembles what their seniors produce, faster or more advanced than their judgment. The second is when people generate artifacts in disciplines they were never trained in. The two failures look similar from a distance and are not the same. Research has mostly measured the first. The second is what it is missing, and in my experience it is the riskier of the two.

The term for this new challenge is, apparently, “output-competence decoupling.”

Other parts of the essay come back to a topic – toxic velocity – we covered before:

The current generation of agentic systems is built around the premise that the human is the bottleneck — that the loop runs faster and cleaner without the awkward delay of someone reading what is about to happen and deciding whether it should. This is, in a great many cases, exactly backwards. The human in the loop is not a vestige of an earlier era; the human is the only part of the loop with skin in the game. Removing the H from HITL [Human In The Loop – eds. note] is not an efficiency. It is the abandonment of the only mechanism the system has for catching itself.

And one last thing that differentiates this essay from many others is the last “what to do about it” section.

The Ringer journalist Brian Phillips asked on Bluesky:

I’m working on a column about the tech annoyances that drive us crazy, and I want it to be as universal as possible, so tell me yours!

E.g. scanning a QR code to read a menu, never receiving the one-time passcode they supposedly texted you, “verify you’re human” by IDing tiny motorcycles, etc.

There are already many responses. I am drafting behind Phillips before he even writes his essay, because I like occasionally checking in with people this way. Not just for commiserating; perhaps scanning the answers will also give you some inspiration, or validation, or quotes for something you can push to make better, wherever you are.

Some patterns I noticed:

• A lot of logging in woes: password requirements, bouncing people from apps to web to log in, login flows forgetting context, “I trusted this device” settings you cannot trust.
• “Local news websites that crash under the weight of all their pop-up ads and auto-play videos.” This post had a great take:

The way super sketchy bootleg websites used to look (written in questionable English, 2/3 of the window overtaken by ads, constant popups and redirects, incorrect information more often than not) is just how all websites are now.

• Hatred of QR codes, or perhaps what they represent: needing to install an app, removing people out of the equation, introducing phones where they weren’t needed before.
• Surprisingly little AI. Is that because of the audience or the way the question was phrased?

Also, this little beauty:

My toaster says to unplug when not in use. It also has a digital clock that resets when I unplug it.

Actors are overwhelmingly diurnal, overtime is expensive, and film emulsion struggles with limited light, so since the dawn of time Hollywood has been using a technique called “day for night” – shooting during daylight, and then darkening and blue-tinting in post to pretend it was night time all along:

It’s a method filled with nuance, as this 11-minute video describes really well. This TV Tropes page lists a lot of examples from movies you might recognize, and another video by Rob Ellis has a lot of practical advice.

Now that you know it, you might spot it in movies that use it poorly: the ones that darken everything too much, the ones where too bright of a sky gives it away, or the ones where the shadows appear lunatic in the wrong sense of the word.

In UX design, you can day-for-night your dark mode as well – long before proper dark mode was a gleam in someone’s bloodshot eye, operating systems allowed you to invert their screens – but the limitations of that approach are apparent very quickly:

Sure, black becomes white, white becomes black, and grays swap places. But in real life, shadows do not get brighter at night, and photos do not behave that way, either.

The “proper” answer is not to do anything automatically and to go all out with a perfectly hand-crafted dark mode that’s an equal partner to light mode: a distinct set of semantic colors, a new strategy for shadows and layering, and a second set of visual assets like icons and images.

Here’s a comparison of naïve inverting and a proper dark mode:

A lot of apps do that for colors and shadows, some even providing multiple dark mode flavors…

…but visual assets is where things get tricky. Yeah, vector graphics can use the same swappable color variables as CSS text and elements, although in practice it is quite a bit of work and from my experience SVG doesn’t make it very easy, either (here’s an example from my essay):

But when it comes to bitmaps, they are usually left alone. Overtime is still overtime, and producing each bitmap twice is a lot of effort.

Since swappable variables don’t exist in this context, the only automatic approach method left is inverting, but a) inverting an already- dark image can make things lighter,and b) inverting things like photos makes them look creepy and mixes up all the colors:

What explains the last part? This has to do with the fact that inversion happens in the RGB color space. R becomes 1–R, and the same for G and B.

Everyone who’s into gradients knows of a similar challenge that results in the gray dead zone effect. This is fixable if you convince a gradient to traverse through a different space instead, or coax it through the RGB space on a more… bespoke path (this is e.g. what Figma gradient plugins do).

Could we invert in HSL or OKLAB color space, then? Yes, we could. They both look similar – this is HSL:

You can see how the photos get inverted now, but the colors remain the same! Still a curiosity, perhaps, but the bottom of the above screen shows this technique feels really interesting for diagrams, screenshots, and things of similar nature. Here’s another bitmap that looks pretty great inverted this way:

Unfortunately, while there are techniques and plugins to do gradients in non-RGB color spaces, I am not seeing a lot of options for inversion customization anywhere. Neither the graphics apps I use, nor CSS offer anything here.

But there’s a trick: do a regular invert and then rotate the hue halfway through. Through the magic of math, this is the same as inverting just L in the HSL space, which means the colors are preserved. This is actually achievable in graphic programs…

…and, more importantly, available in CSS as a filter: instead of invert(1), use hue-rotate(180deg) invert(1).

So, if you have dark-on-light diagrams, bitmapped text, illustrations, or other similar things – or even vector graphics you cannot throw dark mode variables at – this day-for-night trick that can get you places very cheaply. (And for other bright bitmaps, just reduce the brightness by 25%.)

It’s the same as with Hollywood trickery: remember to add a bit more nuance in the right place, and you get something that feels bespoke for the price of only light – please excuse the pun – manufacture.

This 22-minute video by Karl Jobst describes a pretty wild discovery of a glitch called Crystal Storage Glitch, allowing to skip a certain level for much faster completion times in Mega Man X2:

I won’t spoil the glitch because it’s a fascinating combination of a corner case, a race condition, and even a dose of dumb luck. Its finding unveils almost like a scientific discovery over many years – first a theoretical possibility, then a first sighting done in a modified emulator, then confirmation made by a machine via a tool-assisted speedrun, and eventually actual performance by someone by hand. And a lot of this achieved by relative newcomers to the community, too.

There is certain poetry here in having to go slow to go fast – you’ll see what I mean.

In Figma, when choosing a font, you can filter down a list of fonts from “all” to specific categories or e.g. only fonts present in the current file.

But when you type into the search field, the search cuts across all fonts again, ignoring the applied filter. The search effectively lives outside the filter.

In Keyboard Maestro, when adding an action, you can click in the nav to filter down to a specific category. And when you search, the current filter remains active, so you search inside the filter.

Which one is better?

I don’t have a universal rule here, because it will depend both on the UI treatment, and the specific filters and searches people do.

But I think here, my recommendation for Keyboard Maestro here would be to do the same thing as Figma does. I designed that flow in Figma, so I might be biased, but my reasons are:

• There aren’t really a lot of options in each category, so you don’t benefit a lot from double filtering.
• But the most important thing: For both Figma and Keyboard Maestro, the text field might smell like a text filter and as such expected to be multiplexed with the category filter, but I think this field is actually something else: It’s quick keyboard access, like ⌘F or Spotlight or Raycast. And if you think about it this way, it’s important for it to be deterministic – I can always type “Output Sans,” no matter what state am I in, and get to the font.

On that last note, I find it’s good to look around what you’ve designed once in a while and consider not what the UI set out to be, but what it became – there might be more examples of that around you.

Andrew Gleeson designed Analog Mono, “fixing the crimes of VCR OSD Mono.” There used to be this classic pixel font that you’d see everywhere in the 1990s on hi-fi equipment: VCRs, TVs, camcorders, etc. One of its challenges was a low baseline which resulted in all the letters with descenders pulled up, for example:

Analog Mono fixes that problem:

Elsewhere, Kumiko Yoshida made Coral Pixels (also on Google Fonts), a color font that comes with the 1990s and 2000s colorful fringing baked in. The fringing was once an artifact of subpixel rendering, but now it is meant to evoke nostalgia or just as an interesting visual element in and of itself. (Perhaps adjacent to chromatic aberration?)

Lastly, here’s Two Slice by Joseph Fatula – a font that’s only 2 pixels tall, “and somewhat readable.”

Of course, these are all vector fonts – e.g. ready to be installed on a modern operating system – pretending to be pixel fonts. That’s maybe a separate post altogether, but it leads us to the last font, Geist Pixel from Vercel:

The copy introducing the font is a little pretentious/​spicy, but it touches upon something important:

Geist Pixel isn’t a novelty font. It’s a system extension. [… It] was designed with real usage in mind, not as a visual gimmick, but as a functional tool within a broader typographic system. […] This matters because pixel fonts often break in production. They don’t scale properly across viewports, their metrics conflict with existing typography, or they’re purely decorative. Geist Pixel was built to solve these problems, maintaining the visual texture teams want while preserving the typographic rigor products require.

There are definitely fonts whose Achilles’ heel is not the letterforms, but the invisible hard work put into everything that surrounds them: the kerning, the metadata, the extra glyphs, the vertical metrics. It seems that the team being Geist Pixel is proud of especially that last part.

A nice, but unpolished onboarding callout directing people towards a more useful shortcut, in Google Docs. I’m holding arrow keys without ⇧ here first, then with ⇧:

To improve it, I would add some sort of small celebratory “completed!” state, and auto-hide it afterwards; right now, it seems that it hides on a delay, likely regardless of what happens.

(Testing onboarding is hard because once it’s invoked it disappears forever. If you are worried about onboarding experiences in a place you work, please insist on easy toggles to bring it back for testing. And no, one-size-fits-all “reset onboarding” is too crude; ideally you can reset each specific one easily through a simple UI.)

Thank you to Ezra Spier for the tip.

Here’s a 2002 story from a younger internet, by programmer Trey Harris (link to the original and if you don’t like the classic Usenet formatting – my browser’s reader mode can’t even prettify it! – here’s a nicer-looking format):

“We’re having a problem sending email out of the department.”

“What’s the problem?” I asked.

“We can’t send mail more than 500 miles,” the chairman explained.

I choked on my latte. “Come again?”

“We can’t send mail farther than 500 miles from here,” he repeated. “A little bit more, actually. Call it 520 miles. But no farther.”

It would be easy to assume this is a classic case of pebkac, “problem exists between keyboard and chair,” the derisive term used (supposedly!) by support people, describing naïve public who had a tenuous grasp of technological reality. But the story goes to an unexpected place.

This might be the most widely-shared computer bug story of all time I’ve seen – I just saw a comment from 2008 calling it “oldie but a goodie,“ and it even has an FAQ page that’s actually a really great read. There’s quite a bit of chatter inside about something important to me: the balance between the needs of good storytelling and going deep into technical details:

In the story, I make it sound like it took all of ten minutes from being made aware of the 500-mile email limit and determining a 3 ms light-speed issue. In fact, this took several hours, and quite a bit of detective work. The point is, eventually I came up with that figure, ran units, and gagged on my latte.

You can sense author’s frustration with every nerd trying to “gotcha” him instead of just enjoying the story. Even a younger internet wasn’t without faults.

A delightful 24-minute video from ToffeeBun about sampling in videogame music and how it changed over the years:

The video helped me understand the difference between tunes purely synthesized from soundchips, those sequenced with samples (e.g. MIDI or sound trackers), and those that are completely “streamed” (e.g. MP3). It’s stuff in between that’s the most interesting – it always is – with really surprising sources of samples (and, surprising samples!) needed to “perform” sequenced music.

The video itself is frenetically edited, and the opposite of “dry” (which I mean as a compliment).

I love looking at origins of obvious things, because of two things:

• They help me get unstuck. If you go far enough, you will find out that even the most ossified conventions that are older than you haven’t always been this way.
• They put me in the mood of “what of the things that feel normal today that deserve to feel dated, obsolete, or awkward?”

I’ve been emulating the Apple Lisa recently, and I was struck by how many of its UI strings were slightly or wholly different than what we’re used to.

It makes sense. Lisa came out in 1983 as Mac’s predecessor and really the first GUI that is directly linked to what we’re using today. Even though it borrowed things from work done at Xerox, tons of conventions were not established yet.

So, I thought it would be fun to actually take a closer look.

For context, Lisa was as slow as it was expensive, and generally considered a failure. It was basically abandoned by 1985. Not much third-party software has ever been written, but Lisa shipped with 7 impressive office apps with fantastic names: LisaWrite, LisaCalc, LisaDraw, LisaGraph, LisaList, LisaProject, and LisaTerminal.

The screenshots below come from an emulator and from manuals (this links to the 1984 version, but each manual also includes a link to the original 1983 edition). The emulator is pretty harrowing; please upvote the idea of Lisa in Infinite Mac if you would want to see it!

As Lisa powers up, we see the appearance of the “wait” dialog box. We’ll encounter more symbols like this triangle, inspired by traditional flowcharts.

Let’s start with menus, as these really were the treasure map to the whole system.

The Desk menu is basically the equivalent of the dock today.

The File menu has Print appended to it, indicating how important printing was still then; a truly “paperless office” won’t really be possible for two more decades (and seemingly still hasn’t fully arrived).

There is no Window menu yet, so the menu also contains some of that burgeoning functionality. Set Aside is what we would call Minimize today. Save & Continue is basically a contemporary Save, and Save & Put Away a hypothetical Save & Close. Revert to Previous Version is the same as today’s Revert. By the way, in the Revert dialog I appreciated the nice gesture of telling the user how much time passed since the last save, and a warning about undo (we’ll get back to this):

Print Current Selection would today be just Print Selection. Print As Is is basically Print… but skipping the setup dialog with number of copies, etc. It was added later in Lisa’s life, and today, we’d probably call it Print Again?

If you’re noticing a pattern already, it is more wordiness compared to what we see these days. It makes sense. Our growing familiarity with these concepts is what will allow these strings to become tighter over time.

This is that Print… dialog, by the way, with beautiful “while you wait” and “while you work” verbiage (although usually I do not condone strings getting so close to each other). The manual explains: “You can have the Lisa use most of its attention to print your document while you wait. A document will print more quickly if you choose While You Wait, but you won’t be able to use the Lisa for any other tasks.”

The other strings feel less typical. Format For Printer… is Page Setup, but with a lot of quirks. Printers were not usually yet WYSIWYG, able to mirror stuff exactly on the screen. They often came with their own fonts, so some matching was necessary:

The manual had an entire section called “When Settings Don’t Match a Printer,” and there were I imagine god knows how many error cases that had to be covered, including:

And Monitor The Printer… is today’s Print Center: a way to see the real-time printing status. Note a lot of writing here elaborates further on the “while you wait/​while you work” dichotomy:

Monitor The Printer was important, by the way, since the manual warned you your printer might occasionally become haunted:

But, let’s go back to the File/​Print menu. I actually found a version of this menu that comes from a 1982 pre-release Lisa, never launched to the public. Let me show them side by side:

It’s fun to see designers figuring it all out. You will notice the lack of dividers and ellipses actually touching the work-in-progress strings. 1983’s Set Aside is 1982’s very modern Close. Save & Put Away is Put Back. And, at the bottom, it seems the team didn’t yet figure out that the menu options need to consistently use verbs for commands, and adjectives or nouns for toggles – so we see Intended for Printer… (rather than Format For Printer…) and Printing in Progress… (rather than Monitor The Printer…).

Lastly, in a released version of LisaList, this menu would come bearing a harrowing Fix Damaged Document command. Not only it doesn’t even have an ellipsis, but the manual also says “there is always the chance that the recovery process will make things worse instead of better.” Vaya con dios, I suppose.

Let’s move on to the Edit menu.

Today’s Select All is a verbose Select All Of Document, and since this is the first public appearance of undo, that feature is also more descriptive, appearing as Undo Last Change. But otherwise the menu feels surprisingly modern, shortcuts and all.

Unsurprisingly, the first undo wasn’t as developed. We saw earlier in this post “Once you click OK, you will not be able to change your mind, even with Undo,” which today would probably say “This is not undoable.” You could also see a frightening error message arriving without any further clarification, like above.

Sometimes, the app would warn you undo doesn’t have your back. We’ve seen this before, and here’s another example.

Since undo only had one step, LisaCalc and LisaList also had Restore Previous Entry for when you changed your mind after editing a cell in the spreadsheet. You had to employ this strategically, as you did the already-mentioned Revert to Previous Version.

“You can even undo Undo!” bragged the manual, and I imagine there must have been interfaces where undo came without a matching redo. But the eventual solution, of course, was bidirectional undo/​redo with many steps. This basically only needed more memory, still very expensive in 1983.

Above we also see Clear Entries that would just be called Clear today.

Elsewhere in Edit menu, Clear Lines Off Top would appear in LisaTerminal only, and was a charming (and I would argue better) way of saying Clear Scrollback.

The next menu, Type Style, would be called Font today. “Type” is typewriter nomenclature – Lisa was meant to be a typewriter replacement. The point/​pitch convention for font sizes and letter spacing also comes from typewriters, and in an older version of that menu even font names arrive from that universe (PS = Proportionally Spaced!):

Otherwise, notable is the deterministic Plain Text reset with a P shortcut that would in time lose to printing. I miss this sometimes, this “reset” idea, as I think it would nicely compliment Paste And Match Style.

(By the way, Lisa was the last computer to use Apple logo as a modifier key.)

While Type Style is for selection, Format ¶ is all about paragraphs – HTML people know this distinction as “inline vs. block.” (The pilcrow symbol means “paragraph,” although I did not expect it to be common use even then.) The flyout menus with their convoluted mechanics weren’t invented yet, but in some sense there was no need for them as the options were very limited.

It is interesting to see Margin/Tab Ruler as two options with deterministic shortcuts ([ and ]). But the most unbelievable shortcut must be Same As On Clipboard. It reformats the current selection to match what you have in the clipboard – an early salvo in an endless battle that later brought us Paste Special, Paste And Match Style, Paste And Retain Style, Copy/​Paste Properties, Paint Format and so on, and so on. And it was given S, rather than spending it on Save (& Continue).

Otherwise Left Flush and Right Flush would be called aligning today, and the ¶ pilcrow symbol would be replaced by a simple Paragraph Spacing.

In LisaCalc, Format is missing the ¶ because, well, there are no paragraphs in spreadsheets! I love Words Left/Nos. Right, and empathize with trying to align the digits. But it wasn’t even close, was it.

Page Layout shows that we’ve had UI boolean problems from day one. Show Page Ruler and Hide Page Ruler do it deterministically, with one always disabled, and without checkmarks. Preview Pages and Don’t Preview Pages do the checkmark, but introduce a dreaded double negative. (These last options, by the way, is the “pages/​pageless format” showing page margins and dividers, that bother us so much about Google Docs.) Today, these would all be in the View menu that doesn’t exist yet.

And speaking of boolean challenges, here are some top-level menus from LisaList with even more conventions:

But, back to the Page Layout Menu. Insert Page Mark would be Insert Page Break today. I really love Allow To Cross Pages as the opposite of Keep On Same Page, and the incredible O and Q shortcuts.

In LisaCalc, this particular menu comes with a beautifully named For Your Information (sentence capped, for some reason)…

…throwing up a sheet-like window showing basic stats. Today, that window would have a more boring name and probably land in the File menu:

The Search menu is fascinating – why wasn’t it called Find like its items are? I am particularly enjoying W keyed off of Find What (today: Find), while F is taken by Find Next Occurrence (today: Find Again). There is some mnemonic sense to it all, but I like today’s proximity of ⌘F/G better.

What we know as Replace is Change here, and I am particularly loving Cases Must Agree and Cases Need Not Agree (today usually called “case sensitivity.”)

Hide Dialog Box is a string with surprising to me amount of UI jargon. The H shortcut was added later in Lisa’s life, presumably at users’ behest. It’s strange today to see a shortcut like this to hide one specific floating dialog box.

Similarly, Insert Wild Card with a confusing ellipsis allows you to insert a symbol in your find dialog that stands for “match anything here” – top-level menu options reaching inside specific dialog boxes were not uncommon in early years of GUIs, but I think fell out of favor over time as the idea can be conceptually confusing.

The menu below is from LisaWrite, and I like how comparing it with other apps makes us see the team trying to settle on a convention. In LisaList there are no ellipsis, but question marks!

And in LisaCalc, there are… both:

You can notice that it wasn’t clear where one would put Find-related commands and their today’s presence in Edit menu doesn’t really make a lot of sense, either. We just got used to it. (Also note the “occurence” typo.)

Spelling menu has a bunch of fun options and conventions, and an extremely generous use of keyboard shortcuts:

• Find Next Misspelling (you don’t often see that word!)
• Suggest Corrections + Paste Guess (this is just replacing the word with the suggestion – interesting use of the clipboard metaphor)
• Put In Dictionary (today: Learn Spelling)

LisaDraw sports the Arrangement menu, which will look very familiar to anyone using Illustrator, Sketch, Figma, and so on. This is where Bring To Front and Send To Back started! With a tiny bit of editing (Arrangement is now Arrange, and some of the Objects nouns would be omitted), this would feel pretty modern.

I love these visual menus, and I think we lost that kind of stuff along the way:

Okay, let’s move on from menus. The system also relied a lot of dialogs. Let’s look at some of them:

This wordy dialog would become a small loading state today. The verbose “To terminate the operation, hold down the Apple key while you type a period” probably felt necessary because other than Shift on a typewriter, people were not familiar with modifier keys. Lisa doesn’t have the Esc key, and Mac still respects the ⌘. convention in many places in 2026.

(By the way, why would you want to stop saving? Presumably because it could take quite a while.)

In this similar dialog, you can see a reference to a “micro diskette.” Even though Lisa’s “Twiggy” disks seem gargantuan today, they were smaller compared to the original, 8″ floppy disk. (In a similar way, Lisa and other machines of the era were called “microcomputers.”)

Lisa had some proprioception: In this dialog, the disk put in the first drive is called an “upper diskette.” (Also note: more undo education.)

Disks were not large, so sometimes you had to deal with this kind of horror. It’s interesting how the dialog plain sends you to the manual – an early equivalent to eventual Learn More links.

This is another example of a rather verbose set of instructions. On one hand, this is better than “Error 456” and nothing else. On the other hand, it feels like a lot of stuff to memorize.

Also of note, the beautiful Housekeeping menu. I actually forgot about the Finder (or, in Lisa’s parlance, Desktop), so here’s a screenshot of it also:

Housekeeping was basically the junk drawer – on the Mac a year later, this will be named Special. It also has some stuff that today would be in the View menu. (This later version of Lisa calls Trash the same as the Mac. Earlier on, you would see it named a Wastebasket instead.)

Of note elsewhere in Desktop is the use of the term Stationery, roughly meaning “template,” but with extra sprinkling of desktop-metaphor skeuomorphism. Also, Attributes Of is an early version of Get Info.

Another verbose dialog (compare with Abort/​Retry/Ignore from around the same time). This is before we invented hint text that we’d just put under the buttons themselves.

In case you haven’t noticed by now, Lisa’s strings all have two spaces after a full stop!

There was lot of “you cannot” dialogs, walking you through some recovery steps.

Plug and play didn’t yet exist (this would all happen in the 1990s), so that had to be explained also.

I also love the anthropomorphic phrasing “Preferences has been told,” which I don’t believe you see anywhere today.

And I think we can round up this post with a few small delightful language details like this one.

As a huge fan of the slightly pretentious “presently” over “currently,” I smiled seeing this next to the printing status.

“Just a moment, please…” feels so old-fashioned, somehow.

And I want to end on a pre-release version of the Edit menu we’ve already seen. You can spot here Select Entire Document (instead of eventual Select All Of Document), but of course the best thing is the Copy, Cut, & Paste with an ampersand! I find it so, so charming.

I hope you enjoyed this tour. It was interesting to me to see how many of these became the standard back there and then, how many were tweaked a little bit, and which ones had to be redone more thoroughly.

Now, excuse me as I have to go deal with my whistling printer.

I have mixed feelings about Raycast announcing their move from the native interface to one powered by web tech (this is the same thing that made Photoshop’s dialogs so bad), but their blog post announcing the change has at least a useful list of some details that separate good native apps from bad web ones.

I think it’s worth checking out that list and internalizing it even if you’re nowhere near that kind of a decision, because some of these are universal requirements for a better-feeling interface:

• No cursor: pointer on interactive controls. Desktop apps don’t do this. It’s small, but it immediately signals “this is a website.”
• No hover highlights on most controls. On macOS, buttons and list items don’t highlight on hover the way they do on the web.
• Settings open in a separate native window, not a modal or a side panel.
• Popovers and tooltips render as native windows, not as DOM elements inside the WebView. They can extend beyond the window bounds, just like native popovers do.
• On macOS Tahoe, we adopted Apple’s new Liquid Glass material so Raycast blends with the system’s updated visual language from day one.
• No flickering when views appear or transition. This is a common tell in web apps, and we did a lot of work to eliminate it.

There is more in the blog post, and a lot more still left unsaid. Let me add one that I see all the time: accidental text selection. Web makes all text selectable by default, regardless of whether it makes sense for that text to be selected. On top of that, text selection heuristics on complex layouts are not that great. That means that surprisingly often you will see half a text on the page being selected in response to an accidental click or drag.

Here’s an example from YouTube I just spotted, where dragging a sidebar selects everything inside it:

It’s all solvable via the use of event cancellation and user-select, but requires someone to think about it happening.

Yes, there are moments where GUIs allow you to select text for a reason…

…but it’s always been a tricky proposition given the scarcity of affordances. It might be better to employ a pretty common “copy to clipboard” pattern instead.

Chrome’s find option, like every search coming from a good home, does something clever with accented characters – it normalizes them:

No matter whether you search with a proper accented character, or with its basic Latin equivalent, all the same stuff matches: The “ø” letter is treated the same as “o” both in the input field, and then in the search itself.

Yet, Chrome’s tab search inexplicably doesn’t do that, which confused me when working on a post about diacritics earlier this week. Here, it should match all four open tabs:

Tab search was introduced years ago; the Occam’s Razor says this isn’t a recent bug, but that the feature has always behaved like this. I filed the bug, but even if it gets fixed quickly, I think this doesn’t reflect well on Chrome’s team. If the right code already exists for ⌘F, why not reuse it? If it cannot be reused, why not repurpose at least its unit tests or the QA process to make sure this doesn’t fall through the cracks? Normalization should be treated as a core property of any search, rather than an optional “nice to have.”

But, Marcin, didn’t you just invalidate your assertion that diacritics actually matter? After all, wouldn’t you input “nestlé” instead of “nestle” if they did?

To this, I have a few answers:

• Input is not output. This is no different than autocorrect, autocomplete, or other IME helpers.
• The very fact that on many keyboards accented characters are hard to input is itself a sign of anglo-centrism of companies that made early typewriters (Remington, which established a lot of European layouts like QWERTZ and AZERTY, employed a person who bragged he didn’t actually speak any languages in a “how hard could it be” way) and then most microcomputers.
• There is this really interesting rule, also known as Postel’s Law: “be conservative in what you output, but liberal in what you accept as input.” It’s not universally applicable – sometimes it’s better to teach the user to be more explicit if it benefits them in the longer run – but it feels appropriate to me here.

Why does it matter specifically for the ⌘F and the tab search experience? I have this personal theory: the simplest the search, the more the users will blame themselves if it doesn’t work, and assume the tab or the string just isn’t there, rather than rewrite their query. That’s what happened to me. I assumed that the tab wasn’t open and tried to get to it again, wasting time and effort.

The rule might be universally true for any UI surface – the tighter it gets, the less likely we assume it can break. After all, there is a manual for a typewriter, but there isn’t one for the pencil! And these UIs do feel positively basic; they are small windows with basically one input field and an immediate as-you-type reaction.

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.

Turns out that the breathing light survives, sort of, not really, in an Apple product today:

The AirPods Pro case does this when charging – right at the start, or when you tap it later. But it disappears after a while, the pace is now 28 breaths a minute (over twice as fast as the original iteration), and the light is orange.

Is it still the same thing, reflecting on how smaller organisms breathe faster? Or is it mostly an unrelated idea, with the light fading in and out indicating activity rather than lack of it? My money is on the latter – the light turns white when pairing, too, and it cycles even faster then – but it was nice to imagine the return of the old feature for a second or two… or 2.1, to be precise.

This DOS demo called Wake Up! is astonishingly small – only 16 bytes:

The demo doesn’t just make QUOD feel gargantuan. Output this one solitary emoji, “Woman Technologist with Light Skin Tone” – 👩🏻‍💻 – and you spent all your 16 bytes, too. (Proof!)

The creator’s write-up is a bit hard to follow, but there are some interesting aspects to it: “stealing” the beauty from math itself, the reliance on the environment being set up properly (to avoid wasting precious bytes on initialization), and the tight connection between the hardware, the visuals, and the sound.

Oh yeah, in case you haven’t noticed, this has sound! Two out of 16 bytes are devoted to its production, using an existing BIOS function that slots nicely into the existing graphics routine.

This is another recent demo that caught my attention: NINE, from about a year ago:

The platform here is a computer of a similar vintage as the early DOS machines, Commodore 64. C64, like many other home microcomputers, supported special graphical entities called “sprites,” which were used for gaming since the rest of the graphics couldn’t move very fast. (Today, your mouse pointer is conceptually similar to a sprite, being imbued with special powers unavailable to anything else.)

C64 could output up to 8 such sprites. The demo inexplicably has… nine.

The NINE demo didn’t focus on absolute minimalism, but instead employed a barrage of ghostly (and ghastly!) trickery to achieve something that was thought impossible. This time around, the explainer from the author – a 22-minute YouTube video – is filled with great storytelling, and absolutely worth a watch:

I think both of these showcase two things that I appreciate and that translate to great UX design as well.

The first demo shows tight integration between design and the capabilities of software and hardware. Let’s pick the sound routine that needed just 2 bytes. If there wasn’t a way to output sound within this extremely tight budget, the author likely wouldn’t fight to their death to get sound… they would instead focus on what else was possible within two bytes. This is getting as close to full understanding of the medium you’re working in as possible.

The second demo highlights how sometimes you can use absolutely horrid sleights of hand to achieve something beautiful – and how you can perhaps find beauty in those sleights of hand, too. It reminds me of the quote attributed to Teller (of Penn & Teller):

Sometimes magic is just someone spending more time on something than anyone else might reasonably expect.

Penn & Teller talk a lot about how there are only two keys to their success: going further than others would think, and not worrying about employing inelegant tricks in service of something that would appear to be of utmost elegance.

Today’s computing limitations are different than the ones from the 1980s. But a lot of this attitude can still be helpful, even four decades in, and even if your work seems as far away from the demoscene as you can imagine.

The iOS 26 update introduced a bug in the Czech keyboard. Instead of the customary háček (ǍǎĚěǦǧǏǐǑǒǓǔY̌y̌) in the bottom row, another key was duplicated, removing access to the accent character (or, a diacritic) very popular in that language.

Here is the before and after of this situation:

Ordinarily, this can be frustrating but not insurmountable; you can always copy/​paste, rely on autocorrect to help out, or even add some topical text replacements for common phrases. The problem is that this bug only appeared on the keyboard used for logging on, and at least a few people used that character in their password. There, none of these workarounds were available – and so those people were now completely locked out of their iPhones.

The Register reported on this on April 12, and a few days later suggested that Apple was working on a fix. I won’t keep you in suspense; I just verified that the fix landed with the recent May 11 update.

This is, in an of itself, not a fascinating story, but with interesting things to talk about at its periphery.

First of all, The Register never showed a single screenshot. This led to a lot of confusion and speculation in the comments. Turns out, screenshots are valuable not just with bug reporting, but also with bug reporting.

Second, check out this Czech keyboard. Even within the limitations of the ancient QWERTY, there’s a lot of cool stuff happening here. Two new accented keys just appear on the top layer when you switch to Czech. Both have magical properties, too. They’re the modern “dead keys” that either stand alone, or get combined with the previous letter if that makes sense.

This is the stuff typewriters, and even desktop keyboards, could only dream of. But, as always, more software means more bugs, including some with unforeseen consequences; a typewriter could never break this way.

Thirdly, there is this interesting tension between us being led to believe “more interesting passwords are safer,” but then sometimes being penalized for actually making them interesting. A decade ago someone used emoji in their password without realizing they won’t be able to input it, and I’m sure there were other examples.

But the most interesting, to me, part? It’s the diacritic itself. Under one of the posts, a commenter wrote:

Stick with the 7-bit ASCII subset. You will never go wrong.

7-bit ASCII basically means “26 Western letters and nothing else.”

I hate this. I know it’s objectively true – in the late 1980s I felt a sense of relief my name didn’t have any of Polish language’s nine diacritics, which would complicate my life. Even just yesterday in Germany, I spotted this:

Software still struggles beyond ASCII. But this is why we need to keep pushing. Diacritical characters are to be found everywhere in the world. They’re detailed, and varied, and filled with histories. Umlaut is not diaeresis. Kreska is not the acute. A háček is not a breve. They’re rarely optional decoration, and often not even decoration at all; learning about Turkish dotless i might completely upend your understanding of what’s an accent and what is not.

If you don’t have a favourite diacritic, you are missing out. Even the names – grave! ogonek! horn! – are beautiful. (Háček is also known as caron and a wedge depending on context, and in other regions referred to with beautiful words kvačica and strešica.)

If you’re interested, here is David J. Ross’s 22-minute talk about getting to love diacritics from the perspective of a type designer. It’s filled with craft and playfulness:

My favourite accent is, obviously, ogonek. Just looking at Adam Twardoch’s guide on how it should be drawn fills my heart with joy:

A simple rule for overflow logic that will prevent your app looking a bit stupid…

…is to avoid “more” expanding to just one item. If the expansion takes up as much room as the UI to show the expansion, why not show it in the first place?

A reader asked me this, and I thought I will answer here:

One bit of challenge with [where I work] is that my audience isn’t already almost-guaranteed to be into design! They’re hopefully interested in making good software in general, though, and probably curious about the app [I’m building] they could be using. I’m also afraid that developers sometimes confuse “easy to use” with “beginner-only, limiting”, which makes it harder to write about streamlining UIs; there’s only so many times you can invoke “reducing mental load.”

I love this question because it gets to the core of why I started this blog. I’m perennially unhappy with the conflation of “craft” with “delight,” and the subsequent narrowing of “delight” into “cute strings and slow animations.” In the famous words of Steve Jobs, “Design is not how it looks. Design is how it works. What’s tricky is that they’re sometimes related, and even if you learn how to tell the difference, your exec team probably never will.”

I am quoting from memory.

Anyway, I hope spending time on Unsung – please like and subscribe – helps with examples of what to talk about and how to talk about them. But, just to list some alternatives to “reduces mental load” for well-made software that come to my mind:

• is more efficient
• gets you home earlier
• will allow you to spend more time on things you enjoy
• will allow you to choose which parts of the problem to spend time on
• reduces tedium
• understands and practices progressive disclosure
• understands you
• speaks your language
• learns your preferences
• meets you where you are
• is made by people like you
• respects you
• will make you better at what you do
• rewards mastery
• doesn’t dumb things down
• will teach you concepts helpful in other software
• never takes control away from you
• is easy to customize
• adapts to you
• doesn’t disobey you
• will make you look good in front of others
• respects history and legacy of the space
• is built well
• is conceptually/​systemically beautiful
• is well-considered or thoughtful

There’s more, and I am curious what comes to your mind and how you all connect with developers! But maybe just going through a list like this will provoke some ideas.

(Of course, if you cannot honestly claim some of these about software you’re working on, and you think they’re important – I guess you have some work to do.)

I like the Fits on a Floppy manifesto by Matt Sephton:

Software should be as small as it can be. Not as a gimmick, but as a discipline. The floppy disk is the measuring stick: 1.44 MB. If the software that ran entire businesses could fit in that space, then a modern, focused, single-purpose tool certainly can.

In my own work, I have mostly focused on the web side of this equation, as this is where the situation feels the most dire: tens of megabytes dedicated to heavy frameworks, unnecessary tracking scripts, and video ads have a real negative effect on experiencing websites. Progressive loading challenges also make it harder to offer a great experience.

But space considerations are starting to feel more pertinent to local software too, in an era where SSD and hard drive prices are going up, and where local LLM models start taking up more room.

Also, this passage feels very Unsung, and is exactly why the tag #history exists on this blog:

I don’t miss floppy disks. I miss the mindset they demanded—that every byte matters, that constraints breed creativity, and that software should be light on its footprint.

If you reduce tech history to just nostalgia, it won’t be that useful. But if you look at it as inspiration, you might find some truly wonderful and meaningful stuff in there.

On that note: Bonus for a nice classic domain, and a nod toward Mac’s most famous screensaver.

To me, “tap anywhere at the top to scroll to the beginning” is an amazing and underappreciated mobile gesture:

It not only provides an alternative to desktop‘s Home and ⌘↑ keys, but the student laps the teacher here; it’s actually better than every way to scroll to the top on desktop (do you like pressing ⌘↑? do you even have a Home key?), and it’s an icing on a cake of a regular flick to throw the page to the top already being pretty nice.

Tap to return to top is also distinctively mobile in that it allows you to tap just anywhere near the top edge that’s not already a tap target; as far as I can observe, traditional GUIs detest being imprecise in this way, always asking you to click on something specific (although window moving on macOS in the post-title-bar era is also starting to feel similar).

The iPhone gesture seemed to work so well that, over the years, more patterns started borrowing from it. In Bluesky and tons of other apps, you can tap on any tab with scrollable content a second time to scroll all the way to the top. (Again, something that’s hard to imagine on desktop, where you pretty much almost never think of clicking on an already-selected item.)

It’s not just the top, either. In Podcasts, tapping Home goes back to the left:

And in Photos, to the bottom:

To me, the whole “tap to return to the beginning” gesture universe feels ascended to be the core property of the interface. In that way, it is similar to scrolling, undo, copy/​paste, arrow keys moving the text cursor, and so on, all inducted to the National Register Of Historic Gestures.

Why? Because these gestures can only blossom if they work consistently, everywhere. You need to start trusting them so much they slide into your subconsciousness. Breaking the gesture in one place will make it less trustworthy in other places, too, ejecting it from motor memory back to the level of deliberate effort, and therefore making it a lot less usable. “Does this thing work here or not?” is a death knell of flow.

The fact that tapping on tabs is idempotent means there’s also no penalty; if you’re already at the beginning but are not sure, tapping it mindlessly won’t hurt or send you back somewhere else.

This is all great. And this is why I’m unhappy Safari started mucking with it.

Safari has tabs at the bottom – starting with two (regular set and “private” set), although you can add more. Above is a long list of site cards, with newest at the bottom. It’s exactly the same situation as in Photos, and yet tapping on either tab doesn’t restore the scroll position. Instead, it opens the settings dialog:

And, tapping around the buttons does nothing.

I would imagine Safari is a pretty important app used by many people, and so this feels like a bad place to introduce an inconsistency that could have a more serious consequences of un-teaching people about tap to scroll to top in the long run.

The funny thing is that the solution is already there: you can tap ··· in the upper left corner to get to the same functionality. The long press on the tab also opens the same menu.

Messing with a “tap to go back to the beginning” system gesture like this means to me the design team doesn’t fully share the understanding of the value of their own creation, or maybe that stewards of the gesture system are not vigilant… or perhaps the awareness is there, but the caretakers aren’t recognized, rewarded, or empowered enough.

It’s similar to the “no, thanks” example I shared before, a possible worrisome tragedy of the UX commons in the making if the respective teams do not change course. Because, wedging that sort of an exception in – even if you have a great set of reasons in the moment – creates a precedent. Inevitably, from my experience, the next team that will want to override scroll to top, or misuse “No, thanks,” will now require less of a justification.

More unexpected Mario content: a 7-minute video speedrunning composite by FlibidyDibidy:

This video combines my first 5,162 attempts to speedrun Super Mario Bros. I recorded 193 hours of attempts (and practice) on an original 1985 Nintendo Entertainment System, then I wrote a custom computer program to process those videos and combine them via machine learning and conventional image processing techniques.

This is not just fun to look at, and – presumably – study as you’re speedrunning yourself. A sign of a good visualization is that it makes you see stuff that you haven’t before and here, at some point (after 1:42), you start noticing strange comb-like patterns in Mario running.

Turns out this is actually a thing called a “frame rule,” a quirk of game’s timing code where it only checks for a completion of the level every 21 frames, or one third of a second. That means that for every level after the first one, your start will be rounded up to the nearest 21st frame:

The analogy often given is to think of a bus that leaves every 21 frames, and levels can only end by getting on that bus, and so other than in the last level (which has no new level to load at the end of it), improvements in Super Mario Bros. can only happen in 21 frame increments. If you save a frame or two in a level, but it’s not enough to make the previous frame rule, it’s not enough to take the previous bus, you’ll just end up waiting for it to happen anyway.

Stay tuned to the end of the video for some fun stats, and click through in the description below to see the same tech applied live during an in-person speedrunning event.

I like sharing, thinking about, and revisiting basic rules and principles because they really do ladder up to help you with more complex things down the road.

I wrote before how a simple rule to give some breathing room to your length-limited edit fields can be upleveled to a more general “let me color outside the lines when I’m editing” principle. This is another example of a similar situation.

I am in Buttondown, which is a mailing list software. I created a quick test draft just to check something out in the editor, I didn’t do anything else, and then I proceeded to delete it. Then, I was greeted with this:

This is nothing more than a larger version of the “You have 1 email(s)” problem. There might be a situation when I’m deleting something that has been published and linked to. In that case, it’d be good to know about how any links to that thing will cease working.

But this is not that kind of a situation, and the software has all the info to know that. In this moment, it could show me a simpler, much less alarming message more appropriate to my situation. This is not the end of a radio pharma ad where you have to rattle out all the legal disclaimers just in case something could happen.

One tiny counterexample from my neck of the woods: in Figma, when you start writing a comment and then exit without posting it, you get a little warning. But you don’t get that warning when you type something that’s <= 8 characters. In this case, the assumption is that retyping a few characters elsewhere (assuming you haven’t just changed your mind altogether) is much easier and faster than cognitively processing and dismissing the warning.

The challenge with Buttondown’s dialog is that this is more than just extra cognitive processing and “cheapness.“ Here, the stakes are higher, as we’re talking about something adjacent to data loss; the dialog really does feel a bit scary and makes me think I can do some real damage in a situation no real damage is possible.

Software engineer Ajitem Sahasrabuddhe recently wrote a 6-post series called “Iron Core” about airline ticketing infrastructure. The entire series is probably too software engineer-y for us, but the third part has some interesting info about a particular 1960s user interface called “cryptic mode”:

Cryptic mode was born from a hard constraint: teletype terminals in the 1960s billed by the character transmitted. Every keystroke cost money. A command that took 50 characters instead of 10 cost five times as much. Commands were compressed to the absolute minimum.

The result is a domain-specific language whose syntax was shaped entirely by economics. AN for Availability Next. SS for Sell Segment. NM for Name. ER for End and Retrieve. No vowels wasted. No words spelled out.

Apparently the official name is “native mode,” but it gained its nickname because… well, see for yourself.

Asking the system for “Availability for Next flight” for February 8, from Nagpur to Delhi, is just 13 characters:

AN08FEBNAGDEL

And the system responds in an equally mysterious way:

** AMADEUS AVAILABILITY - AN ** NAG DEL SU 08FEB 0000
1 AI 416 Z9 C9 D9 Y9 B9 NAG DEL 0840 1030 32A 0
2 AI 416 M9 H9 K9 Q9 T9 NAG DEL 0840 1030 32A 0
3 6E 5317 S9 T9 W9 V9 Q9 NAG DEL 0840 0755 32A 0

With time these commands became wrapped inside more approachable interfaces and GUIs. But they exist under the hood and…

Many experienced travel agents still use it today alongside, and sometimes instead of, web-based agent interfaces such as Amadeus Selling Platform Connect. For a trained operator working a booking-heavy workflow, it is faster than the equivalent graphical interface for the same sequence of operations.

Except today, you get to choose. At the beginning, when “online” didn’t imply internet, and registration computers looked like this, you didn’t have a choice: this was the language you had to fluently write and read.

It makes Unix commands, also intentionally short/​cryptic, look like Microsoft Bob.

In light of a recent Googlebook announcement that uses a mouse wiggle gesture for AI (which to me doesn’t seem like a pleasant interaction), some of us were talking about how, on macOS, mouse wiggle helps you locate the cursor by making it bigger.

I am maybe a sucker for videos and podcasts where people start laughing, but here we go – a very short video about a version of Linux that “does not limit how big your pointer can get if you wiggle the mouse pointer”:

A fascinating 9-minute video from PawelCodeStuff about randomness in the context of computing:

It explains those weird moments where sometimes the computer asks you to wiggle your mouse – to generate unpredictable numbers – although the specifics of what exactly was random in my wiggling was a surprise to me.

There is something poetic about computers yearning for that one thing they can never get – complete unpredictability – and collecting it in a little pool like you would something very precious. Also fascinating that in modern CPUs, there now exist hardware components that gather truly random data from the real world.

While I have never needed true randomness in my design career, knowing how to control pseudorandomness (specifically, how to replay it) has been helpful.

Here’s an example. In my essay about Gorton, there is this interactive bit where you can drag a slider for “messiness.” With regular pseudorandomness, the experience is wiggly and gross:

But when you always restart the prng from the same seed (“the Groundhog Day maneuver”), it feels much better: