This is what happens when you go to the homepage of Gemini and start typing quickly:

Mechanically, I think this is React or some other framework setting focus again with some delay, but the end result is… rather disturbing.

While the technical solution would be to fix the problem or at least do not set focus again if already set, I wonder what’s the real challenge here. I imagine it might be that the testing process (if any) assumes using the mouse or trackpad first. In this case, moving the hand to the keyboard to start typing gives the interaction just enough delay to miss the second, unnecessary focus.

I think a good assumption to have for all common interactions is that for some users, fingers are already on the keyboard and things can happen so much faster than you expect.

Not accounting for that, the creators of this flow inadvertently broke one of the cardinal rules. We talked about it in the context of mouse pointers before, but it applies as well to text: don’t move my cursor for me.

In response to my recent interactive essay about interactions, Waider on Mastodon posted a great crystallization of a common problem:

There is nothing quite so frustrating as a persistent user interface papercut. You know it’s there, but you keep running into it because the moment you start thinking about what you’re doing instead of how you’re doing it, that knowledge slides away until BAM you run into it again.

I think this is really nicely put and highlights about why it’s very important to care about this kind of stuff.

If you forgo a standard interaction out of carelessness, a bug, bad systems thinking, or for other reasons, you’re not just making your users frustrated by something not working. You’re also at risk of making them frustrated at themselves, assuming they can change what their fingers do easily, not fully knowing that a) this is motor memory, not just regular conscious actions (and any memory is hard to “update” intentionally), and b) motor memory is separated from regular, declarative memory, and not possible to reason with using the same techniques.

(As an example, it’s very hard when keyboard shortcuts or mouse gestures disagree between apps, because while you consciously might know which app you’re in, that’s not necessarily true of your fingers.)

Waider continues with an example:

The canonical example of this, for me, is Microsoft apps on macOS: even now, decades after Microsoft started producing macOS versions of their apps, they insist on largely disregarding the native UI idioms in favour of their own. Current pet hate is that if I’m commenting on a document, the Ctrl-A/Ctrl-E actions do not work, and boy howdy do I use those constantly.

My recent example is that even though I wrote about Safari overriding the natural “scroll to top/​bottom” tap gesture on their tabs – so I am aware of it in my declarative memory, I know Safari designers messed it up, and I know exactly what to do and not do – my fingers still occasionally tap to scroll in Safari anyway.

From Brad Woods, a messy (in a good way) and copiously illustrated/​animated exploration of “juice,” or:

Our wet little term for constant and bountiful user feedback. A juicy game element will bounce and wiggle and squirt and make a little noise when you touch it. A juicy game feels alive and responds to everything you do - tons of cascading action and response for minimal user input. It makes the player feel powerful and in control of the world, and it coaches them through the rules of the game by constantly letting them know on a per-interaction basis how they are doing.”

It’s mostly, but not exclusively videogame related, but it has some obvious tentacles reaching into the consumer and even professional UX world – at this point in Unsung’s history you all probably know I see these worlds as overlapping, hence linking to a lot of videogame interaction stuff.

Won’t be a surprise that I particularly liked the “level of juice” slider:

The whole page is messy, but that’s actually kind of great. It generously links to other things, too. I don’t agree with all the examples, but I the entire effort feels like it came from a person, and I really treasure that.

I also thought this notion was very clever:

There is a trend to juice rare events in non-game software. For example, an explosion of confetti to celebrate completing onboarding or a funny animated 404 page. Game developers do the opposite. They focus on the mundane, routine tasks. Because these are the foundation the rest of the software sits on.

(Brad Woods’s “Digital Garden” is generally worth checking out as a whole.)

There are tons of small bugs around. Occasionally, there is a really big one. In the “oh my god, I can’t believe it” category, here’s a story of the game Yakuza 6.

A few months ahead of launch, in February 2018, Sega released a free playable demo of the game. The demo gave access to the first level, and then blocked the progress with a barrier:

Somewhat unusually, the demo actually contained the entire game in a hefty 35GB+ download. The idea was apparently that after the game release and player’s purchase, they could “unlock” the game with a code and resume as if nothing happened, instead of downloading it separately and likely losing their progress. However, that made this barrier a pretty load-bearing one, as finding a way to circumvent it would mean people could play the entire game for free.

But before speedrunning hackers laid their hands on this challenge, it turned out no circumvention was even necessary – a bug in the game code itself made the barrier simply not appear on American PlayStation consoles.

Sega realized it quickly, pulled the demo, and blocked the installed copies via DRM, but not before some players got access to the complete game and finished more than the expected first chapter.

Alas, there was no public post mortem or an explanation; I’d love to understand what happened on a technical level. Either way, it’s wild trying to imagine the moment people at the company realized what they’ve done.

I thought about this the other day, and I thought it’d be fun to share this internal tool I made over a decade ago to aid with exploring options for Medium’s typographical redesign.

It’s called Fontificator. You can play with Fontificator here (desktop browsers only), or watch the likely confusing video below:

The motivation for building Fontificator came from two observations:

• font previews on type foundry sites were generally too limited to get a real sense of how a certain typeface feels, and it was best to see a font in situ,
• often an extremely tiny nuance – like adding some letter spacing, or messing with line height – was what separated something that was promising from something that seemed very far from working.

With Fontificator, I was aiming at this Doug Engelbart-esque notion of one hand on the keyboard + one hand on the mouse, and the UI where it was only necessary to point to an element, and the keys under your other hand would start working immediately – no clicking needed:

• F and G to change the font,
• – and + for font size,
• ← and → for letter spacing,
• ↑ and ↓ for line height,
• < and > for opacity (for all the above you can hold Shift for bigger moves),
• and, there are a few more shortcuts you can see at the top.

This way, we could move really, really fast. To accommodate that, Fontificator always tried to keep the current item under the cursor by counter-adjusting scroll position as needed.

On top of it all, a few more shortcuts:

• ⇥ and ⇧⇥ move very quickly between different types of stories so you can preview that,
• Space compares to the original/​current version,
• 1–9 allow you to switch to different “slots” so you can have various presets ready to compare,
• Esc hides the toolbar for maximum immersion,
• ⇧R resets.

You can also edit any text if you are so inclined, and also drag in any font file from your computer onto a paragraph – then that font becomes part of the F/G stack. (Bernino Sans and Freight Text were the starting fonts before the redesign.) On the left, you can also see a naïve mobile preview – there was also more sophisticated on-smartphone preview, but I removed it from this restored version.

Fontificator was literally made for an audience of 2–3 designers (and perhaps 1–2 stakeholders in read-only mode), and it was surprising to me how quickly one could master this strange tool, have fun with it, and feel the page’s typography becoming much more malleable. We also put up a more “traditional” list of contenders on the wall…

…but it was in Fontificator where we learned the most.

I love internal UIs because they allow you to go very wild and very tactical. If you have one you’d be willing to share (maybe it, too, is on the other side of the statute of limitations?), or one you already wrote about or spotted someone else doing so, please let me know!

The software company Panic has a blog, and has had it since 2009. It has a clean, modern aesthetic that looks something like that:

However, something interesting happens as you start going back in time by clicking Older Posts at the bottom – the historical posts are rendered using their original styling:

This isn’t something that happens for free, as with any redesign every piece of content gets ported to a new framework and style by default. So, I gather this was an intentional thing that also required extra effort both to make it work like this to begin with, and to allow the old style to appear nicely within the different confines and technical realities of the new style (you can compare the above screenshot of Firewatch announcement as retrieved today with its original appearance in the late 2015).

I love this effort. I wonder if more places on the web could use that kind of thinking. As an example: what if your social posts or blog posts from long ago came adorned with the same avatar that you used when posting them, even if you updated it many times since?

In game development, there is this strange effect known as “tunneling.” It happens when you do collision detection. Imagine a simple situation where every time you move a cube, you also test whether it touches the wall – and if it does, you make it bounce off of it.

This works great, but if you move and detect the collision less frequently, something weird can happen:

Here, the movement was so coarse that there was no point at which the cube touched the wall, so the collision wasn’t detected, and the cube passed cleanly through… as if it made a tunnel.

(You can play with this simulator yourself, by the way.)

The easy answer seems to be “well, run the collision detection more often then,” but… how often? And what if the entire game engine runs off of computer’s frame rate, which you are not in control of it at all? All in all, it’s not a trivial challenge, although various techniques exist to remedy it.

We talked before about another challenge with frame rate dependence. They’re not limited to games; for interfaces that are based on physics, they will rear their ugly head, too. But tunnelling happens in simpler UI situations as well. Here’s an example from Photoshop – I’m holding a button and if I drag slowly, each item will be toggled. But when I start moving fast…

Fortunately, the remedy here is much easier than in the complex world of videogame physics: just remember the last one touched, and toggle everything in between that and the current one.

On the tldraw blog, Steve Ruiz covers a slightly more complicated scenario where you do have to do some physics: an eraser in a drawing tool.

Pointer input isn’t continuous. The browser reports the pointer’s position as a series of discrete samples, and when you move fast, those samples can land far apart. Flick your wrist and two consecutive pointer events might be a hundred pixels from each other, with three small shapes sitting untouched in the gap between them.

A naive eraser asks “what’s under the pointer right now?” on every pointer event. At slow speeds that works fine. At high speeds it tunnels straight through anything that happens to fall between two samples, which is exactly when people use the eraser most aggressively: big, fast, careless swipes to clear a region.

Here’s Ruiz’s example of the eraser in FigJam, with heavy tunneling:

And here’s one in his drawing tool:

You can click through to learn more and see the algorithms, but either way it’s worth remembering: if it applies to your interactions, think about the “flyover states” and make sure to make things deterministic, regardless of whether the mouse is a tortoise, or a hare.

And, I liked Ruiz’s sentiment at the end:

[…] The decision to test segments instead of points is the difference between an eraser you can trust at speed and one that mysteriously leaves survivors behind. Users will never notice it working, and that’s the point.

A quick post from Paul Kafasis at the software company Rogue Amoeba, talking about making update notifications less annoying:

Though [the open source update framework] Sparkle serves us very well, it has one notable downside. Update announcements are most likely to appear at the least convenient time: right after you’ve launched the app.

With that in mind, we’re making changes to how update notifications appear throughout our apps. In the future, when the software’s timed automated check detects a newer version, it will no longer pop an obtrusive window like the one seen above.

Instead, a small “Update Available” indicator will be shown in the app’s interface. You can see it right here in Audio Hijack.

I first remember this approach from Chrome in the early 2010s. (If you know it from an earlier application, please reach out!)

The browser still uses it today, but the visual treatment was different early on; the update icon badge started with green, then yellow, eventually ending up red. While this resembles traffic lights the inspiration was, apparently, rotting fruit – you’d be more likely to want to clean up an old, stinky fruit than a fresh new one.

Here are, I believe, the first three visual treatments in Chrome, 2011-2013:

How effective was that treatment, I don’t know. (It definitely felt more thought through than the trash where the skeuomorphism undermined the function itself.) But it is all interesting to me in the larger context of the tensions underlying updates:

• It’s in a company’s best interest for every user to be on the latest version, since that saves on support headaches.
• A company needs to believe the newest version is the best ever – even if it’s not – similarly as our brains need to believe we are generally right most of the time, just so we can function.

That’s why I always appreciate the improvements that prioritize the user experience over the company’s.

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.

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.

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.

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!?

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.

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.

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.

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.