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: