In my inbox, over the years, in no particular order:

From: YouTube Premium
Subject: YouTube Premium Individual plan price update
Email summary: The monthly price is increasing from $13.99 to $15.99.

From: 1Password
Subject: Important: We’re updating the cost of your subscription
Email summary: The annual price is increasing from $35.88 to $47.88.

From: GeoGuessr
Subject: Upcoming Change to Your GeoGuessr Subscription
Email summary: The monthly price is increasing from $4.99 to $6.99.

From: DreamHost
Subject: Upcoming DreamHost Price Change
Email summary: The monthly price is increasing from $13.99 to $16.99.

From: Printful
Subject: Product and shipping price updates
Email summary: Some prices and shipping rates are increasing.

The only two emails I could find that were actually honest about the price going up in the subject line, instead of obfuscating it with terms like “change” or “update,” were Apple’s and Panic’s.

The former had a subject “Your Subscription Price Increase,” and looked like this:

The latter was titled “Playdate’s price is about to go up a bit” and looked like this:

Also note both telling you what the previous price was.

I spent most daylight hours yesterday driving in torrential rains in pretty bad visibility, and I was astonished how many cars didn’t have their lights on.

It looked something like this. The cars with tail lights on were somewhat visible, but the cars without them didn’t stand a chance:

Some drivers definitely lacked enough imagination to turn on their lights. But even though I knew to do that, I struggled, too – my rental car light interface felt so opaque that I almost chose to drive with the wrong lights on. And it all had to do with iconography.

Cars have two main settings for lights:

• “regular driving,” meant to be used at night and during limited visibility – like in heavy rains,
• “parking,” where front lights are less prominent, meant to only be used when stopped.

The UI for lights seems to typically look like this:

Without knowing, can you figure out which setting is which?

The left icon with two lights facing away from each other means the parking lights. The far-right icon with one light pointing slightly down (“low beams”) is regular driving lights. The latter is the right thing to do in the rain, but the assignment feels kind of arbitrary to me, and I could totally see the icons going the other way.

Also, the above is a somewhat gentle situation. In my car, the lights were on a stalk, and the setup looked more like this:

Here:

• the lightbulb on the left is a meta indicator for “this is the main light setting” (you can see it above too, on the dial),
• the middle part with the wavy line is fog lights,
• the arrow-heavy thing on the right informs of two things: pull on the stalk for high beams (another mode), or rotate the stalk left or right for turn signals.

That’s a lot of stuff going on, and many similar icons that do not appear immediately understandable. The whole interface seems optimized for motor memory, but harder to approach at first.

In both modes, the feedback from inside the car is exactly the same – you see the interior dashboards illuminate, and the front lights go up. At night, you might spot the difference in the front light intensity. But in the daytime rain, it’s less likely – especially if it’s a rare intense rain you don’t encounter often.

(Many cars have an AUTO option now, but I wasn’t sure I could trust it, and if it would properly account for the rain reducing a lot of visibility.)

Lost perhaps amidst the recent conversations about icons in menus and app icons was another subtle change: Apple started embracing more iconography on buttons, too.

You can see it on keyboards, where the U.S. models followed in the footsteps of international ones, now showing symbols instead of legends for Tab, Caps Lock, Shift, Fn, Enter, Return, and Delete. Here’s the previous generation and the 2026 one:

The shift also happened on screens. Below are examples from the last three versions of iOS (18, 26, and 27), side by side.

When starting a new note, it’s not just the keyboard’s ↵ that replaced Return. The back icon also lost its legend, and Done became a checkmark:

Here might be the best case scenario, with Cancel and Done swapped with icons:

In this AirDrop screen, Done became a close box:

Elsewhere, Cancel morphed into ×, in an unfortunate position next to a different ×. Plus, Search on the keyboard became a loupe:

When screenshotting, Done was splintered into a checkmark and an ×:

And here, Done transformed into a checkmark, while Edit became a new kind of a paint icon:

Seeing all this, I was reminded of this old post from Dmitry Fadeyev, titled “False simplicity”:

Sometimes, what appears on the surface to be simple is actually far from it. For example, there’s a trend in Twitter clients to use icons instead of text labels for buttons. Just icons, no text at all. These icons don’t take much space, look elegant and maintain that simple feel of Twitter, except…they’re actually just confusing.

Fadeyev also quoted Jef Raskin’s take on icons:

In every study that considered the question, icons were demonstrated to be more difficult to understand than were labels, especially at first viewing, which contradicts one of the most frequently cited reasons for using icons, namely, comprehensibility for beginners. […] Although it is true that tiny icons can take less screen space than labels, you have to ask: At what cost? The smaller a button, the longer it takes to operate it, and the more difficult it is to find; also, it is difficult to make a small icon distinctive.

I like that take.

Here’s my personal go-to cheat sheet when it comes to iconography:

• icons are compact, allowing you to squeeze in “more UI,”
• people probably understand only a few icons (close box, checkmark, plus, some chevrons), and can learn others – but the learning process will be harder than you think,
• many icons are never understood, but people can still to some extent use them without ever understanding them,
• icons can break the monotony of an all-text interface,
• well-made icons make the interface look more attractive in a way type can’t.

I don’t believe Apple is doing it all just for aesthetical reasons. My guess is that it’s more about the first bullet point above: liquid glass added so much chrome and padding that Apple simply ran out of room for text labels encased in glass.

At the first glance, Apple is avoiding the car light problem by using popular icons. However, there’s a new challenge: most of these icons are too popular, and overloaded with meaning:

• checkmark: “commit” or “to do item/​checkbox”?
• ×: “close” or “clear”?
• loupe: “search” or “zoom”?

The only outlier is the edit icon, relatively new and likely unknown. With the extra challenge that on-hover tooltips don’t exist on touch devices, the way forward would be to use the paint icon consistently to teach it to people, but it seems Apple isn’t yet doing a great job at that. The below screenshots are all iOS 27, where you can see the leftover Cancel and Done labels in place, and a missed opportunity to put the new edit icon next to Customize to help people connect the concepts:

I wish I could peek inside Apple to see how these efforts are faring, and what’s in store.

To go back to keyboards, I am curious why Apple didn’t consistently apply text and icons for all the affected keys, like they did for the bottom row a while back. Here there was enough room:

And how could we solve the car problem, if we think iconography makes it harder for less experienced drivers? I could imagine a similar idea here as well:

But the funny thing is that most modern cars have a digital dashboard, so for the first time, tooltips are an option. You could imagine turning the stalk and seeing this kind of a message appear for a few seconds, the description and the icon side by side to help the user connect one to the other:

Of course, introducing a tooltip means “now you have two problems.” And, we might be attacking the symptoms here – the real reason might be a complex system underneath, whose complexity is relayed to the user without any translation. Or, perhaps the icons themselves could be changed to better represent “parking” and “driving.” But let’s save all those for future posts.

This post has been edited after I originally confused a few light modes.

In the 1990s, users of some Unix-based operating systems would sometimes see a peculiar error. It happened occasionally when sending an email to a person you might have already sent email to before, and in addition to the error being confusing, the message itself was particularly bewildering.

Let’s say you wanted to send an email to “MWichary.” Instead of a confirmation, you would see this:

550 mwichary... User unknown: Not a typewriter

As many strange errors tend to be, this one was at an intersection of four different things.

The cause of the error was something many of you will recognize – code being anal about lower- and uppercase. Behind the scenes, a piece of software called sendmail always assumed lowercase user names, which was true early on. “MWichary” was quietly changed to “mwichary” – a user that didn’t exist – and the program reported the literal outcome, instead of its chain of reasoning.

The second part was a sort of a meta-error in the error handling routine. Sendmail correctly reported back “User unknown,” but then reflexively added whatever the system error value reported, for extra debugging color. These are usually helpful, reporting things like “Host is down” or “No space left of device” – I bet you’ve seen some of the very distinctive strings if you ever did anything adventurous in the terminal.

In this particular context, however, the system error was pretty useless. “Not a typewriter” meant basically “this is a program being run in the background; it’s not meant to accept any user input or write anything for the user to read.” It’s not an error as much as a condition, and is true for a lot of programs quietly doing the operating system’s bidding.

But… why was the message phrased this way?

That’s just history. Computers were originally connected to typewriters as input/​output. Some of these typewriters were local, attached to the front panel, or console. Others were remote typewriters, or teletypewriters, often shortened to teletype or even tty. If you recognize these terms, that’s because they are still with us today!

You can see how “This doesn’t have input/​output I can do something with” can become a terse “Not a typewriter” in an era when every character feels costly, and a typewriter is your only option for input and output. Then, the string was simply kept a few decades too long, even after typewriters were replaced by teletypes, terminals with screens, and eventually Terminal and Console apps.

The fourth piece was fun with grammar: the simple choice of joining the two messages by a colon made it feel like the user was supposed to be a typewriter.

The message was eventually renamed. If you encounter it today, it will say “Inappropriate ioctl for device,” which I guess is an improvement. But its code remains ENOTTY.

It’s entirely possible it will still be named that decades from now, even after we all forget what typewriters were.

The title of the post comes from the explanation in the manual for the Solaris operating system.

An 11-minute video from MattKC documenting huge effort to revive a backup tape from a 2000 game Frogger 2: Swampy’s Revenge:

This is a pretty harrowing story of restoration, including an extremely obscure backup tape made by a short-lived Dutch company, attempts to reverse engineer a poorly documented data format, a data recovery company that damaged the tape instead of restoring it, and a mad hack to trick the drive into reading it anyway.

A good video from Linus Boman about clip art, most (in)famous from Microsoft Office, and specifically PowerPoint of the 1990s–2000s:

Turns out clip art is a lot older than I expected, and… it also never fully went away. On top of that, Boman covers a lot of aspects – from quality and perception, through the “user interface” of clip art, to how the means of conversion and reproduction changed it forever. I also loved the little “sidebars” in the video.

Even if you don’t care about clip art per se, a lot of the threads in the video will be relevant to things like shadcn, Inter, Google Fonts, Canva, The Noun Project, the Claude aesthetic, and so on.

Also relevant: Internet Archive’s MS Clipart Search.

On the most recent episode of the Waveform podcast, the hosts talk about two new announcements in the MMORPG world (relevant bit starts at 1:21 and goes on for 14 minutes):

The context is this:

• RuneScape launched in 2001, and World of WarCraft in 2004,
• each game already had a “relaunch”: RuneScape via Old School RuneScape in 2013, and World of WarCraft with its Classic edition in 2019 – both revisiting and perhaps straight replaying the respective original game, but with some new improvements.

The new announcements are yet another revisit for each universe:

• RuneScape announced RuneScape 4 – an old game engine but with more modern graphics,
• World of WarCraft announced World of WarCraft: Forever, which feels like a cross between “reboot” and “rewind” – going back to the original, but creating brand new events and universes within.

I haven’t played either game, but the segment made me think: why have we never seen non-game software do this kind of stuff? I can think of multiple reasons, but at the same time I am surprised I can’t come up with even just one example of a software company doing something similar – I mean, rewinding the clock – with one of their bloated apps.

We have seen companies reboot their software – the most (in)famous examples in recent times I can think of would be Apple’s iMovie ’08 and Final Cut Pro X, Sonos software refresh in 2024, and Digg redesign in 2010 – but that feels different. Of course, time and again, we also see competition take another crack at a problem and steal the market from an incumbent afraid to cannibalize itself, but that’s also a different thing.

In a post not long ago, I wrote:

I think that kind of push and pull is important, especially today. I don’t love using Google Sheets, but my favourite spreadsheet is not Excel 97, either. My favourite spreadsheet is some hypothetical anachronistic version of Excel 97 that also has modern high-dpi typography, and a ⌘K command palette, and today’s trackpad gestures, and support for AVIF and HEIC.

…and I still think I would love to see “Excel 97 Revisited” today. But I’m not sure I’ve ever seen anything like it.

Please let me know if I am missing something obvious!

À propos the last post, from music editor Marc Weidenbaum:

The first is don’t let anyone or anything, or anything acting like anyone, or anyone promoting anything, convince you that craft is outdated or will ever be outdated; you will only improve, only make the sounds you imagine in your mind’s ear and feel in yourself, by working steadily to achieve them. Also recognize that expected paths lead to unlikely ends the more patiently and curiously, guided by instinct and experience, you walk those paths. There is always an excuse to not put in the work. If you allow “AI” (I put it in quotes because it’s less a specific thing, in this context, than what is often cast as, to borrow a historical term, a specter) to become that excuse, well, it’s unfortunate, but there would have been other excuses. So, the best thing to do is put the threat you may perceive from AI in a tidy little box full of all those other excuses, don’t distinguish it from them, and get to work. […]

I’ll close now as I opened, with the bad news. These two suggestions, you may have noted, have something in common: they don’t happen instantly, at the push of a button. They take time. Put in the time.

Quote discovered via Robin Sloan’s newsletter.

I linked to his work before, and here’s The Art Of Storytelling with another interesting video – about what made Jobs such a good presenter:

I’m not going to spoil the findings, which are presented well with good corroborating examples. But the most interesting thing to me was one short video snippet of Jobs being visibly nervous before a very early, 1978 presentation:

It made me think about other examples of Jobs being off his presenting game.

The most well-known one is likely the 2005 announcement of the “iTunes phone,” or Motorola ROKR E1, just over a year before the iPhone. It’s a really painful watch, seeing Jobs squint at the sort of interface he usually makes fun of, regretting the whole deal, very aware of the smartphone they themselves are working on, but unable to speak about it yet (the relevant part starts at 17:24):

But I have another, trickier suggestion: the “Antennagate” presentation of 2010, where Apple had to do damage control over the issue of the iPhone 4 losing cell signal when gripped a certain way:

Now, this isn’t a bad presentation. I actually think it is a great one. The arguments are valid, the data solid, and the whole thing comes together well. In the recently leaked and generally rarely witnessed slide-less Q&A portion, Jobs displays understanding of the issue and answers questions well; perhaps I’m grading on a curve here, but even his one moment of anger/​frustration seems so much better handled than the famously impatient and immature Jobs would have done earlier in his career.

Both videos are worth studying and teach how to do damage control well, and how to tell stories of things you would otherwise choose never to talk about.

But also, early on, it was really fascinating to see Jobs reading off of so many generic, cheap-looking slides with literal sentence fragments, breaking the “show, don’t tell” rule, and – I think – generally using the slides as a crutch walking him through the narrative. It really took me aback because I don’t ever remember Jobs doing that as prominently.

It makes sense. Jobs had to rush back to work from vacation, and the time to put this all together was very limited. I don’t mean necessarily to pick on anyone here, but rather find in all this a confirmation of a universal truth. Sure, Jobs was smart and had a lot of charisma on stage. But in the end, at some point, slides are just like any other kind of craft. You design the slides, you revise them, you practice, you let the practice influence the content, you get feedback, you kill your darlings, you revise again, and repeat all that so many times you get sick of it all.

It’s clear to me that the team here ran out of time for this, and there’s something comforting in the fact that even Jobs couldn’t wing it, and still had to put in the work.

My favourite piece of writing I’ve done about motor memory remains “Shift + Shift” from 2018. I have linked to it over the years, but if you haven’t checked it out yet, you might find it interesting.

Just this week, I have had another similar moment, and amazing in a slightly new way.

How many of you tap ⌘1, ⌘2, ⌘3 to switch between tabs? This convention has been there for as long as I remember, and so has been my fingers’s embrace of it. The system works in Chrome and Safari, in the Terminal (and Ghostty, which even shows the shortcuts on tabs themselves), in Nova, in Figma, and presumably tons of other places:

(Just about the only place where it doesn’t work is the Finder, and that’s only because ⌘1/2/3 keys there were first assigned to switching the view style – icons, list, column view – some time in the early 2000s, some years before the tabs came. Hard to change a shortcut people are already used to; luckily, I personally don’t use tabs in Finder.)

At this point, I press ⌘1 and ⌘2 and ⌘3 without thinking, just as instinctively as I would ⌘Z for undo, or ⌘C for copy.

So instinctively, in fact, that last week I was looking at Messages, I wanted to switch to the group chat, and my fingers just reached for ⌘1:

I have never done it before. I have not heard this was possible, nor seen it announced in the menu, or a tooltip, or via onboarding. I didn’t even think about it. My fingers just… did it. Completely on their own.

And it worked.

I was just there, looking at my hand amazed, piecing together what just happened as if I were watching someone else’s actions.

It’s funny to pause and think about such a seemingly tiny thing. After all, this happens all the time. Every time I slam Esc to dismiss a dialog I never closed before, every time I press ⌘V to paste something in a new location, every time I tab from one field to another in an app I just installed – sure, these might be system defaults in various places, but I see them break once in a while; when they do work someone might deserve credit for wiring them properly, even if I take it for granted.

In these moments, you only notice things going badly; as a matter of fact on the same day I pasted some bolded text into the very same Messages app, and tried to press ⌘B to undo the bolding – and that didn’t work.

And I think that’s why that ⌘1 in Messages is worth a little celebration. Over the years, enough apps and websites and operating systems quietly decided to spend extra effort to participate in the ⌘123 convention, together building a dependable interaction system that more and more people’s motor memories could learn to trust over time.

That included mine, including one extra thing that separates it from the story I linked in the first paragraph – and one you probably already noticed.

The Messages app doesn’t have tabs. My motor memory kicking in wasn’t just a recall of something that I’ve already done before. Somehow, in my brain, this convention felt so great that it quietly extended from “⌘1 = first tab” to “⌘1 = first content thingy,” without me even realizing.

And that’s so amazing, right? It’s stuff like this why I keep harping on Safari’s problematic tabs and other compromised interaction systems, and that’s why today I raise a small toast to the designer at Apple who thought about ⌘1 in such a clever way.

Nice moment in iOS: when you reduce the volume to zero, subtitles come up automatically – and they go away the moment you increase the volume again.

This is from YouTube on the iPad, but it appears to be system-wide:

(Feels extra meaningful in the face of so many people playing their media on speaker in public these days.)

Here’s what happens when you try to update your Android phone if it’s low on battery (even if it’s connected to a charger):

It’s a pretty cheap error UI, a misaligned string thrown carelessly in between existing interface pieces. It doesn’t even bother explaining what “too low” means.

Compare this to what the Playdate does in the same situation:

If the device battery is depleted, the software simply charges if first to the necessary minimum (spelled out on screen), before automatically proceeding to the actual update – all without any user intervention.

We previously talked about fire-and-forget states, or interfaces which give you confidence that once the process starts, it will finish on its own. (If you don’t like military references, we could call these tap-and-walk-away.)

This is a really good example. There is even a nice corresponding version for when your Playdate needs to be plugged in first:

Once you do, the process again continues by itself right until the end.

At the end of the previous post in this unexpected series about iOS Safari’s tab control design, I wrote:

This is how interaction systems slowly fall apart. […] It is likely that Safari’s exception will now be treated as “blessed,” and start spreading further. Given enough time, more and more pills will go in whatever direction they want when dragged – and people will learn not to trust any of them.

I didn’t quite get this right, as it seems this has already happened. It might have been Safari that used a “blessed” interaction from elsewhere. Conversations with a few readers helped me piece together a larger story of how we got here. I fired off some of my old iPhones and emulators to verify them, and so let’s go back in time all the way to 2007.

Step 1: These rotary controls for timers have been here since the first iPhone. Note how you drag the background, not the selection, but that works because the background is styled as a physical object, you see the options extending in both directions, and the selection remains fixed in place.

Step 2: In iOS 7 in 2013, the camera app adopts a similar treatment, but on a horizontal plane. This is roughly as above, flattened, but with the background still extending in both directions, showing adjacent options. This also made some skeuomorphic sense because this control is very “mechanical” – you could imagine such a wheel on a real-life camera.

Step 3: In 2023, Safari follows in those footsteps for its tab groups (which originally was a more traditional menu). It might have felt like the right thing to reuse, but the control doesn’t feel as refined as the Camera’s. It also introduces the problems where tapping no longer scrolls to the initial position (mentioned in part 1) and the too-eager tab group creation overflow (mentioned in part 2).

Step 4: This is where the trouble begins. Camera gets redesigned for iOS 26 and liquid glass. The team decides to rearrange and simplify the control visually, but at a price of making the interactions feel more complex: there are now only two items visible by default (the background doesn’t extend to hint at other options in its resting state), the current selection no longer stays in place, and the control generally suggests tab-like interactions but doesn’t provide them.

Step 5: At some point in the beta process, the Camera team perhaps realizes the same thing I found challenging in part 2 – these now look like pills, and elsewhere the system taught us finger drag moves pills rather than the background. In iOS 26 beta 4, the direction is reversed compared to all previous versions of the app.

Step 6: Seemingly almost immediately, people complain, since many years of motor memory are now compromised. So, in beta 5, Apple adds a setting called “classic mode switching” – similar to natural scrolling years before, on macOS side.

Step 7: However, not long after that, in beta 6, Apple removes the setting and reverts to the original direction from steps 3–4.

Things that come to my mind:

• Inverting the control to go the other way in step 5 was where the consequences of previous steps reared their ugly head. I imagine perhaps the strength of complaints surprised Apple, which found itself without a backup plan, between the rock and a hard place: earning either the immediate ire of power users (whose motor memory was disrespected) or the future ire of other users (who will experience no consistency between pilled controls going forward).
• Adding a setting would be kicking the can down the road, but so is – as I hoped to establish in part 2 – leaving things as they are: There’s still a systemic problem where controls in Camera and Safari are now at odds with other pilled controls.
• What makes a control a control is not paper principles, but a collection of details working together. Removing the extended background, restyling the control, and making the selection no longer stay in place might feel like small changes in isolation, but at some point Theseus would like a word. I see this sometimes in other surfaces, where individual UX changes compound over time, become basically dead reckoning, and result in a boiled frog.
• I wonder if Apple succumbed somewhat to the “dumb consistency” problem: often it’s better to be inconsistent in a smart way than consistent in a dumb way. It might feel good for all the tabs and the pills and the toggles to look the same visually, but that feels like dumb consistency if they behave differently. It might seem good for Safari to reuse Camera’s toggle, but the Camera is generally a one-of-a-kind, bespoke app, so it has some leeway here. Safari doesn’t really get to play by those rules.
• I am curious why the Camera team didn’t invert the direction and the ordering of things. In this case, two wrongs would make a right, and this would keep the motor memory intact. (I imagine the reason is that this would trip up people who remembered things cerebrally, rather than “in their fingers.”)
• I feel the team wasn’t given or didn’t give itself enough time, which jibes with how unpolished the entire liquid glass effort was in its first year. In a perfect world, the camera control would probably have been redesigned again before launch to avoid tricking the motor memory – or perhaps the whole original iOS 26 change reverted.

That’s Camera. Where’s Safari in all that? Just where it started: Safari’s control today again seems just like a cheaper, more hurried, less thoughtful version of what Camera does. The Camera toggle doesn’t have the jarring “swipe to the left to create a new space” flow, doesn’t need to support tap to top, shows you the background affordance more readily, uses haptics, feels less buggy, and even only allows you to swipe one notch at a time, so the control feels precise and never runs away from you.

In the just-released iOS 27, the Camera is even slightly improved – it again shows more of its surroundings even before any swipes.

I haven’t noticed any updates to the Safari control.

The story of this entire system now appears to be this:

• The Camera team made mistakes that could have been avoided; changes to deep motor memory do take years and have to be planned and approached with patience.
• The Safari tabs have been drafting behind the Camera tabs, but still introducing smaller mistakes of their own: continuing to prioritize strange interactions in lieu of intuitive ones, and forgoing some of the nuance.
• Both look like pills and, when dragged, go in the opposite direction as other pills in the system.

In all these screengrabs, I’m dragging my finger to the right:

I don’t, of course, know all the details, and I realize I am harsh in my assessment. I sympathize with the depth of the challenge not just for the team – motor memory can be brutal, and established interaction systems are really hard to evolve – but also in coordinating with other teams in a closed-off culture like Apple’s.

Then again, these are iPhone’s top-tier surfaces so I think it’s fair to expect excellence, and this is also not the first time Safari team has made some puzzling design choices. Perhaps most importantly, Apple is also the platform owner and they set the tone for other apps, which we’ve seen recently in their indirect influence over CleanShot’s settings.

I hope you found some interesting things in this long post. As a reminder why it all matters, and why protecting systems of interactions like tap to top (part 1), or slide on an object to move it in a predictable way (part 2) is important, this is a quote from one of the readers:

It’s actually worse [in Camera], because often you are in a bit of a hurry to take a picture and it behaving unexpectedly is the last thing you need. I had this once or twice: suddenly it was in video mode and by the time I had it back in regular photo mode, the train I was trying to photograph was long gone.

I’ll be curious if we see more evolution of these spaces, and hopeful Apple resolves the problems. But now, I’m ready to stop talking about Safari’s tabs for a while.

Thank you to Nikita Prokopov, Daniel Dickison, Jeremy Kanter, and Martin Hoffman.

I started GUIdebook in 2003, and last updated it exactly twenty years ago.

It’s an interesting time capsule itself now, incompatible with mobile reading and sporting an aged design. I have kept it up because it’s apparently used as a reference in various user interface courses, and if you haven’t seen it, it could be a fun browse.

I walked away from it by accident, distracted by a new job, but I always wanted to evolve it into something better as my storytelling skills and my interactive skills grew.

Unsung is GUIdebook’s cousin, of course, especially in pieces like Lisa’s copy (and cut, and paste), Were Touch Bar’s problems software rather than hardware?, and even little things like Anachronisms.

But the direct preview of what I dreamt GUIdebook of becoming was in my last year’s interactive piece Frame of preference. It’s a history of the first twenty years of Mac interfaces told through its settings, it has a proper narrative (I never got to it with GUIdebook), and instead of screenshots, it uses Infinite Mac’s technology to tell the stories via emulation. I’m pretty proud of how it turned out, and you might enjoy it if you haven’t seen it yet.

I would love to try a few more things like it.

But, back to GUIdebook. Keeping it alive for 20 years required multiple updates as PHP evolved, and a more recent rewrite that ditched easily-hackable PHP altogether. (Don’t ask me how I know it’s easily hackable.) None of these were particularly noticeable on the surface, but I recently added one tiny user-visible change – the screenshots are now properly pixellated:

It was fun – and slightly eerie – to update the site’s history page two decades after I touched it last.

Speaking of string interpolation, I loved this recurring gag in BoJack Horseman:

The (un)installation bug from the previous post was an overeager directory delete, but a more common problem I’ve seen is this one. Here’s an example from iTunes 2.0:

The installer tries to erase a previous version of iTunes using (with root privileges) the rm -rf command. However it doesn’t take into account that volume names can contain spaces. […]

When the diskname (partition name) starts with a space the following happens:
rm -rf /Volumes/ harddiskname/iTunes.app 2> /dev/null

So rm removes /Volumes (all mount points!) and a nonexistent path harddiskname/iTunes.app, but no errors are displayed because they are /dev/​nulled.

And a very similar thing a decade later, from Steam’s Linux installer:

I launched Steam. It did not launch, it offered to let me browse, and still could not find it when I pointed to the new location. Steam crashed. I restarted it.

It re-installed itself and everything looked great. Until I looked and saw that steam had apparently deleted everything owned by my user recursively from the root directory. Including my 3TB external drive I back everything up to that was mounted under /media.

The culprit was identified by another user a few messages down:

rm -rf "$STEAMROOT/"* could be evaluated as rm -rf "/"* if $STEAMROOT is empty

These are the sort of classic user-generated content meets string concatenation/​interpolation bugs that haunt engineers’s dreams.

The solution: If a user gives you a string, you have to wrap it as safely as possible so that it could never break apart into pieces in transit.

So you wrap the path with quotation marks. (I believe you can actually do this everywhere in Linux – cd "/usr/local" will work as well as cd /usr/local – except no one ever does so as it’s quite annoying.) But then, a string with quotation marks would escape containment, so you have to escape those by changing " to \". And then, naturally, you also have to escape any freefloating backslashes to \\.

Of course, there are usually functions that take care of all of the above; you just have to remember to use them, as well as think about the edge cases like a variable being empty to begin with.

This all is a distant version of SQL injection – perhaps most well-known from this XKCD comic – and a more modern prompt injection. There’s even a version of it in UI design:

Here, the wrapping isn’t for security reasons, but to help people understand where the command ends and the string begins. But this introduces a new challenge, as any type of visual wrapping – quotation marks, bolding, italicization – can draw undue attention to the string itself. So, sometimes you just leave it be and hope for the best:

But let’s go back to the installation issues. I bet there are were tons more string interpolation and escaping bugs that we simply never learned about. Yet, as users of a project called Bumblebee learned in 2011, nothing beats the destructive power of a simple typo.

The best way to start here is with the summary of the fix to the bug, because that is the best encapsulation of the story:

Yeah, you read it right.

Here’s the original bug report:

An extra space at line 351:
rm -rf /usr /lib/nvidia-current/xorg/xorg
causes the install.sh script to do an rm -rf on the /usr directory for people installing in ubuntu.

Totally uncool dude!!! The script deletes everything under /usr. I just had to reinstall linux on my pc to recover.

Removing the space will fix this. Probably should do it quickly!!!

Reader, the bug was fixed quickly.

I mentioned David J. Ross’s work more abstractly before, but here’s a great example of a good font announcement: Slight Chance Stencil.

It’s interesting, teaches you new things, clearly talks about and shows its inspirations, and is free of the sort of bloviating, pretentious, nutrition-free language that often accompanies typeface reveals.

At first, I thought I was going to get creative with the positions and angles of the stencil “bridges” that traverse the letterforms. I tried fun diagonal bridges like the ones pictured below, but I found that the fancier I got, the more distracting the gaps became. And it was important to me that the design didn’t feel too clever or self-aware.

So after much experimentation, I ended up sticking with vertical bridges for the vast majority of shapes. (A handful of diagonal bridges are stashed in an OpenType Stylistic Set.)

While Nickel Stencil shifts them to the left or right to reduce the clutter of horizontal branches, Slight Chance’s bridges mostly run right down the center, leaving branches on both sides…it’s more clutter, but it’s also more corners to make soft and worn.

I happily made exceptions when this approach left a distractingly short fragment. Sometimes I shifted the bridge to one side or another (see crossbars like B and a), sometimes I used a diagonal bridge (see K and A), and sometimes I used a horizontal bridge (see T and t).

Plus, the typeface and its origins are really cool.

Marques Brownlee published a video commenting on YouTube’s just-announced A:B testing feature. In short, for some creators, it will be possible to publish slightly different versions of the video at launch time to different parts of their audience, if those versions are deemed “close enough” to the original.

Brownlee digs into how confusing this feature might be in actual use for viewers, never sure whether they’re watching, commenting, or rewatching the same video as others see, or even as themselves earlier saw. Toward the end of the video, Brownlee shifts his focus toward other YouTubers, with a monologue that I wanted to quote here because it captures something important:

You know, this is being framed as a tool to help you improve your videos. But I think for 99.9% of creators – well, to be literal, it’s not actually helping you make better videos; it’s helping you find which version of your video has the best retention, which doesn’t necessarily mean it’s a better video – hot take.

And there are so many examples of creative decisions that I have made, and that so many others have made in the video creation process, that are definitely not the best retention-optimized decisions, but they’re fun, and creative, and interesting, and new, and entertaining, and characterful.

So there’s always going to be the top 0.1% of channels that are all about mass appeal, and that’s fine. But last time I checked, a lot of what makes YouTube fun is the stuff that is more niche down, that is not mass appeal by definition. It’s the cool small hobby you found, or it’s the fun, unique thing that you just discover that only a few people are talking about that – that stuff! That’s what makes it fun.

I think if a lot of those channels and videos suddenly became like superoptimized, retention-maxing, and everything, those would get a lot less fun to watch. And so imagine if all the feedback anyone ever listened to was just to have the best retention – as you optimize over and over and over again, you start to trim out all of the other creative stuff that happens to not be the most efficient way to tell a story.

So I guess what I’m trying to say is... the skill of being a video creator on YouTube is not always necessarily about the maxed out, most efficient, optimized way to do everything, but it’s to find creative ways to share something, or teach something, or explore or explain something, or review something. So I just think making and finishing and publishing a bunch of videos is a better use of a creator’s time than making one thing and then, you know, a whole bunch of different drafts of titles, and thumbnails, and different cuts of the video to try to optimize for, like, the last few percent. […]

That’s all. I think just stand by your creative choices. You made this video, this is the video you chose to make. And now you get to share it, and you put it out, and you learn from it. […] That’s the creative process. Have conviction in what you want to share with the world.

There is another half-pulled-on thread in his video: Brownlee doesn’t say it directly, but dances around the idea that the very fact this feature was launched is reflecting on YouTube’s own insecurity as a product. Jim Nielsen follows up on that on his blog:

I find it interesting how Brownlee shares his opinion that YouTube spends way too much time chasing their competitors and not enough time being YouTube.

Which, when you think about it, is exactly the kind of place a feature like this would stem from: an insecurity in your own creative choices. How YouTube approaches its own insecurities is now trickling down as a feature to its users.

“Let’s let people make lots of variations on things, try all of them, and see what performs best” is exactly the kind of thinking you get in a platform that doesn’t know what it wants to be. So it’s left spending its time 1) doing what others are doing, and 2) following the fickle whims of whatever it can measure.

Brownlee talks a lot about YouTube videos being “fun, and creative, and interesting, and new, and entertaining, and characterful.” Those might not be the most important adjectives to apply to all of software, of course, but there are some interesting throughlines here. I have also personally not seen a lot of thoughtful A:B testing in my career. I think those are an easy way to lose yourself, to have your app become a bundle of metrics that everyone obeys, but no one understands, and – once you open the door to being driven by poorly-understood experiments – for the desire to fall back on patterns from other successful apps, without reflection, to grow stronger and stronger.

That’s how you end up with stuff Nielsen and perhaps even Brownlee argue YouTube itself has become: a set of Brownian reactions, or a warmed-over software cosmic latte, if you will. From my perspective, this often also leads to systems of interactions or features that don’t come together well to the user, as you end up borrowing from other places without the necessary hard work of translating them to feel at home and consistent with your system and its quirks and conventions. From what I’ve seen in my career, A:B tests do not promote design execution rigor. The tests are meant to be light by definition, since a lot of them are expected to fail. Before the test, there is limited incentive to invest in quality, but neither there is one after the test – if A or B successfully raises a metric, you don’t want to mess with it then, since what if you change the very thing that made it “work”?

On top of all that, we can add what Brownlee started with in his video: overeager A:B tests feel like software’s version of gaslighting. How can you trust an app if it feels like it’s changing without rhyme and reason seemingly on a weekly basis, whose changes are not announced or documented anywhere (small A:B tests never are), and when other people don’t see the things you see?

1.

One day, as I was reading an essay on Medium, I saw an automatically inserted subscribe block:

But as I was exactly on top of it, a new thing popped in my view, an interruption on top of interruption, both saying the exact same thing:

2.

For a while now, whenever I try to follow a link to a site that no longer exists, Chrome shows a strange “This site doesn’t support a secure connection” flyout, just before hiding it itself, and then following it by a generic error page:

This feels truly eerie: either a bug where the flyout gets triggered too soon without having all the information, or the flyout is trying to warn you about Chrome’s very own internal page.

3.

Just this week, after already having been in Taiwan for five days, and after having used Apple Pay to pay for public many times on each of these days, Apple Maps helpfully told me that I can… use Apple Pay to pay for public transit:

4.

Some months ago, after finalizing my car reservation and moving my attention elsewhere, an automatic “keep the session warm or lose it” window appeared, suggesting my reservation might actually “expire”:

5.

Downloading is possible on YouTube Premium and actually helpful, allowing you to load up some videos ahead of a long flight. There even exists a section where it suggests some things to download.

However, download suggestions include member-only videos, and whenever you try to grab one of those, you get this result – a pretty poor “Video wasn’t downloaded” message:

6.

When I recently opened a dispute on PayPal for a keyboard I never received, at the end of the process, I saw these three screens in succession:

In effect the screens said, in order: we closed the case and decided in your favour, you haven’t finished filing the case, the case is open and we’ll update you.

7.

I feel uneasy bundling all these “the left hand doesn’t know what the right hand is doing” examples, because they’re not all the same.

Examples #1–3 from Medium, Chrome, and Apple Maps are frustrating and somewhat embarrassing, outbursts from badly-behaving software that doesn’t know that it’s not okay to throw pop-ups at the screen whenever you feel like it. I particularly dislike announcements of features that the user has already been using since they feel condescending to me, but I don’t want to assume it’ll be the same for everyone else.

Examples #4–6, however, are more insidious. Whether they happen because of plain old carelessness, or lack of imagination, or Conway’s Law – different teams not talking to each other – they can lead to people jumping to wrong conclusions or building entirely wrong mental models. Is my reservation truly done, or have I not actually finalized it? Is it possible to download member-only content, except I need to do something special to set it up? What is the status of my PayPal dispute?

The answers in this case: yes + no + the first screen was the one telling the truth. But each answer required extra effort for me to figure out, and that effort would be avoided if only someone tested the flows better.

Continuing the theme of software fixes for hardware problems, here’s an essay I wrote in 2016 about a broken computer display that I “fixed” as a teenager, just because I wanted to play Civilization.

It remains one of my favourite things I’ve ever written.

In my recent visits to German and Polish museums, I noticed a recurring theme: modular industrial dashboards, which I imagine have by now been all replaced by software.

I don’t know much about these – please write me if you do – but I wanted to share them anyway, perhaps for context, or amusement, or inspiration. They’re interesting design systems, and interesting interaction systems as well.

This was a very cool physical display for air traffic control, at the The Deutsches Museum in Münich:

At Fernmeldemuseum Stuttgart, these were used to monitor subway trains, or light rail. I do imagine these panels must have been interactive with all the buttons?

I like that they light up to show status:

One of the modules was a counter:

And I believe this was a way to annotate that something was… fixed, maybe? Or on its way to being fixed?

A railway museum in Nuremberg used what looks like the exact same system, and I spotted a few modules with their plates removed:

And, here’s a similar panel shown in a tram museum in Stuttgart, filled with an incredible typographical tension between DIN and the German equivalent of Dymo:

Warsaw’s train museum had a slightly different system, but similar in look and feel:

This big industrial switch toggled between day and night. I don’t know if it changed the operation of the system, or is just switched on some sort of a dark mode for the panel itself:

And this was at the DASA Museum in Dortmund, from a power plant control room:

This was by far the biggest one of the ones I’ve encountered…

…with the biggest variety of modules…

This was also the panel I showed some molly guards from before. But today I want to end at this great switch:

Don’t you just want to rotate it, no matter what it does?

★★★★☆

A new confession: I struggle with a lot of accessibility writing.

I am not necessarily saying this to blame people writing in this space, whose work I respect even if it’s not resonating with me. I think it’s more of a recognition of how difficult it is to talk about accessibility and disability. Advocacy is never easy. It’s hard not to be impatient with the pace of progress, hard to contain your incredulity that others don’t get that what is so obvious to you, hard not to constantly expect more from people, hard to imagine others – and the society as a whole – not caring. On top of that, accessibility is a more difficult subject than many I cover regularly on this blog. There are hard-to-explain technical issues wrapped in deep legal considerations, and some aspects of disability are taboo or taboo-adjacent. To me, all this often makes even best-intentioned accessibility writing less approachable.

I am also, personally, to blame. I sometimes struggle with design writing, too. Some of the taboos and hangups live inside me. I might be obstinate when corrected. I have also personally seen a few times the opposite of the curb-cut effect: not fully thought through accessibility accomodations making software worse for some groups of people. All of this is making me a tricky customer.

I’ve been wanting to find accessibility writing that would work for me, with just the right amount of push and pull: detailed but not overwhelming, inspiring but not cheesy, gentle but not basic, pleasant without being cheap.

This book by Sara Hendren is as close as I’ve ever been to all this. It’s exceedingly well-written, to a point that it’s really hard not to quote it excessively. Witness the very opening:

Every day every body is at odds with the built environment. Bodies come up against stairs and sinks and subway platforms, sometimes with ease and grace and sometimes blundering and awkward, over hurdles, even in a sudden clash. Each flesh envelope is miraculous and mundane in its way, lugging all its gear and getting where it needs to go. Maybe you handle a sharp knife with enjoyment of its grip; maybe you wince as you sit down in or get up from your office chair.

Or, just a few pages in:

But consider: this dual job that design has to do is a mammoth task! How do you make a charismatic thing – not just a thing that works, but a thing that has elegant presence or pleasure in its handling, some kind of draw, a thing that pulls you in or makes you think while also being handy, modest, even garden-variety in its value? This combination is what makes design so interesting to so many people. It’s not just the quest for a better mousetrap, and it’s not just a free-form experiment, and it’s not just a slick new color scheme. […]

When Hendren early on decides to focus on the right words and the best definitions – a theme permeating the entire book, important in an area of sensitivity around language – it has none of the awkwardness of a wedding toast’s “the dictionary defines X as…” but is instead a lucid exploration of the power and beauty of language, piercing right through some of the taboos I mentioned:

Among disabled people there’s a bigger catch-all term, a slang for this particular mismatch: it’s called life on “crip time.” Crip is short for cripple, a name that disabled people have repurposed in an act of political reincarnation, dropping the degradation attached to a word that was used to describe them in the past, cripple, and investing it with in-group pride. “Crip time” is flexible shorthand in disability culture, used to indicate a range of uneasy relationships to the pace of contemporary industrialized life, with its relentless and clock-driven organization of hours and days. As a disabled person, to say you’re “on crip time” on a Tuesday might signal the extra time that it takes you to get to the train platform or in and out of a public bathroom. It can also stand for bigger systemic fits and starts – the spiky, unpredictable time it might take a person to proceed through a fairly rigid K-12 education that’s built on all kinds of normative chronologies.

This whole book is this – it’s accessibility and disability as details, as creativity, as confidence, as joy, as warmth, and as craft. The writing has so much range and color, covering some of the aspects I expected, but also talking about autism, dementia, phobias, and general intellectual disability (who knew? your brain is your body, too). Hendren dips into history as needed – the origins of the usually simplistically portrayed curb-cuts is fascinating – but the book is anchored in the present.

There isn’t a lot of software in the book, and the other reason I’m giving it only four stars is that I wanted… more photos. I’m a single-issue voter this way, always dreaming of visual evidence of devices, people, and places. But don’t let this stop you. This book will help you understand accessibility and disability – and if you already do, it might help find good ways to talk about it. You should read it.

Thank you to Ethan Marcotte for suggesting the book and a conversation about it, and to everyone who answered my question about good accessibility writing – check out the answers on Mastodon or Bluesky if you are interested in more recommendations!

1.

One of the classic parables about loading goes as follows.

A building manager had a problem: people were complaining about the elevator being too slow. But upgrading the elevator was an enormous expense, so the manager came with an alternative solution: they put a mirror next to the elevator call buttons. Even though the elevator didn’t become any faster, complaints trickled to a halt, as people were checking themselves out in the mirror and that changed their perception of how long the wait really was.

2.

In the late 1970s and early 1980s, it wasn’t uncommon to equip early home computers with audio tape players, using the same cassettes designed to record and play music. Software was encoded as sound. A lot of redundancy was needed to account for many low quality cassettes and misaligned playheads, so loading times were really long. There were other disadvantages – no random access but definitely random errors, tapes wearing out and being “eaten” by the player – but tapes were so much cheaper than floppy disks or cartridges that they endured.

On one of the computers, the British ZX Spectrum from 1982, an interesting convention emerged. As the game was arriving from the cassette, what was loaded before the code itself was its “title card.” The loading process of just this one image took about 35 seconds, and watching the graphic emerge was mesmerizing, almost like deciphering a puzzle – especially when, only toward the end, the color attributes appeared and the whole thing clicked into place:

Some of these were beautifully done (here’s a gallery of… all of them?), created by talented artists working in a very unforgiving medium, a pleasure to watch materialize on the screen…

…or, at least, it felt so for the first few encounters. Upon loading the game for the nth time, you grew more and more aware of the fact that you are spending precious time waiting to load a screen you’ve already seen. This was different than the first example; the mirror existing never slowed down the elevator.

Sure, it was just 35 seconds out of a 5–20 minute load time – I told you cassettes were slow! – but still. Some people loved them, others built truncated versions that skipped the title screen altogether (as much as you could imagine just fast forwarding through it like you would through a song, it didn’t work that way).

3.

Figma is a web design app, and its editor arrives in a big, everchanging blob of JavaScript, in addition to having to load and decode the contents of the file itself. This isn’t 5–20 minutes, but it’s long enough that it necessitated a loading screen of the heavy variety: one with a progress bar.

During my time at Figma, an idea would reappear with surprising regularity: what if we put a little hint next to the loading bar? Something that could teach you about a useful keyboard shortcut, or a trick? You’ve seen that before, often in games:

It seemed like a thoughtful gesture for the user, a mirror of the elevator mirror idea. But I fought it, tooth and nail, for one very specific reason: this would remove pressure to make this screen fast.

Had we given the screen another purpose, subconsciously or not, we might start caring less about improving it – as a matter of fact, you could make an argument to introduce artificial minimum loading time just so that the user could finish reading the tip!

4.

I had a similar feeling when, in 2018, Gmail replaced its simple progress bar loading state with this:

It was huge, corporate, intense. It felt like an admission of defeat: our app is slow, and I guess we’re surrendering ourselves to it.

But recently, I’ve noticed not just that Gmail’s loading state has been simplified, but also that it doesn’t appear nearly as often:

I don’t know the technical details: is it caching? a more intense refactor? Either way, as much as I absolutely dislike what Gmail has become – there might be no more harrowing place in the web app world than Gmail’s settings, for example – kudos to the team for making it better. Gmail seems to be loading a lot faster now.

(There is one small exception: it would appear that the loading state image itself doesn’t have a proper loading state – a rather strange omission.)

5.

There is, I believe, a more universal lesson in here.

Loading is a complex space, where sometimes the most natural solution is a bad one, sometimes making things faster is making things slower, and sometimes new thoughtful design for whatever delay there is can be a better use of engineering effort than focusing on shaving off more milliseconds. (It’s both speed and the perception of speed that matter.)

Also, this is exactly what Y2K was: We remember and react to loading states that are elaborate, cute, memorable – but we never see or link to loading states avoided.

And while you see occasional stories told by engineers making things faster, you don’t often hear accounts of people within companies, somewhere at the intersection of design and engineering, who work hard designing thoughtful loading states, avoiding loading state bloat, or figuring out some clever hybrid approach.

But, to be fair, there is also no parable of a building manager who just forked over some cash and installed a better elevator.

In response to a previous post, one of the readers wrote this:

I would phrase this as the fault of the animation having violated the Hippocratic oath for animations, which is “first, do no harm” a.k.a. “first, don’t interfere with user input”.

Yes, one has to be afraid of hyperbole – was there ever an onscreen transition that saved a life? – but there is something I really liked about this phrasing. After all, most transitions and animations are decorators, and every transition and animation is, by definition, also a delay.

Here’s Shazam as I open it, and overlaid are my frantic taps as I’m trying to make it start the song recognition process:

It’s a cute cold start animation, but:

• It’s not interruptible, like animations should be.
• It doesn’t even buffer the taps, so – in case the animation covers for something truly uninterruptible, like loading from the cloud – I can’t simply tap and forget, but instead have to wait and tap after it’s done animating.

What’s particularly frustrating here is how Shazam is being used. On the other end of this whole flow is a song that might already be fading out – timing myself, a user, can’t control – so time wasted on the uninterruptible animation might be seconds separating failure from success.

I know it does feel like a blink of an eye when watched out of context, and it is literally just a bit over a second of a delay in the best case scenario, but I wanted to share it as a general example. I believe these seconds add up, especially in a stressful moment, on an older device, repeated many times a day, across different apps… or all of the above. (My go-to example: Imagine your keyboard keys reacting with a second of delay!)

At least, I should compliment Shazam for not making another mistake: after the recognition starts, tapping the same button doesn’t cancel it – instead, you have to tap a close box in the corner. Here, the designers realized I might actually be slamming the big button many times over, and I shouldn’t be punished for it even more.

I wrote recently, about macOS, “it’s hard when the operating system cedes its responsibilities to provide good design patterns,” and Mac developer Brent Simmons in a recent essay shares a parallel line of thinking about how unreliable and untenable designing with the basic macOS UI components has become:

But there’s another reason: the stock Mac UI is designed by Apple, the best designers in the world, and do you really think you can do better? Really?

The app world is full of people who think they’re better and they’re really, really, really not.

Well, I still think Apple has the best collection of UI designers in the world, but, for whatever reasons, the guidance from above on how the Mac UI should look is missing the mark. I’m not blaming the people doing the work — they’re doing great work with the direction they’re given.

So this — bad direction — is where the secret third reason falls down. And we’re left with no real reason to stick with stock Mac UI (except for wanting approval from longtime Mac people like me, and you really shouldn’t care about that at all).

In addition to low interface quality and sometimes flimsy guidance, Simmons also adds how much effort it is just to keep up with default macOS interface, which feels like the opposite of its social contract:

The idea was that by using stock Mac UI you the developer would be carried along — you’d get most of the macOS changes every year mostly for free or with not that much work, since you’d kept up every year.

But my app NetNewsWire has a very stock Mac UI, and Liquid Glass adoption last year was a lot of work. Using stock Mac UI didn’t save us much — in fact, we had more work to do compared to the apps with more custom UI.

We talked about this before in the context of all those menu icons that were mandatory… for just one version. Imagine sinking time and resources to create the icons one year, only to learn 12 months later that this was just a head fake, and one without – as far as I know – even a hint of an apology from Apple.

Designer Reimar Servas goes further than the usual Border Radius Discourse and thinks about the deeper but often ignored questions of border radii as a system, and about the consequences of such a system that go beyond visuals:

[…] These redesign efforts suggest ignorance of a fundamental problem: rounded forms have a smaller surface area than angular ones. Used as containers, they reduce usable space.

This is fine on most touch-based UIs since they typically feature simple layouts with only a few controls and plenty of white space. Such spacious designs help our fingertips, which demand larger touch areas. A mouse pointer, by contrast, can target much smaller elements.

Professional desktop software — think 3D modelling, video editing, or music production — is often packed with small controls. On these complex interfaces (and the operating systems that host them) screen estate is precious, even on large screens. Heavily rounded elements don’t work well here.

I liked this simple, but powerful visual:

Servas adds:

Apple is well aware that principles from pointer-based UIs rarely translate well to touch interfaces. After all, they spearheaded the evolution of touch UIs and introduced multi-touch interactions like pinch-to-zoom to consumer electronics — formerly only seen in science fiction or obscure research projects . Yet they’re now rolling out single unified design language across watches, phones, desktop computers, and XR goggles.

The piece was written just before the arrival of Golden Gate, which undoes some of Tahoe’s damage. Yet, I remain worried about the rumoured touch MacBook. I consider adding touch to macOS an unsolvable challenge, unless you happen to be okay with compromising on precision and density. I’m not.

The relationship between keyboard manufacturers and standards bodies in various countries is so complex I barely understand a snippet of it.

The most famous example must be the 1990s PowerBooks, which had a beige variant for Germany and Germany only, to conform with local laws that prescribed and enforced specific color and contrast combinations for keyboards, in order to avoid glare and attendant ergonomic problems for terminal operators in the decades before. (It wasn’t just Apple. ThinkPads did the same.)

(I know. Jump scare!)

But you’ll understand that what caught more of my attention was an obscure variant of keyboards for (parts of?) Canada in the late 1990s and early 2000s.

The white 2003 keyboard might be my favourite of Apple’s keyboard design, instantly recognizable in either the American version (more words), or the European one (more symbols):

There was also the Japanese JIS standard keyboard, which famously kept Control where older terminals had it – to, no doubt, delight of Japan’s programmers:

These are the three well-known layout standards. The one for Canada followed Europe, but only to a point. The layout was the same, but the symbols weren’t:

Here’s an alternate view of the European and Canadian keyboards, and you can see that the latter one introduces different, unique symbols for Ctrl, Alt, Tab, Caps Lock…

…and even goes as far as Esc. (The Esc symbol is roughly the same you see worldwide, but for some reason, Apple always shied away from putting it on even symbol-friendly keyboards – even though frustratingly it’s being used in macOS menus in all the locales.)

The story repeats itself in the middle of the keyboard. Here are, again, the US and European editions…

Canada, with its abundance of icons, makes Europe feel like America:

Even the arrows are different – here’s America vs. Canada:

Even the Enter arrow – here’s Europe vs. Canada:

And numeric Enter/​Return gets a different shape, too:

I don’t really know what is the full story here. I imagine the government exerted some pressure and Apple relented, creating a unique set of keyboards with some really ugly icons.

I know the previous two models were affected also – here’s AppleDesign keyboard from the second half of the 1990s:

You can see all the same symbols…

…and even the extra glyph for Num Lock I imagine was prescribed for the PC side, too:

And, closer to the present, I have seen examples of the first metal keyboard from the late 2000s, too. But I don’t believe these symbols are used today. Even in their heyday, I’m not sure whether they were sold in the whole of Canada, or just its French-speaking portion – if you know, please share.

It’s my understanding this is called the CSA or ACNOR keyboard. And, just like before, these symbols are in Unicode – ⇬⇭⎆⎈⇱⇲⎗⎘ – looking just as gorgeous.

That was me being sarcastic. I can imagine the pain inside Apple of someone having to put the ugly symbols coming from above, alongside otherwise generally thoughtful and refined typography. Sure, Apple did good here compared to other keyboard makers, but still, it must have hurt. This is what makes these keyboards so interesting to me.

But there’s one more symbol that might be interesting to talk about, and perhaps you already spotted it above. It’s here, on the Japanese keyboard:

This time around no standard was involved; I believe that the pencil on the Control key is solely Apple’s invention.

What is it for, and why was it there just in Japan? Typing in Japanese might be among the most complex, requiring switching between a few writing systems – katakana, hiragana, kanji, and also Western letters – as fluently as possible. To help with that, Apple used a system called Kotoeri, and added a new alternative symbol for Control that was also present onscreen, in the relevant typing menus:

The system was there in the waning years of classic Mac OS and early years of Mac OS X.

Just like with the Canadian symbols, I don’t fully know what happened to Kotoeri. I’m reading that it was gone from Mac OS X by 2014 – but even already in the years before, Apple removed the slightly pixellated symbol from their keyboards, and switched back to a standard ⌃ Control symbol in the UI.

Of course, if in the 1990s it was people in Japan who had to switch between various keyboards all time, today, thanks to emoji, it is everyone. If the Kotoeri pencil reminds you of something, Apple came back to the same well more recently with the 🌐/Fn key – but I already wrote how much I hate that.

Inspired by a conversation with a friend, I made a mini site that’s an interactive representation of my design bookshelves:

I am hoping it becomes a fun reference to browse, or something just enjoyable to play with. I made the interface feel very differently on desktop and mobile, and I hope both are fun. (There’s also a simple list if not.)

I wish, just like with a regular bookshelf, you could open any book and check it out – but that’s tricky for many reasons. (I did at least scan some of the covers that weren’t available on the web.)