Speaking of user interface guidelines, developer Matt Sephton and others compiled many of Apple’s human interface guidelines, starting from 1980, all the way to 2014, including some goodies like early drafts, NeXT, Newton, and so on.

Elsewhere, designer Geof Crowl put together his own list that goes broad instead of deep, including style guides other than Apple’s, too.

The list was made in 2020 and a few links are already broken, but there are some gems here like the modern Designing for Playdate, or the classic Zen of Palm from 2003. You can learn a lot just by grabbing one and scanning it.

Let me add a few more I know of:

• Amiga User Interface Style Guide (1991)
• Magic Cap Concepts (1995) with a strange subtitle “Everything right is wrong again”
• Java Look and Feel Design Guidelines (1999)
• Windows Interface Guidelines for Software Design (1995)

I like learning new things, and I like learning new old things. I was looking at Apple Human Interface Guidelines from 1987 and this passage caught my attention:

The most common use of double-clicking is as a shortcut way to perform an action. For example, clicking twice on an icon is a faster way to open it than clicking once to select it, then choosing Open from the File menu; clicking twice on a word to select it is faster than dragging through it.

I knew that double click an icon was a shortcut to the first action (typically Open), but I never really thought of double-clicking a word as a faster way to drag across to select it – even though, in hindsight, it makes perfect sense.

Another vintage thing I learned of recently from a coworker is this, also covered in the 1987 HIG:

If the user begins a double-click sequence, but then drags the mouse between the mouse- down and the mouse-up of the second click, the selection becomes a range of words rather than a single word.

This doesn’t feel (to me) like a very pleasant gesture to perform repeatedly, but what feels nice about it is that it automatically snaps the selection to the endings of the words:

Part of me would prefer this to be the default behaviour when selecting more than 3 words, or so, so you could be less precise.

Anyway. The double clicking to perform default action applies to a lot of lists of things. Here are some examples from Scrivener, Word, and Lightroom – you can double click on each of these items to proceed, without having to select and click the button:

But sometimes the creators of such dialogs forget. Here’s Screen Sharing in MacOS, and a notification in Chrome where only the slow path is available – double clicking on items doesn’t do anything:

The tricky part about not being a good citizen of a shared user interface is that those omissions aren’t just local to your app – they can ruin the gesture in other places, as people’s fingers learn to distrust it in not just your app, but in general.

(The quote in the title is from Apple Macintosh User’s Handbook.)

The Touch Bar arrived in 2016 seemingly already pre-doomed, on a generation of machines that had a “we’ve run out of ideas” smell all around them. The arrow keys were reshaped, the keyboard got a slimming down, and even the beloved MagSafe wasn’t, in fact, safe. All of these changes would prove unpopular and get reverted in time, and the axe would eventually come for the Touch Bar, too.

With an enormous benefit of hindsight, a decade after its arrival, and on the (rumored) eve of fully multitouch MacBooks, I wanted to look critically at the Touch Bar in more detail. I put a spicy title above this post, and while I’m not sure I can answer it in the affirmative, I feel I got surprisingly close to that.

What did the Touch Bar do?

The Touch Bar replaced the top row of the keyboard with a narrow touch screen and a Touch ID surface/​button on the right.

The touch screen provided a constant virtual Esc key on the left, and the remainder could become one of a few things:

• app controls – whatever the app wanted (either buttons or more interactive surfaces):

• control strip – roughly the same as what function keys do today by default (brightness, transport controls, volume):

• a hybrid mode of smaller app controls on the left, and expandable control strip on the right:

• F1–F12 keys:

• a few smaller modes, like showing spaces, quick actions, or emoji:

• small submodes where only the middle of the Touch Bar would be taken over:

The Verge has a five-minute video that shows a lot of this stuff nicely.

Functionality

Touch Bar arrived with a hybrid of functionality for casual and pro users – some built into the macOS itself, and some coming from specific Apple-owned apps.

A few apps offered basically a subset of their toolbars (although often without customization), with an occasional submenu, like digging deeper into font options or choosing a color adjustment. Some apps like Safari and Photo would invest in tiny previews of objects.

Particularly demo-friendly were sliders for volume and brightness, and those in specific apps – playback in QuickTime, or swiping through the photo gallery, clearly inspired by similar controls on the iPhone. Even though Touch Bar was referred to as “multitouch,” it really only supported tapping and horizontal swiping, with just the latter being something classic function keys clearly couldn’t do.

A simple but effective was also an arrow pointing to Touch ID authorization and payments – a small example of software proprioception – which Apple even included as a GIF in their press release:

But there were also some strange moments, the strategy feeling a bit like “let’s throw a lot of stuff at this and see what sticks” (then again, it worked for the first Apple Watch!):

• Any system dialog would show its buttons repeated in the Touch Bar. This felt puzzling to me, as those were already served well by both mouse interactions and keyboard (Esc/Enter).

• It was nice that you could drag the volume or brightness control, but then the slider would be disconnected from your finger and the volume would also appear in the old HUD on the screen, altogether feeling like different parts of the system weren’t aware of each other.

• Xcode offered a button to comment out the current line or selection, which must have felt almost insulting to programmers – is there anyone who’d prefer that over the ⌘/ key combination?

Lastly, for the first edition, the IA felt complex:

• Word completion was in the middle of the bar, but the emoji entry point was on the left.
• There were many kinds of chevrons (at least three!), and the action didn’t fully match their arrows – some of the chevrons indeed made the controls expand in an expected direction, but some instead drilled deeper and took half of the bar, and others took over the whole thing. (On top of that, some controls had regular horizontal scrolling.)

• Some controls that looked like regular buttons expanded on tap, too, so in effect it was never truly clear what a control would do when touched.
• The close boxes were sometimes on the left, and sometimes on the right of the buttons.

Settings

Strangely for such a high-profile feature, the Touch Bar settings arrived sprinkled in between older keyboard options, rather than in a separate Touch Bar tab that could help you understand the whole system easier, and also perhaps offer nice previews of what was possible.

Apple’s penchant to brand even small things also backfired a little bit – customizing the Touch Bar required facing strange phrases like Quick Actions, App Controls, and Control Strip (this is where the usually non-nostalgic Apple reused a classic name, rather than naming it System Controls to mirror App Controls).

On the other hand, the Customize Control Strip interaction here was an absolute highlight, providing a magical-feeling bridge between the world of the Touch Bar and the heavens above it – this was perhaps the best-designed part of the whole system:

(That kind of customization was also available in some, but not all of the apps that supported the Touch Bar.)

By the way, Apple seems to have learned the settings lesson since 2016, or even overlearned; the action button introduced to the iPhone in 2023 came with a lavish new interface:

First public reactions and the evolution

Back in 2016, the Touch Bar arrived to muted optimism (“not great, perhaps promising, looking forward to season two and three”), mixed with loud frustration from seemingly every single person who relied on the physical Esc key.

Touch Bar was only revisited once, in 2019; this slight update reintroduced a mechanical Esc key, and felt slightly faster in use.

There were no other hardware improvements, and I believe zero software changes from Apple’s side during the whole lifetime of the feature. Some third-party apps added Touch Bar support in the first few years, but even then the verdict seemed somewhat reserved:

Most Final Cut Pro power users will be so used to using keyboard shortcuts for the editing functions they use regularly that they may not find the Touch Bar any quicker for simple editing and playback, but the sheer number of context-dependent settings means it’s likely to prove its value eventually.

The Touch Bar never made it to non-Pro MacBooks or other computers, and started being phased out altogether five years after its arrival. Perplexingly and for reasons we might never know, the project was “maintenanced” almost as soon as it launched, and it wasn’t immediately removed perhaps only to save face.

Haptics and ergonomics

Touch Bar felt unpleasant to fingers.

People’s ire around the Esc key was mostly in how “dead” it felt next to the other keys, which was especially important for something further in the periphery, used as an escape hatch or as a core interaction by programmers. (The key was also slightly offset, likely only to preserve symmetry vis-à-vis Touch ID on the other side.)

I bet that the unavoidable and constant comparison of the feel of the Touch Bar buttons to the real keys just below was what made the whole thing feel worse than it was, and I’ve always wondered if haptics could have helped here. What if a light touch offered gentle haptic feedback similar to feeling the “ridges” of the keys without pressing them, and a deeper press offered a proper haptic tap?

Already in 2016, Apple had similar tech in the trackpad underneath. I bet I’m underestimating how hard or expensive it would be to repurpose it, but: the iPods never had true haptic feedback, yet even in the first model they arrived with a little speaker that emitted haptic-like sounds on actions. It was surprisingly effective, and I was curious why Apple didn’t do the same thing here.

On top of that, while the row of function keys above is fun for an occasional press, it doesn’t ergonomically seem as great in prolonged use. Reaching up to the Touch Bar is more effort than reaching for the trackpad, whether you put it below or to the side – there’s a reason keyboards grow wider but they rarely grow taller. In The Verge video above, you can see the reviewer use a Touch Bar button as a modifier key while interacting with the trackpad below, and it feels unpleasant just watching that happen:

On top of that, the Touch Bar surface sat lower than the surface of the keys, which made it ever so slightly less pleasant to use – it didn’t only feel like it was above the keys, but also behind them.

There were other rough edges that added up:

• The Touch Bar would go to sleep eagerly (after only 60+15 seconds), hiding all its controls and forcing you to tap it or press a key to wake it up.
• The quality of the animations was not the same as on the other touch devices or the Apple TV.

• While the Touch Bar itself was fast enough to support smooth scrolling, there was also some (I think intentional) delay when pressing the Fn key and some Touch Bar controls, plus a general slight, but perceivable latency on every touch.
• Speaking of scrolling, it was uneven: in Calendar, you could use momentum scrolling but the calendar didn’t update in real time, and stopping the momentum by tapping anywhere like on the iPhone actually selected a different month:

• Often the only way to escape a submode was to press a close box on the left, which was unpleasant given the position of your hand; there was no thoughtful shortcut, like double tapping an option, to exit faster.

Size

Using the Touch Bar was being constantly aware of its small size: The previews were tiny, your fingers overlapped content all the time, and scrolling only happened in the horizontal plane. (And you had to keep your finger in a straight line instead of a slight arc – not a natural gesture.)

Expanding the Control Strip required tapping on a very small chevron; there were tons of those tiny chevrons elsewhere, too, narrow and hard to press without haptic feedback. It made the interface feel fiddly, a strange compromise from a company that thoughtfully established and enforced the “44 pixels” minimum size for touch targets with the first iPhone. (The chevrons were exactly half of the recommended minimal physical width of any touch target on the 2007 iPhone – 3.5mm instead of 7mm.)

Many spaces felt tight in other ways, too. Craig Federighi’s keynote demo showing Safari previews was claustrophobic with just five tabs:

When using any typing surface, the Touch Bar would get divided into three areas: app controls, suggested words, and control strip on the right:

In other apps, some areas were scrollable, but there was no room for a scrollbar. Using the Touch Bar in any meaningful capacity felt like constantly guessing what’s movable and what isn’t, and constantly resizing tiny virtual windows, except without any pleasant resizing mechanics from Apple’s larger screens. Here, the emoji pane UI is doing some really clever things to help traverse hundreds of emoji, yet it still feels not enough:

The interactions in photo editing and a few other places felt so cramped and convoluted that I wonder why anyone would choose them over the spaciousness and precision of the screen above.

I wonder if the limited height also created other downstream effects. For example, drilling down did a (slow) fadeout/​fade in effect, instead of scrolling down and up to help you understand the hierarchy – and showing the chevron pointing in that direction, too. I am guessing that was because the movement would suggest you can swipe up and down, and there simply wasn’t enough room for that gesture to feel good.

Using the Touch Bar, I kept thinking of the wonderful customization feature I mentioned that cleverly fused the Touch Bar with the screen above, and also a similar interaction from a 1980s Xerox machine (where pressing the key below More would show other options):

Could this have worked for other Touch Bar interactions to create more room, or would it become frustrating as your fingers would naturally want to tap the bottom of the screen? There is a small thoughtful integration like this in text editing, where the Touch Bar seems to be aware that while your fingers are downstairs, you might be looking up:

But then, in the same place, choosing a color is not integrated the same way:

All in all, the Touch Bar was new I/O sandwiched between an old O and an even older I, and it didn’t seem like all the relationships here were fully figured out.

Could Touch Bar just grow larger? Asus Zenbook Pro showed the endgame of this idea – it enabled some new interesting things, but threw in tons of more challenges like a missing trackpad, or deciding what to put on each surface:

I wouldn’t expect Touch Bar to go nearly as far, but I was curious to see it grow a little bit vertically to alleviate some of the pains.

Customization and infrastructure

Apple bet the Touch Bar house on individual app built-in support and a few core interactions. But I wonder in hindsight if the answer was user customization.

On that front, the Touch Bar exposed Apple’s underinvestment in the actions infrastructure. Keyboard customization in macOS has already felt ancient in 2016 and did not improve since, and Shortcuts app didn’t even exist then. This was Apple’s chance to provide a gentler Keyboard Maestro-like experience for the masses, but the Touch Bar didn’t allow you to plop in even a few function keys alongside the new features – the only option for that was the old-fashioned mode with F1–F12 with none of the benefits of the Touch Bar (you couldn’t even change the labels!), and also without haptics.

Sure, there was a gesture in this direction with Quick Actions, but those felt extremely underbaked; in my explorations with Automator and Touch Bar, I encountered some truly confusing settings and flows and could never make it work fully. Here, I had to go to a faraway System Preferences pane, and see various Quick Actions that were not talking to one another:

In a better setup, it would be possible to assign any key or action or menu command to any ground-floor Touch Bar button; something like SF Symbols (formalized in 2019) could provide all the necessary icons. Or, one could imagine some delightful integrated interactions like this one that would make it easy and pleasant to make the Touch Bar feel personally useful.

Or, how about sparklines or other tiny widgets that’d quickly show visual status, of the kind pro users like to put in the menu bar already, and easily pluggable to data sources (see the very recent TerminalWidget)? Or a left/​right slide gesture, buttons, or a keyboard combination to swap between Touch Bar “spaces”?

How about learning what commands you use most often that don’t have keyboard shortcuts, per app, and suggesting them as the first five buttons on the Touch Bar?

Could the Touch Bar have been saved?

Today, it often feels like the Touch Bar chose revolution in the moments the right answer was evolution, and evolution in places that called for a revolution. With hindsight, after seeing projects like Stream Deck and Flux Keyboard capture people’s attention, maybe it could have worked this way:

• First version arrives with a physical Esc or at least “sound-based haptics,” and allows you to do more things via much nicer settings software: easy assigning of buttons to system actions, and icons so you no longer have to remember whether it was F3 or F7 doing your thing. Don’t treat the Touch Bar as repudiation of function keys, but as their enhancement. On top of that, add some easy-to-put-together widgetlets and sparklines. This is Pro hardware, and these feel like pro features.
• Staying tighter, focused, and reigning in some more complex interactions would help, too (problem: they look so good in videos!). Instead of boiling the ocean and recreating a lot of the existing GUI in a cramped space, focus on just one–two great interactions per app. Finder: Show the Quick Actions that were already customizable and not as easy to access in some views! Emoji: Paginate instead of scroll, but do a really clever pagination that highlights the power of a parallax swipe gesture that can only exist here. System: Add immediate screenshotting by default.
• If this worked, subsequent versions would add haptics, perhaps increase the size, and go mainstream from pro users to regular users, learning all the useful lessons along the way (also from third-party apps like Pock).

But I’m not sure. Touch is fun but there is, ultimately, a ceiling on value you can squeeze out of a small touch strip, and a floor on complexity of yet another input/​output device.

And there was always an elephant in the hardware room – many pro users are likely to use computers on desks with separate keyboards, which puts the Touch Bar either too far away or makes it altogether inaccessible. In the decade since, Apple hasn’t even solved this for Touch ID, the only part of the Touch Bar that didn’t get sacrificed to the angry IBM 3270 terminal gods.

Would the Touch Bar have worked as a standalone device? Could it ever become good enough for you to want to pay for it twice?

Perhaps not. But had Apple improved the keyboard and action customization software for the Touch Bar, only to see it crash and burn, we could at least still keep the software.

Following (or, preceding) the previous post…

1.
Old computers loved 8×8 fonts and they also loved 8×8 graphics.

Since for many of those computers the graphics were displayed side by side without any gaps, the fonts had to waste a precious pixel or two to create some breathing room between the characters. But there was a benefit to this arrangement – you could seamlessly combine two or more tiles into something bigger.

You could see that already in built-in graphics for a late 1970s computer Ohio Scientific Challenger 1P: a lot of single-character graphics of houses, tanks, planes, and people – but also some that only made sense fused together, forming submarines, warships, or the U.S.S. Enterprise:

A later computer called Atari ST had an Atari logo spread across two characters, and an easter egg – a 16×16 face of “Bob”.

And Apple II’s character set allowed to combine a few glyphs into a running man, a folder, or a scrollbar:

Arcade videogames did the same. Pac-Man’s maze was assembled out of solitary 8×8 characters, but Pac-Man and his frenemies were large, clocking in at 16×16:

You can even spot a fascinating technique above. The ghost could cleanly fit in a 2×2 grid, but instead it’s offset vertically and takes up a 2×3 slot. Why? Just so the eyes and the “skirt” could move independently without a combinatorial explosion of tiles needed:

2.
Not long ago, we looked at various installation graphics for Mac OS X apps. Those creatively used a new feature of Finder: a way to specify a background image.

The Finder before Mac OS X, from 1984 to the late 1990s, didn’t have that feature, and yet you could occasionally see something like this:

How was it done? By splitting the graphics into many 32×32 icons, and then positioning them carefully inside the window.

The icons weren’t proxies of apps or even images. They were just there. The last ingredient was names composed of only whitespace, and it all started looking like one unbroken huge image… except when you invoked the Clean Up function, which proceeded to ruin the whole thing in a particularly delightful fashion:

3.
Ever since its launch in 2014, Slack allowed anyone at any workplace to create custom, shared emoji, and starting a year later, people could also use them in their reactions.

Those proved to be very popular, and many books could be written about how custom emoji reflect a given organization’s culture.

Many emoji could also be output side by side, and Slack chose not to put any space between them:

I think by now you know where this is going.

People started splicing bigger images into smaller emoji, first by hand…

…then with limited automation, and then via fully automated tools with names like slack-big-emoji or slack-emoji-enlarger:

As in every other version of this technique, assembling the tiles the proper way is part of the challenge. The one above looks like this:

:tjp3-000::tjp3-001::tjp3-002::tjp3-003::tjp3-004::tjp3-005::tjp3-006::tjp3-007::tjp3-008::tjp3-009::tjp3-010::tjp3-011::tjp3-012::tjp3-013::tjp3-014::tjp3-015::tjp3-016::tjp3-017::tjp3-018::tjp3-019:
:tjp3-020::tjp3-021::tjp3-022::tjp3-023::tjp3-024::tjp3-025::tjp3-026::tjp3-027::tjp3-028::tjp3-029::tjp3-030::tjp3-031::tjp3-032::tjp3-033::tjp3-034::tjp3-035::tjp3-036::tjp3-037::tjp3-038::tjp3-039:
:tjp3-040::tjp3-041::tjp3-042::tjp3-043::tjp3-044::tjp3-045::tjp3-046::tjp3-047::tjp3-048::tjp3-049::tjp3-050::tjp3-051::tjp3-052::tjp3-053::tjp3-054::tjp3-055::tjp3-056::tjp3-057::tjp3-058::tjp3-059:
:tjp3-060::tjp3-061::tjp3-062::tjp3-063::tjp3-064::tjp3-065::tjp3-066::tjp3-067::tjp3-068::tjp3-069::tjp3-070::tjp3-071::tjp3-072::tjp3-073::tjp3-074::tjp3-075::tjp3-076::tjp3-077::tjp3-078::tjp3-079:
:tjp3-080::tjp3-081::tjp3-082::tjp3-083::tjp3-084::tjp3-085::tjp3-086::tjp3-087::tjp3-088::tjp3-089::tjp3-090::tjp3-091::tjp3-092::tjp3-093::tjp3-094::tjp3-095::tjp3-096::tjp3-097::tjp3-098::tjp3-099:
:tjp3-100::tjp3-101::tjp3-102::tjp3-103::tjp3-104::tjp3-105::tjp3-106::tjp3-107::tjp3-108::tjp3-109::tjp3-110::tjp3-111::tjp3-112::tjp3-113::tjp3-114::tjp3-115::tjp3-116::tjp3-117::tjp3-118::tjp3-119:
:tjp3-120::tjp3-121::tjp3-122::tjp3-123::tjp3-124::tjp3-125::tjp3-126::tjp3-127::tjp3-128::tjp3-129::tjp3-130::tjp3-131::tjp3-132::tjp3-133::tjp3-134::tjp3-135::tjp3-136::tjp3-137::tjp3-138::tjp3-139:
:tjp3-140::tjp3-141::tjp3-142::tjp3-143::tjp3-144::tjp3-145::tjp3-146::tjp3-147::tjp3-148::tjp3-149::tjp3-150::tjp3-151::tjp3-152::tjp3-153::tjp3-154::tjp3-155::tjp3-156::tjp3-157::tjp3-158::tjp3-159:
:tjp3-160::tjp3-161::tjp3-162::tjp3-163::tjp3-164::tjp3-165::tjp3-166::tjp3-167::tjp3-168::tjp3-169::tjp3-170::tjp3-171::tjp3-172::tjp3-173::tjp3-174::tjp3-175::tjp3-176::tjp3-177::tjp3-178::tjp3-179:
:tjp3-180::tjp3-181::tjp3-182::tjp3-183::tjp3-184::tjp3-185::tjp3-186::tjp3-187::tjp3-188::tjp3-189::tjp3-190::tjp3-191::tjp3-192::tjp3-193::tjp3-194::tjp3-195::tjp3-196::tjp3-197::tjp3-198::tjp3-199:

What’s the point, you might ask, if Slack also allows to share images?

I am not certain there is one. Sure, you can write around a tiled image in a way you cannot around a regular image, and you don’t get any chrome. But the real rationale here is, simply, the love of the game.

But this is why I love the details of history. You never know when an old detail chooses to come back to life again. Sometimes it will be a fun hack to try, but once in a while, it might be the only solution to a gnarly problem.

Thank you to Andrew Yaros for teaching me about tiling in classic Mac OS.

A really well-produced 27-minute video from Super Splash Wave about 8-bit and 16-bit pixel art:

What I liked about the video is that it doesn’t just revel in nostalgia, but goes deeper into some techniques and trends and details in the videogame graphics of the 1980s and the 1990s: palette limitations, palette animation, sizes of objects, dithering, parallax, small ventures into 3D, etc.

It was also great to see specific changes and evolution of what from the distance of 2026 might seem like one monolithic era. The very first games used rigid grids and the assets were generally done by engineers themselves. Then, the work was split between artists doing the visuals, and engineers implementing then. Only after that, closer collaboration between engineering and artists allowed truly spectacular effects to take place, mirroring what we’ve seen in UX design when designers and front-end engineers work closely together.

A nice moment I spotted in Asana – you can quickly record your name pronunciation (the video below does not have sound):

As someone who has “How to pronounce my name” in the footer of his website, it’s much appreciated!

The result appears as a simple icon next to your name:

For discoverability, if you spot this speaker icon on someone else’s profile yet, it shouldn’t be that hard to connect it to the microphone on your own profile that allows you to record:

Safari broke tap to top for tabs (say it three times fast), and Bear added two-fingers gestures. Ivory – a Mastodon client for iOS – tries a different approach in a slightly different setting.

The normal tap to top gesture works as expected, but tapping the top again returns you back where you were before:

I believe this is meant to be a small gesture of help if you tap to top accidentally, yet I am not entirely sure it’s effective. Would you, in a moment of panic, decide to do the same thing again, after years where every other gesture like this in the entire system taught you those taps are idempotent?

It gets a little bit worse, too. There is another established standard of going to the top – tap the selected tab again. This works across the entire operating system, too. But Ivory changes it, requiring you to tap twice, not once:

I don’t have access to the combined feedback of Ivory’s users, but I am much less of a fan of this than of Bear’s approach, as it doesn’t feel like it comes together as a system.

At the bottom of the screen, the interface teaches you that you have to tap one more time than usual, likely putting in your fingers the idea that you just have to tap many times, especially if you never figure out it’s a double tap and not two taps that trigger the interaction.

But then, at the top, this is how the interface reacts like this when you do exactly the same thing:

It feels like a system that’s well-intentioned, but inconsistent not just with the rest of iOS, but also with itself.

I praised the note-taking app Bear before for its memory; the app would always remember your last-visited note and the precise place within it, even if it had every right to forget it.

But there is a general problem here: memory that kicks in when not expected can be frustrating, as you have to undo its results and “reset to normal.” For Bear that’s not a problem, though, right? The whole iOS has a nice “tap near the top to scroll to the top” gesture that would work here as well, making it easy to recover if you return to the note where you last happened to type.

Except, with any writing app, the very bottom is as valid of a destination as the very top.

Bear designers understood it and tried to solve it in a new way, by adding two gestures: a two-finger swipe up takes you to the very top, and a two-finger swipe down to the very bottom:

It doesn’t quite work as well as I hoped – for some reason, it scrolls way too far down, and does feel a bit sticky mechanically.

It’s also, like any complex gesture, not very discoverable. But here’s where Bear tries to help, by… adding even more gestures atop these two. There is a two-finger swipe left or right for jumping back and forward in history…

…and even a two-finger tap to reveal a navigation menu.

That last one feels like overkill to me, but there is something interesting about the app building an entire little universe of compatible gestures – “Come here for all your navigation needs!” – knowing that it increases the chances users will develop a habit of learning and using them. (The gestures also work whether you’re in view or edit mode.)

I am curious, though: Would allowing to tap somewhere near the bottom edge not work as the “obvious” solution to get all the way down?

I just learned something fun this weekend. The seminal videogame Pong from 1972 looked like this:

But there was a problem. Here’s Al Alcorn, the designer/​engineer of the machine:

The paddles on the original Pong didn’t go all the way to the top. There was a defect in the [circuit] – I used a very simple circuit, I had to, to make the paddles, but they didn’t go to the top.

This meant that there could be situation where the ball sneaks up past the paddle at the very top of the screen, and the player cannot do anything to stop it.

You can see it in this video:

But Alcorn decided not to change that:

I could have fixed it, but it turned out to be important, because if you get two good players they could just volley and play the game forever. And the game has to end in about three or four minutes otherwise it’s a failure as a game. So that gap at the top, again – a feature. So that was sort of a happy accident.

“Happy” primarily in the context of the industry – the goal of an arcade game was, after all, to bring in quarters, and this here was the unexpected equivalent of the zero in a casino roulette game. But I wonder if some of this bugginess/​randomness also helped the game feel challenging and surprising, even for skilled players.

The task manager app Linear does something interesting I have not seen before. In the keyboard shortcut tooltips, it highlights the modifier keys you already pressed, to give you confirmation you’re on the right track:

I think this is nice, particularly given that the modifier key situation is kind of a mess, and particularly if you consider some keyboards present their modifier keys like this:

I think it’s valuable to offer a connection between your fingers touching keys and something happening onscreen in real time – similarly how the blinker arrow in your car pulses exactly at the same rate as the sound it makes, to help you connect the two.

However, Linear does not do this in all the contexts:

While the first two videos might be simply bugs, I am not sure about the last three. It’s entirely possible this was done intentionally because these surfaces – the menus, the command palette, and the keyboard shortcut pane – do not support actually invoking the shortcuts. (Pressing the listed keys would not actually achieve anything.)

But I still wonder if this was a good call. One of the most important things for any new systemic pattern is building trust: making sure it’s consistently applied in all the nooks and crannies so that the user can understand what it does, learn to rely on it, and form the habit. Just one place where it doesn’t work might make it easy to just give up on it altogether.

Perhaps this is an example of how hard it is to design a cohesive system, which in Linear’s case is compounded by the fact that a lot of shortcuts start with regular keys like G and O and P, exacerbating focus issues. Either way, it’s delightful to see someone doing something new in this space.

Something different for today: a one-hour episode of a podcast A Life Well Wasted from 2025. (I can’t link to it directly, but it’s the most recent episode, called “Game Over.”)

It’s a human story whose beats might be familiar to some of you: a long software project that ultimately failed despite the enormous effort. And it did so in an industry – high-budget videogames – where failures might feel particularly brutal: the projects take multiple years but the defeat can be swift, the servers get shut down and the game instantly evaporates, and instead of employees being reallocated to other games, the studio gets disbanded and people let go.

There are some nice moments in the podcast’s interviews with about a dozen people, hearing about personal pride and responsibility, working together with others, and a certain camaraderie not just with other people, but with their software that develops:

I think the best part about it was being able to play with my coworkers and then cutting loose, and being silly, and really enjoying what we made together, as a unit. That experience alone made it worth it.

There are also questions about the management’s role in all of this – this part we might never get to know fully – and the worry about game preservation.

This is not mentioned in the podcast, but it seems widely understood the story is about Concord, a AAA live-service game that is rumored to have cost a staggering $400 million dollars and taken 8 years to develop, only to be shut down mere 12 days after its launch in the late 2024. (AAA means a blockbuster with highest budgets seen by the industry, and live service means a game like Fortnite, which is expected to make money over time from add-ons and upgrades.)

Learning about Concord’s macro view adds a lot of color to the boots-on-the-ground podcast above, but one has to be careful exploring it; the online discourse about the game felt similar to the 2016 reboot of the movie Ghostbusters where sure, the product might have been subpar, but also a lot of commenters seemed eager to arrive to the conversation carrying truckloads of bad faith, gatekeeping, and misogyny.

Some good articles? Keza MacDonald in the Guardian has a nice summary of the whole situation:

This is a brutal sequence of events. Sony bought the makers of Concord, Firewalk Studios, in 2023. Concord had been in development for eight years, and it was an expensive game, with bespoke cinematics and a long-term plan that would have cost $100m or more to develop. In its two weeks on the market, it sold fewer than 25,000 copies, according to estimates. This is a shocker, even compared with the year’s other bad news for developers and studios.

MacDonald also adds:

Speaking personally, I do not want a game that takes years to play. I want one with something to say, an experience to impart, and one that eventually ends. A game whose artistry comes before its business model.

This is partly a matter of taste. Self-evidently, there is an enormous market for live-service multiplayer games; it’s just that most of those people are already playing one. I highly doubt that there are untapped millions of players desperate for a hero shooter or battle royale game who just haven’t found the right one yet. It’s time that publishers try something new instead.

An article by Matt Kim at IGN adds to this notion:

With so many games now taking close to a decade from the beginning of development to release, we’re starting to see the financial and creative consequences of an overlong development cycle. Spend too much time in development and ideas that were once novel are no longer in vogue. Furthermore, the time and money spent over those years has to be recouped somehow, which leads to decisions like the $40 cost of entry for Concord when many of its peers are free to play.

The cost of coming late to the party means you must bring something new to the table. Unfortunately, Concord is neither particularly innovative nor content-heavy. That said, it does have a level of polish at launch that was often absent from its hero shooter peers when they were first released. Indeed, Concord’s weekly animation story drops are fully motion-capture, and Firewalk’s time spent on crafting its lore has helped secure Concord an episode of this winter’s video game animation anthology series, Secret Level.

But well-established hero shooters like EA’s Apex Legends launched almost bare bones and still managed to make a splash thanks to its intriguing central concept which combined hero loadouts with a battle royale match format. Valve’s Deadlock doesn’t even have finalized assets or art but has still caused a huge burst of excitement among the PC community, thanks to the way it changes up the classic 6v6 hero formula with its heavy lane-and-minions MOBA [Multiplayer Online Battle Arena—ed.] mechanics. By contrast Concord appeared with an all-too-familiar offering and, frankly, the time spent on finessing its presentation – the graphics, motion capture, performance, and so on – likely lead to a later release date which in turn meant it lost valuable time establishing itself among its peers. If it had been released four or five years ago, when the PS5 first came out, maybe its launch would have been an entirely different story.

I think this is important to quote on this blog that often talks about “finessing” and implicitly – or sometimes explicitly – about the value of taking time to get the details right. We can’t forget that there are such things as overdesigning and overproducing, and that ultimately there is no way to polish your way out of something that lacks a soul.

I am generally not a fan of typewritten art, because at some point it all starts to feel a bit same’y, and the gimmick of using a typewriter as a paintbrush wears off pretty quickly.

But these drawings by German artist Arno Beck caught my attention, because it feels like they playfully remix three eras:

• overtyping keyboard art (early 1900s),
• the sort of photorealistic smooth shading I most associate with ASCII/​ANSI art (1990s),
• big pixels from early home videogames (1980s).

In case this interests you, in 2018 I gave a 46-minute talk called “The abridged history of having fun with keyboards” that’s a (hopefully fun) walkthrough of this whole space:

Robin Sloan:

I still use Sublime Text for all of my programming and all of my newsletter-ing. […] The app is simple and superfast; I have it set up exactly the way I like it […], and it’s difficult for me to imagine ever switching to anything else.

Here is a piece of software as sturdy and obedient as a cast-iron pan.

Sloan links to a piece by David Bushnell about Sublime Text, who writes:

I don’t know who develops it and I don’t care. All I know is that I can place my text cursor and read the surrounding code without a bombardment of popovers, pop-unders, pop-left-and-rights, pop-inlines, pop-in-and-out-too-fast-to-sees. […]

The perfect dev stack is a collection of software that each does one job and doesn’t suffer main character syndrome. I want to code, I’m not looking to make lifestyle choices. I don’t want a bloated everything app. Don’t get me started on the “unified toolchain” plague! Show me the latest VC-backed build tool and I’ll show you ten lines of PHP that does a better job.

If you’re fed up of the absolute state of things, Sublime Text still works.

This is all very much in line with the post about TextEdit from a while back.

I do care who develops good software since, at the very least, I want to give them credit. This is the best I could find, if you too are curious. It was prompted by someone asking:

I’ve been a Sublime Text user for over a decade, and now a Sublime Merge user, too. But it occurs to me that I know almost nothing about the team/​company behind it.

I wonder if this is a nice example of the (quiet) posture of the company matching the (utilitarian) personality of the software it is making.

iPhone’s home button and then the swipe up home gesture are so important and well done that they probably need to be covered as Unsung Heroes, but I wanted to mention something else today as we’re revisiting the whole “app icons in squircles” story (my most recent post + Louie Mantia’s post).

The first iPhone in 2007 put apps as squircles on the home screen, and it also put a matching shape on the home button:

The shape on the button didn’t survive very long. It was removed starting with iPhone 5S in 2013, which introduced Touch ID – I guess it wasn’t possible to print the icon atop the button without sacrificing the finger detection accuracy. Then, in 2017, the button itself disappeared with the iPhone X.

The iPod Touch was the iPhone without the cellular radio – it was made from 2007 to 2019, supported all the same apps as the iPhone, and sported a home button with a squircle up until the end. (Ironically, despite its name, it never got a Touch ID.)

But there was another iPod that entered the app fray. It was the iPod Nano, whose last edition from 2012 had a home button – except it looked slightly different:

What was the reason? I don’t know if Apple ever explained it, but I believe the idea was that this iPod did not have downloadable apps, nor the App Store, nor even iOS. Those were all built-in apps, and I imagine Apple wanted to indicate visually that they’re different. Because it wasn’t just home button. The apps – eight of them, across 2 pages, although you could rearrange them! – all sported circular icons:

I don’t know if this approach was in any way effective, but I found it a funny little footnote.

Some years ago, the inimitable channel Technology Connections posted a 17-minute video about the peculiar design quirk of ceiling and room fans – they usually order their options Off → High → Medium → Low rather than the more natural Off → Low → Medium → High. The video is a bit off topic for this channel, but check it out if you’re interested how sometimes weird physics considerations influence design in the real world:

In the video, the host also talks about the more natural order that typically looked like this:

I wonder if you recognize this kind of an interface. I have a distinct memory of it from radios (where “zero volume” would mean “off”) and from TVs/early computer displays (where “zero brightness” meant “off,” too). There was something special about these controls that stuck in my memory, motor and otherwise: this tangible, heavy click when you ventured outside or back into “off,” almost as if you had to break the interface itself.

I thought this, too, was a convention from an old analog time. Yet, I keep occasionally finding the “the first notch is special” interfaces on screen.

Sometimes, they are pretty literal translations of the concept, like when you adjust the key repeat rate in macOS:

Or, similarly, when you choose the dock magnification:

But sometimes they are a bit more conceptual. Here, Nova treats the first notch of the zoom scale as a “list” option:

Or: The new horizontal tabs in Chrome allow you to resize to whatever width you want. Below 125px, however, they snap directly to the minimum 55px width, a one-off “column view” with streamlined and purely iconographic controls:

These all have pros and cons, too.

On the con side, just like the fan or volume controls, they miss any memory since turning them off physically moves the knob away from any “value”; if on/off was a separate button, you could just leave the radio at your preferred volume and never touch it again. They also won’t be as discoverable as a separate onscreen toggle would be. (Here’s an example of a more classic treatment from the Nothing Phone.)

Pros? They are compact. They allow you to change from “off” to a value in one quick gesture, skipping an explicit “on” step. You could even argue they are simpler also in a visual sense.

But also, they are a bit… magical. I don’t know. That’s what to me unifies those old physical controls and their newer digital equivalents – they’re a little extra, a little different, a little special. They break the monotony of a predictable interface built out of boring, identical components. (Although, sadly, not a single onscreen example above uses haptics!)

And I think that’s kind of nice. Not just in the very functional sense of breaking up the UI through shape coding etc., but also in a sense of making UIs more interesting.

Speaking of volume, macOS used to show it as a sort of a HUD, using a treatment that borrowed from both the “first notch is special” radio knobs, and from early onscreen interfaces in TVs:

But after 20+ years, macOS Tahoe changed it so it now looks this way:

I can understand the argument that this is more consistent, and that it even teaches you – by proximity – that Control Center is what these controls call home. Yet I can’t help but think (and it seems I am not alone) that this is so boring and exactly how Windows would approach things – and that this change, just like the squared icons, is how macOS lost one more bit of magic.

The post about the dark mode toggle reminded me of two similar things rattling in my brain.

On the positive side, here’s a delightful interaction from macOS. I can easily maximize the window to take up half the screen, but the moment I start dragging it, it recalls and nicely restores itself to its original size:

macOS designers correctly figured out that the window being maximized or half-maximized is a state – but it has to be a state dressed up as a size. The button entry point is the “state” version. But on the way in, there is also a more natural “size” version: you can have the window snap and maximize to half screen when you drag it to the right edge. And on the way out? You just saw it. You don’t have to switch the state to “non maximized” first, and you don’t have to restore to the original size by hand.

Here’s a bad example – one of the macOS’s horrible settings pages:

So far, it seems good. Some of the toggles are on, some off. You not only see a position of the switch change, but also the track under the switch is a different color to help you disambiguate. Nice.

But now look what happens when I toggle off the second option, which the third and fourth option rely on:

Processing this dialog visually, does it look like “on, off, disabled off, disabled on,” or does it look like “four toggles, each one inexplicably with a different shade of gray”?

There are many solutions here: some visual, some IA, some systemic. Also, I use the graphite accent color, which somewhat exacerbates the issue, although it’s there with any accent color.

But I wonder if one of the challenges here is that someone thought it’s important to show the state of the toggle even if it’s disabled, and everything else followed from that. This feels similar to the dark mode essay in that there will always be someone making that argument, and that argument will always feel stronger, because it will feel like it’s backed by logic. The system will make sense as a diagram. Each of its parts will come from a logical conclusion. So did the tri-state dark mode toggle. Or the Power/​Sleep/Wake keyboard buttons. Or Abort, Retry, Fail in DOS.

Arguments for systemic completeness are always going to be easier to make than arguments for thoughtful simplicity.

I sketched two possible solutions. They’re not the best ones, and you might recoil at them, since either one is a compromise. But that’s the point.

On her blog, Lea Verou makes a case that each user-facing website dark-mode toggle should only ever show two options, but in a smart way.

The challenge is that any dark mode toggle needs to actually accommodate three options: dark, light, and the default “whatever the system says” (which can be always dark, always light, or change with the time of day). Many toggles simply pass that complexity onto the user:

I want to get something out of the way: I don’t think Verou’s article as an article is fully successful. I feel like it spends a great amount of words to explain something not entirely as complex, and even the interactive playgrounds felt slightly too rigid and altogether confusing. If you care about (interactive) explainers, it might be an interesting case study in and of itself.

But I am very much much on board with the proposal and the line of thinking it represents. Verou suggests a “smart” dual state toggle, which still allows the website to follow the system, but shoves the complexity of the “whatever the system says” branch into the crevices between visible UI. Here’s how I understand it:

• The smart toggle only has two options: light and dark. Mechanically, clicking or tapping the toggle brings you to the opposite option. Simple.
• If your new option is the opposite of system (e.g. you switch the page to dark mode if your system is in light mode), it will stay in that theme forever, no matter what the system does in the future.
• If your new option is one that currently matches the system, it will then continue following the system in perpetuity (e.g. it’s back to the default behaviour).

This toggle will feel compromised, and you might immediately find some rare use case it doesn’t fully support – maybe attached to an imaginary user, or even an internal user giving you feedback in person. But Verou is absolutely correct in her insistence to fight through that:

Tri-state toggles are implementation-driven UI. One of the most common UX mistakes is designing UI around the underlying data model instead of user goals. Good interfaces abstract away the underlying model and expose a model that aligns with user goals (unless of course these happen to coincide, which is rare).

Now, it’s just a dark mode toggle. It might not seem like a difference between a smart dual state toggle and an explicit tri-state toggle is that much. But:

• “Whatever the system says” is not just one extra option. It’s also one extra weird option. It doesn’t feel like the other two. It’s seemingly repetitive. It’s often unclear what it does before clicking. It’s not obvious where to put it in order. Verou doesn’t mention this in her post, but even just seeing the word System next to Light and Dark feels complicated. (Auto is slightly better.) The cognitive load here might be larger than it seems.
• What is an interface if not a collection of a million challenges, each one seemingly insignificant on its own? Trivial things add up. One compromise here and one cheap decision there, and soon you’re talking real money.
• Thinking deeply about something like this gives one practice for dealing with complexity elsewhere, and facing even more difficult challenges where the stakes are higher and the compromises larger.

A similar example might be that of PC keyboards in the late 1990s, which also exposed system complexity and pestered people with Power/​Sleep/Wake keys:

Computers do not do that anymore, simply having a smarter singular power button, piped to a more sophisticated logic underneath.

From Marton Barcza at TechAltar, a good 12-minute video analyzing what went wrong with the famed Live Tiles that Microsoft was pushing throughout most of the 2010s:

Now, among Windows Phone fans the pervasive opinion is that Live Tiles have failed because Microsoft did a poor job with them, which I think is at least partially true – after all, even many key Microsoft apps like Skype had broken Live Tiles half the time, the Windows 10 start menu was filled by Microsoft with Live Tiles that were clearly just animated ads rather than showing you something actually useful, and the company of course never built out any of their advanced interactive concepts either.

But while all of that might be true, the fact that every major company has walked away from this idea and nobody else has picked it up since, means that there probably are more fundamental problems with this idea. And I can think of three distinct ones:

• user experience,
• form factors,
• and horizontal integration.

Barcza goes on to talk about some specific interactions and problems, and arrives at the conclusion that Live Tiles ended up at this unpleasant intersection where they’re tried to be icons, widgets, and notifications all at once, not doing a particularly great job at either task. That, and there were also challenges with the design primarily being mobile-first, and struggling surviving a jump to a large screen. (Live Tiles were abandoned in 2017, at which point desktop Windows reverted back to what it was before, and the mobile/​tablet lines were altogether disbanded.)

What I found interesting in watching this today is that it feels Apple has made some similar mistakes in their Liquid Glass approach and wider platform unification desires (see: macOS Settings). Both these and Live Tiles attempted to create A System Of Systems, and both ended up occasionally feeling like they awkwardly crowbarred some wider concepts into places where they didn’t truly belong.

If it helps with your further research, I understand Live Tiles were part of a bigger UI effort called Metro and started in earnest with Windows Phone.

Minimaps are an interesting UI element because they often feel very exciting – something about things being small, or responsive, or maps just being cool? – but fail to actually be useful.

I find minimaps for coding particularly tricky because, at least in my world, code all looks very much the same from far away. Seeing a thumbnailed/greeked version of it felt just like a more expensive and distracting version of a regular scrollbar, without any benefits.

But Xcode does something interesting. It allows you to use MARK to create a sort of a “header” for the minimap anywhere you want:

The minimap then shows those headers not greeked, but as human-readable text:

I thought this was clever, allowing you to see the bird’s eye view of the code not just in the most obvious visual sense, but also as a sort of “table of contents,” adding so much more utility.

This, of course, is technically no longer a “zoomed out view” but then again, it’s not that there is some sort of rule that it has to be. As a matter of fact, quite the opposite; it all reminded me of the famous London subway map by Harry Beck, which also broke the expectations in a similar way.

The original, geographically accurate map of London’s tube looked like this:

Beck decided to take liberties with the geography and reimagine the map as a diagram to help the travellers, and ever since he’s done so in 1933, many transit maps followed suit:

Sopwith is a 1984 videogame made by David L. Clark for the original, seminal IBM PC model 5150. It sports the distinctive 4-color CGA palette and an equally distinctive PC speaker soundtrack.

It’s also one of the oldest videogames still in active development, and I was surprised how enthralled I was learning about it.

(First of all, you can play Sopwith in a browser. Choose “single player” and then “novice” first for the game to tell you about its unusual keyboard control scheme.)

The current maintainer of the effort is Simon Howard. He wrote about Sopwith’s interesting history; I appreciate this kind of approachable and caring preservation of obscure titles. The history is worth a read.

From that, I learned a fascinating factoid. The game was intended as a demo for networking hardware, and the original author didn’t realize the game was “in circulation” for many years:

Intended as a trade-show demo, it’s unclear how Sopwith escaped to the general public. David L. Clark didn’t even discover until around 2000 that it had “gotten out”. Little did he know, Sopwith had been circulating for years in collections of early games for the IBM PC. Only a couple of years after the first version was released, ads were appearing in magazines like PC Magazine advertising Sopwith for sale as part of collections of games for the IBM PC

The modern edition started by Howard is called SDL Sopwith (SDL being a cross-platform graphics library):

SDL Sopwith is directly derived from the source code to the original DOS versions, and still includes changelog comments that date all the way back to 1984.

What I particularly liked about the contemporary Sopwith is its guiding document/​philosophy page, also worth checking out in full. Here are some choice principles:

• Sopwith has a long history that deserves to be honored and preserved. By default, the game should always play like the original DOS version. That means the gameplay in particular should be the same, without any significant differences. Someone who has just discovered the project should find it to be a delightfully accurate recreation of the game they may have played when they were younger. […]
• Some new features can be enabled by default, as long as they are subtle, unintrusive, carefully considered and can be turned off. An example is the medals feature.
• The game will never try to be “something it’s not”. This means that it will always have four color CGA graphics, PC speaker sound effects and a low resolution display. It will never add (for example) hi-res sprites or 3D models, digital sound effects or MP3 music. The goal is to be “a great old game” rather than “a mediocre modern game”.
• New features should be fun and recognize the comical aspects of the game. Features should be carefully considered before being incorporated, not just added arbitrarily and thoughtlessly.

There is something in all this that I feel a lot of software could learn from – not just vintage games. I appreciated Howard being thoughtful about growing Sopwith without forgetting its roots, but also with understanding that some things have changed since 1984. You could imagine remixing “The goal is to be a great old game rather than a mediocre modern game” to something like:

Better be a great focused app than a mediocre sprawling app.

Lastly, how did I learn about Sopwith? Howard shared this charming installation visual with me:

A strange thing happens when you press Enter on an empty item in a list in most text editors – the entire list item disappears:

This feels counterintuitive. Isn’t Enter for committing and adding more things? Wouldn’t Backspace be the right key to press to break a list?

Yes, and no. I am not sure who invented this pattern (I spotted it first in Word 95), but that someone understood a strange interaction contract existing in text editing – Enter is actually an escape hatch. In text editing, no matter where you are, you can always press Enter multiple times to just create more room for writing.

In an app that doesn’t cancel a list on Enter, you can face a terrifying moment where you get stuck in a list, and getting stuck is never fun.

This principle feels so useful that I see more and more apps apply a version of it for other things. For example, in many modern text editors pressing Enter after a headline returns you to regular text, just so it’s not as easy to get stuck in a headline style:

An interesting 20-minute Config talk from the Instagram designer Rose McManus:

It covers some of the same areas we recently talked about: diacritics and Polish S (and a fun video about English conventions from a while back), but it tackles them on a higher level. McManus talks about how people express themselves via their usernames, how that changes in various countries of the world and for what reasons, how it intersects with some UI considerations, and how people use it creatively – and also, sometimes, abuse it.

This is the K-pop star IU. Uh her Instagram handle is “dlwlrma.” And I think at first this maybe seems already like complete hyperreality, like it’s bearing no relationship with her Hangul name, or even with her stage name. But actually, I think this is at the third stage of Baudrillard’s theory because really “dlwlrma” is Lee Ji-eun’s Hangul name typed out on a Korean keyboard but backwards, distorted, while that keyboard is set to render Latin characters, almost like a cipher. And then her display name is her Hangul name typed out with one of the characters changed, so it’s like a pun.

I didn’t feel the talk stuck the landing – in the end, I wasn’t very sure why the decision that was made was made. But there’s a whole lot of stuff before that was fascinating and thought-provoking.

Mac’s operating system has a peculiar way to install apps. An app typically arrives in a file with a .dmg extension (it stands for “disk image”; my brain always reads it as “damage”), which upon double clicking becomes a kind of a drive. You go inside the drive, and there is the app icon.

But the journey isn’t over. While you can run the app from the virtual drive, the drive will eventually disappear after the reboot – or if you eject it – so it’s in the app’s interest to suggest a more permanent home for itself.

The way many apps choose to do it is by creatively combining a few of Finder’s options. Those options are available for everyone, in any folder, but perhaps not as known. The first stop is removing the toolbar and the sidebar, and any other bars. The second is switching to the icon view, and picking the right window dimensions. What’s needed next is a link to the Applications folder. The last ingredient? A custom background that’s placed underneath and creatively uses the fact the size and the position of all the icons are known:

After this makeover, the Finder window resembles almost a specialized app window, and you can use all of this power to… tell the user to drag the app to the permanent folder:

There are nuggets of something good in this flow – dragging an app icon to Applications is consistent with the other gestures you use to navigate the Mac, and teaches you that the app is just a file that you can place anywhere, or trash when done.

Overall, however, it feels quite a bit confusing, leading to spurious dangling drives, extra confusion, and attendant problems like these:

But I am not here to relitigate the flow itself, but to take a look at a few of those customized Finder windows. They became, in a way, a particular design playground with just enough constraints to make it interesting: an app icon, an Applications avatar, an arrow between the two, a typical size, and a bitmapped background tying it all together.

(Other historical playgrounds that got many designers excited: a calculator app, a weather app, a Twitter client… and outside of pixels, a watch face or a chair.)

Below, I went through many windows to find what I thought were the most well-made or interesting “drag to Applications” treatments.

The arrows

The first obvious place to start playing is the arrow, which can really be any shape and color… or maybe even not resemble an arrow at all:

An unusual direction

That last window shows that although in Western cultures it’s customary for time and flows to go from left to right, it doesn’t mean we can’t choose a different axis. Here are a few more examples:

More specific instructions

You might have also spotted above that some places aren’t content with the arrow itself, and adorn the window with more explicit text instructions.

Here are more examples of that. This one adds a simple two steps, but also perhaps starts feeling like Arrow City:

This one distributes the two steps differently and tries to cover the clean-up also, so you don’t end up with a dangling drive:

This one has a certain “cheapness” to it, but I find its minimalism endearing – the “link” arrow almost serves as the action arrow, and since you can rename the link itself, why not rename it into a set of instructions?

And this one feels like mad libs. Does this work, or is it more confusing to intersperse (passive) instructions and (active) objects this way? I’m not sure.

Scenes with icons

What I also noticed is a fun way that some of these used the dimensionality of the icons themselves, to place them in “the real world.”

Issues with gestalt

These next few feel like they have some issues – specifically with gestalt – and I thought it might be informative to look at them.

The first one has a very strong left-to-right directionality, and I wonder if people try to drag the left blue folder onto the right one?

This one is an interesting lesson in how versatile arrows can be, but also how tricky it feels if you go against the convention:

This I’ve seen a few times – despite the arrow, this still feels like a 2×2 grid of equally important things, or can also be misunderstood as “drag two items onto the other two items”:

And this is a better example of how to accomplish something the above window botched:

Different mechanics

Not all the apps choose the arrow-drag mechanic, and some are not allowed to. Here are other treatments I particularly liked:

Fun visuals

Some apps go deep on visuals. Here are a few I liked:

A modern app called Inkscape does something interesting:

[The Finder backgrounds] are designed by our users on the website in the about screen content. Held with every major release!

So I downloaded all the major releases of Inkscape to show you:

Today

And that brings us neatly to today. I think Firefox deserves extra credit for keeping their Finder install window beautiful and elegant throughout all these years:

And let’s close this off with a few gorgeous modern examples. Many apps these days come from the App Store and skip the Finder flow altogether, but here are a few that still ask you to drag:

That’s it! But send me more if you have them!

Thank you to Chris Messina for creating the Disk Images collection which I pulled from extensively for this post. Additional thanks go to Jean-Michel Durand, Mindaugas Rudokas, Louie Mantia, Colin, mimi, Jeremy Visser, Luke Dorny, Oskars, and Peter Tripp. The title comes from a reaction to one of my social posts where I asked people to send me good examples.

If you’re a professional web app, your key shortcut situation is not to be envied. Once the operating system grabs the ⌘ shortcuts it requires (⌘M to minimize, ⌘H to hide, ⌘Q to quit, etc.), the browser has its turn, claiming everything from ⌘R, T, N, L, W for tab operation, to ⌘F, P, O, and S for other things. And then, some input controls inside the browser also need to listen to ⌘Z and XCV, and maybe even A (select all), B (bold), and I (italic).

At this point things feel barren, and some web apps start reaching instead for less common modifier keys (⇧, ⌥, ⌘⇧), and others go straight to no modifier zone, or override those of the above shortcuts that they can. Each approach, of course, has its own set of challenges.

It’s perhaps not a surprise that someone got fed up, and that someone was people working on the project management tool Asana, which did something relatively unique: it promoted Tab to be a modifier key.

The video shows me using Tab+K to like tasks, Tab+Return to open a sidebar, Tab+Q to add a quick task, and Tab+H to return home. Here’s the entire official shortcut list, with Tab shortcuts emphasized:

What’s fascinating about choosing Tab is that the key already has so much to do:

• it moves focus to the next UI control,
• it indents a bullet point or even just text,
• it accepts an autosuggestion or a placeholder (and similar things).

On top of that, repurposing a key to be a modifier key – especially one that already has a job or two – will also have a long tail of strange consequences. And, Tab is only on one side, which could wreak havoc with the ergonomics of keyboard use. (You are, technically, always supposed to use the modifier key with the opposite hand to the hand you’re pressing the main key with.)

But…

I am not ready to hate it quite yet.

Tab is not the worst key to use in this context, as it’s really the only available big key other than Caps Lock, which is impossible to mess with on the web. The other big keys – the spacebar, Return, and Backspace – would be radioactive for this purpose.

The asymmetry issue? Anecdotally, I understand that both right-handed and left-handed people most often use the pointing device (mouse or trackpad) with their right hand, and consequently often prioritize left modifier keys anyway.

Here is how Asana deals with some other challenges:

• When you press Tab to move focus around, the action can now only take place on key up, not key down, so tabbing (or, indentation of bullet points) feels slower.
• When you hold a regular modifier key and then change your mind and simply release it, no action occurs. But Tab already has a job as a regular key (tabbing or indentation, depending on context), so if you change your mind, something will still happen. This might be annoying. (You can press Tab+Esc or Tab+Space for a safe cancel, but that doesn’t seem very intuitive, especially in a moment of panic.)
• An action only on key up also means there can be no repeat when holding Tab. I am not sure how important this is, especially in the context of accessibility.

What’s interesting and I bet the main reason Asana approached it this way, is that Tab is a separate little island, far away from other modifier keys – and thus not just without any preexisting conflicts, but also impossible to confuse with other modifier keys. Asana could have kept all the shortcuts above but substituted Tab with Ctrl on a Mac and Alt on a PC, but those would then be packed among many other similar-feeling keys.

(There is a price for this isolation, as Tab backfires the moment you have to combine it with other modifier keys. Asana doesn’t do it very often – I have only seen Tab+Shift+D, G, and F – but I wish they didn’t do it at all.)

Overall, I’m surprised how positively I feel about it. If you use Asana a lot, I’d be curious how Tab-based shortcuts feel to you. If you work at Asana, I would love to know if you consider these a success.

The only thing that seems to be missing is an option to go back to regular shortcuts if needed, for people who might want it for motor control reasons. (It is possible to achieve that with tools like Karabiner Elements, but that tool is really unpleasant to use.)

Oh, also. Tab+B does this, because, well, “tabby.” Cute.

Speaking of computers that used to stop running if you looked at them funny, a few years ago I wrote about the Monkey app that was there on the original Mac. Many software engineers will recognize the premise – Monkey was just a chaos script randomly pressing mouse buttons and keys during the night hours, and if the computer crashed because of Monkey’s random actions, the team would be able to reproduce it and try to fix it.

I was also inspired to try a Monkey-like approach for something creative. In hindsight, it’s a very Unsung post, so you might enjoy it!

Also, in the post, I showed this boring version of Monkey:

Since then, I discovered a different version with its own icon, perhaps designed by Susan Kare:

(If creative use of randomness rings a bell, here’s also an earlier Unsung post about a different take.)

Contra the previous post, just spotted this “Same settings, new look!” callout in Firefox, on a page I have never visited before, talking about a feature I have never used:

I mentioned this once – when you get someplace new, everything is new. This redesign announcement’s conditions were engineered poorly, because they didn’t even consider people who didn’t use the feature before the redesign.

I keep thinking of the very old computers from the 1940s, 1950s, and even 1960s, where the challenge wasn’t what to do with the computer, but with keeping the computer running. There was a machine called JOHNNIAC which gained a nickname “pneumoniac” because it refused to work on a warm day. On many other computers, there was a daily ritual of finding which of the vacuum tubes blew up and had to be replaced. Some teams had a literal downtime tax; they knew and communicated in advance that 40% of the days the machine would not be up to the task, consumed by tweaks and repairs to bring it just to the state of being ready to do work.

When I look at those kinds of pop-ups and callouts, I think how we’re unwillingly recreating the very same conditions. I deeply believe people are exhausted not just by changes in software, but also constant questions, pop-ups, unnecessary notifications, “STOP 2 END,” “tell us what you think,” emails to unsubscribe from, unsubscribes that don’t work the first time, and so on.

Software should not require the user to occasionally click on buttons just to keep it running.

I wanted to show you a year’s worth of messages from my barber’s software, because this is what software should be.

No spam, no upsells, no growth hacks, no unwelcome cuteness or puzzling verbosity. It’s so curt and straight to the point it should be set in a 1970s Helvetica: The appointment’s tomorrow. Any questions?

From Robin Sloan:

Yet we should never forget that the product of work isn’t only the work — it’s also the worker. Doing the work changes you; the up-close expe­ri­ence trans­forms your capa­bil­i­ties and even your desires. Insights and ideas emerge from that interface, and I believe the agent mae­stros lose a lot — too much — when they take their big step back.

But I suppose this is just my temperament, which I’ve written about before. I don’t merely want things done; I want to do them.

Tangentially related to the previous post, this 8-minute video from CrowBranch is a fun tier list of various ways games try to keep you in bounds:

The limits here are I believe unrelated to precision, and rather to wanting to keep the player within a controlled, designed environment. (We once covered a story of this backfiring horribly, and also talked about skyboxes and streaming.)

The video also made me want to see people – especially designers with less experience slash less baggage than I have – doing a tier list of e.g. common interface elements. Or maybe I should make such a video…

When you learn computer science, at some point you encounter floating-point numbers in all their peculiar glory. Floating-point numbers allow you to store values that are extremely huge or extremely tiny, but that comes with a strange price. The number is still just a number with a regular limited precision, but is accompanied by a floating point – another number that just says how many zeroes to put after or in front.

In effect, when your number is millions, you get a precision of thousands. When your number if billions, you can only count in millions, and so on. This makes intuitive sense, in a same way a billionaire doesn’t care about pocket change. (Go to a floating point visualizer, and you will see you can input 9000004 and 9000005 and 9000006 with no problem, but add one more zero and 90000004 will be rounded down to 90000000, and 90000005 up to 90000008. Bigger numbers get even less precise.)

This has a strange effect when it comes to videogames or graphic software: The further you move something away from the origin of your universe – where X and Y are 0 – the more you have to worry about its internal precision.

This is not a problem in real world. You can send a tiny, incredibly meticulous watch screw far beyond the solar system and back, and it will do fine. But now jump to the digital world, assume Earth is 0:0 – apologies to Copernicus – and now the further away you go, the more the floating point moves to the left, and at some point the precision of the number on the other side runs out; a value that can express billions of kilometers is too coarse to even consider millimeters.

This is a fascinating problem which is visualized nicely in this short video. This is what happens when you move an object with its constant internal precision further and further away:

There are ways around this – you can increase the precision, introduce a “floating offset,” have two precision centers around two floating points, or do a bunch of other things – but each one will cost you. So, sometimes, the best solution is the simplest one: do not allow the numbers to get too big.

And this is why Adobe Illustrator, Figma, and I bet at least a few other tools that promise infinite canvas, actually stop you if you stray too far away from the center. Precision is like atmosphere, the canvas says, thinning out the further you go. We cannot promise your structural integrity will survive going past a certain point, so we won’t allow you to do that.

Here’s Figma, where I at some point the canvas stops following your scroll commands:

The first invisible X value is 131,072 and it’s not a surprise it’s one of these numbers that will look very, very familiar.

It seems like a huge enough value, but if you consider a slide in a slide deck is 1920×1080, it’s not as infinite as it might initially seem. And this is also why – in part – Figma Slides manually wraps you after 20 slides:

I’ve enjoyed John Gruber’s posts about ads appearing on an increasing number of Apple surfaces: the App Store, Apple News, and – soon, perhaps – Apple Maps. (Just for reference, here’s an example of such an ad.)

In a post earlier this week, Gruber likened ads to stickers on laptops, and shared a fun Steve Jobs story:

That’s what those stickers on PCs are: they’re ads. Intel pays for the “Intel Inside” stickers that booger up PC laptop palm rests. Longtime readers will recall that back in August 2007, Apple held a Town Hall event to introduce new iMacs and some iLife and iWork software updates. In a post-event Q&A (imagine that), Bob Keefe of Cox Newspapers asked “Can you say why you all are not participating in the Intel Inside program, putting the stickers on your new or previous Macs?” This question was so absurd from the perspective of those who covered Apple closely that it prompted outright laughter. […]

The 2007 exchange went as follows:

Keefe: Why are you not participating in Intel Inside program and not putting stickers on your Macs?
Jobs: Uh… what can I say? We like our own stickers better.

(In case it’s not clear, this was a joke; Apple didn’t and doesn’t put any such stickers on their products. They instead used to include Apple logo stickers in boxes.)

In May, Gruber posted about Apple’s ads, too, and brought up the zero-one-infinity rule:

I feel like a variation of Zero-One-Infinity is a good rule of thumb for ads, too. From the perspective of users — and probably developers — zero was the best number of ads for Apple to show in App Store search results. One was worse but acceptable. But now that they’re showing more than one, they’re on their way to infinity. They’ve started down the slippery slope. Remember when Google only showed one ad in search results?

“Slippery slope” is a perfect term. But I wanted to add something here. In my experience, in the realm of UI, there is no middle notch. I’ve seen it time and time again… the moment you open the door to One, Infinity starts exerting its pull:

• adding just one setting will send a message that We Do Settings Now and more settings will follow,
• one uncomfortable exception followed by weeks of deliberations will inevitably open the door to subsequent mindless exceptions,
• one cheap or lazy approach can spread through the interface like rust, subconsciously telling people “cheap and lazy solutions are okay here.”

Here are two examples I’ve been thinking about recently:

• This right click menu in Chrome started with just one fork (new window or new tab) – now there are three alts that I have to choose between, every single time, even if I only ever use one option:

• This – screenshotting in iOS – was originally just one fork: Save or Delete. Now it’s a staggering five options I have to choose from, every time, even if I never touch four of them:

Once you wedge one thing in the door, it’s really hard to stop. My theory is that this is because digital interfaces are pretty much all infinitely extensible. There will always be a way to add one more button, one more link, one more setting, one more ad. If something doesn’t fit, you make it smaller. If making it smaller looks bad, you add a scrollbar. If a scrollbar doesn’t feel right, there’s always overflow.

Not only is it very hard to create interfaces that have limitations, but a bad decision is not just precedent – it’s code that can be copied and reused. Existing code always had tons of… well, gravity, even before LLMs.

And so, products grow complex without anyone intending them to; a new team adds just one more thing, which in isolation always feels like nothing to worry about. The Hick’s Law, the extra mental load, the weirdness all grow in between those moments, in a no-man’s land no team typically feels responsible for. The logic is always circular: Why would the team adding a third option have to do something a team adding a second option didn’t have to do? Why would the team adding the second option worry in advance about option number 5?

This is why it’s important to hire and recognize people who will understand that those limitations have to be imposed arbitrarily, and empower them to be able to say, “Let‘s not add this. We like our own stickers better.”

My MacBook does have a sticker, which I bought and put on it since for some reason I find it really funny.

An interesting short story from Ernie Smith at Tedium, who ventured out to do the opposite of what we usually cover on this blog – disrespect his motor memory:

Recently, I made a realization: I have been unwillingly addicted to Facebook for a long time, and it’s not even because I like Facebook. Rather, it’s because I find it an extremely easy URL to type into a modern web browser’s omnibar. This sounds crazy, but the first two letters, f and a, are on the home row, and I don’t really rely on bookmarks, but my browser’s history function to type in URLs.

This creates a sort of recency bias. If I type in the same URL a lot, it’s the one that pops up the most. And so, if I’m at a browser with no clear idea of what my intent for the next page I load up, I inevitably type in “fa,” which would suck me in. […]

So, what I ended up doing was creating a URL that does nothing but forward to Google News. […] The result is that whenever I type in my new Facebook URL, I go to a news aggregator, which is inevitably what I was using Facebook for anyway. A week later, and my Facebook usage has gone down considerably.

There is something really interesting about creating your own URL for a purpose like this. Smith doesn’t disclose his, but you can imagine it’s something like facebook.aresluna.org that just redirects to a news aggregator. If creating a new URL is too difficult, there are always other options:

Wanna go to fatberg.com every time you load your computer? Or maybe faxtoy.net?

This is a good example of some of the challenges with “recent” interfaces I am such a big fan of. If you’re designing recents and you think they can turn against the user or otherwise get in their way, it’s good to offer not just a “clear recents” feature that gets rid of them all, like here in Apple’s Music…

…but also individual clears, like here in Bluesky:

I don’t know if this is true for all the browsers, but in Chrome and Safari, you can also clear individual suggestions this way:

Smith writes a bit more about the addictive nature of computers, but I’ll let you read on your own.

Nice moment in Slack and Medium – when logging in, the login code that arrives via email is already there in the subject, in addition to hiding inside:

This feels good for two reasons. One is the obvious one: you see the code earlier, it might show up in a notification, etc.

But also, this should prevent multiple login codes to be threaded as a “conversation” inside your email client, since threading is based on the email subject – and threaded utility emails can be extra confusing.

Over the years, I acquired this weird collection of almost-invisible, but important signifiers of when I know a product really focuses on craft and thinks about its users.

I thought about one recently. Here’s what happens when you try to copy a long block of text from YouTube’s (otherwise very useful) text transcript pane:

And here’s an analogous example from GitHub:

GitHub’s arrives ready to go. YouTube’s throws in a lot of messy things in between the lines.

Why does it matter? Because these both feel like places you’ll be copying a lot from, and dealing with a messy paste can feel so, so unpleasant.

You have probably seen this chart before, from xkcd:

This is the fabled automation trade-off, or the high fixed cost vs. low variable cost dilemma.

Yeah, if you’re doing a lot of copy/​paste, you might invest in creating some sort of a clean-up step, or even going through a programming text editor which has multiple cursors or other casual automation. But what if you don’t do that often, or if you don’t even know how much time it’d take you to automate it? Then the investment seems scary or insurmountable, and you’re stuck doing something like this, time and again:

And it’s really nice to encounter a place like GitHub, where the team was thoughtful enough to save you all this trouble.

There is also an asymmetry that’s worth pointing out. I believe making this good doesn’t have to be a lot of work for people putting these surfaces together. Here’s me fixing the YouTube situation with two simple lines of CSS with user-select: none:

I don’t know if it’d be as easy for all big text block situations, but I think it’s good practice to look around a bit and think about what are tiny things that you can do on your side that will save your users minutes or hours of tedium (see also: recents and paste and even more recents).

Julian Fong, a software engineer at Pixar, wrote a short thread on Mastodon with an interesting take I haven’t seen before:

I still don’t use any AI code in my work, but I have to review more and more of it these days. One of the things bothering me about that these days is just how lacking in personality that code is.

RenderMan is a code base which is now over forty years old. It is a collection of idiosyncratic styles written by equally idiosyncratic people.

I’ve been in this code base for 26+ years and I can recognize the author of many chunks simply by looking at indentation, comments, or coding style. And I can often map style to personality quirks of the author.

Dan McCoy’s code for converting general polyhedra from 1990 still survives today. Probably one of the few pieces of code left that actually has a for ( ; l; l = l->next) loop for linked lists. Dan is also the only person I’ve ever seen use the abbreviation R.N.G in comments.

Tom Duff is the inventor of the Duff Device, so you can imagine what kind of code he might write. But he also left a comment in the implicit field code which was a quote from the Preface to Samuel Johnson’s Dictionary, from 1755. That’s just who he is.

(In a fit of hubris, many years later when I refactored the code, I left an answering comment which was a quote from the Preface to Noah Webster’s “An American Dictionary of the English Language. I’m not sure Tom ever noticed this.)

I was just thinking of Duff’s Device the other day!

I’ll let you read the rest on your own, but will excerpt the ending, too:

I could go on and on about all of our recognizable quirks, but living in a code base with that history is like living in a Berkeley Craftsman home. It’s old, it’s creaky, okay, it’s missing AC and you’re probably going to die when it hits 100 in the summer (which happens all too often these days), but dammit, it’s charming and it’s artsy. […]

[With Claude-generated code] there’s no typo or quirk that immediately recalls an interesting whiteboard discussion in the author’s office. It’s just code and comments repeating what the code does.

Code is art. I work at a studio full of ungodly talented artists, but I will still die on this hill. Code is often messy and dirty and it’s a pain to create and get right but the results reflect the personality of the creator and the pain of the creation. Just like the rest of art. Sometimes you have to look at the source code to see that, but it’s there if you look for it, hidden beneath the surface.

In the era of the telegraph, a century ago, you could listen to the dits and the dahs and decode the literal message, but you could also pay attention to the rhythm and the timing and the quirks of someone’s particular finger on someone’s particular Morse key – and learn to recognize not just a particular person, but also, sometimes, even their mood. There are stories of Allied spies knowing exactly which of the German operators they surveilled (but never met in person) was sending messages at a given moment, just by learning their tapping style, known as “fist.”

I found it delightful to read Fong’s stories of his coworker programming fists.

In early 2023, Dan Olson at Folding Ideas made a scathing, smart, almost two-hour-long video essay about Decentraland, the metaverse that was one of the poster children of the web3 era:

Most of what Decentraland does, and what it fails to do, are things that would be considered forgivable or quaint in a Kickstarter MMO that had clearly bitten off more than the creators could ever chew, but given that this is a project founded on cryptocurrency, all of those foibles are laced with the language of finance and landlordism. Strolling down Decentraland’s spacious boulevards at 5 frames per second rewards the user with a seemingly endless parade of virtual billboards brightly proclaiming that the space you see is all available to rent.

In May this year, Nick Heer at Pixel Envy wrote a copiously annotated birds-eye overview of Meta’s metaverse attempts thus far, in an essay called The Metaverse Fever Dream:

Officially, Meta is still all-in on the concept around which it pivoted the entire company in 2021. It still has a whole marketing page proclaiming its belief “in the future of connection in the metaverse”. You can go shop its lineup of Quest headsets which Meta says represent the best and most immersive metaverse experience, though its flagship model is now two-and-a-half years old. It has awkwardly promoted its Ray-Bans as “A.I. glasses” despite them becoming the company’s most successful line of mixed reality products, and it is desperately trying to connect its newest muse of A.I. with its last one. The single mention of “metaverse” on its Q1 2026 earnings call (PDF) is when Zuckerberg claimed to be “excited for more of our metaverse efforts to be powered by the A.I. models we’re training as well”.

I linked to Meta’s metaverse reviews before, but I thought these two (very) deep dives are great to invest in, side by side. Both of the failed metaverses look similar only on the surface. They were spun by very different organizations, started with different goals and premises, and their creative and maybe even ethical bankruptcies have a very different dimensionality.

In the context of this blog, it’s also interesting to reflect on how poorly they’re both made, which is extra fascinating given the disparity of budgets of the efforts. My guess would be something like this:

• Mark Zuckerberg and Meta’s leadership do not understand design, so even though there might be a lot of talented designers at Meta, their efforts do not end up mattering as much.
• Decentraland is ostensibly “open source” – or at least open-source-flavoured – and open source generally struggles with attracting talented designers.

These are two interesting and distinct failure modes – although, as the essays make abundantly clear, no amount of design talent, execution, or craft could turn successful an idea whose entire premise is a house of cards made out of newsprint-grade paper and magical thinking.

Here’s a nice moment in Logic Pro, a music app. Like with most such apps, you can press R to record playing an instrument. However, if you forgot to start recording, or were just goofing around and stumbled upon something wonderful, you can press ⇧R and the recording will appear anyway, as if you had a time machine. This is a quick TikTok video showing it in action:

The feature is called Flashback Capture. Of course, just as it was with undo send, this is no magic. The app is always recording the events quietly, and then offers you to make them “real” if you want.

I dug around and found a support document that offers a rare view into the mechanics of this feature, which are slightly more sophisticated than I imagined:

When playback is stopped, Flashback Capture creates a separate region containing all the MIDI events received since the last playback. However, after a pause of 20 seconds between incoming MIDI events, those initial MIDI events before the pause are discarded. If when playback is stopped, you perform some MIDI events and then pause for 1.5 bars or longer, those initial notes aren’t included in the visible part of your region. If you do want those MIDI events to be included in the created region, you can drag the left region boundary to expose them.

What it seems to say is:

• If there is a longer pause within your play, the notes are still recovered, but hidden. You can always drag to reveal them, but in effect, only the most recent of your notes are immediately visible – a nice touch. (The moment you start dragging, it also shows you a quick preview of where you’re going, which is extra thoughtful!)

• If the pause is 20 seconds or more, all the notes before that pause are no longer preserved – presumably to prevent too much wasted data in your file.
• However, after you stop playing, you have infinite time to invoke Flashback Capture and recover the notes.

This seems like a good and thoughtful feature that prevents data loss, a sort of magical “reverse redo.”

Thank you to Chris Krycho for telling me about this feature, which is apparently also available in other music apps, e.g. Cubase and Dorico.

A fun 16-minute video from PortalRunner with this premise:

This is an image file, containing a picture of my cat. But if I rename it to .MP4, it becomes a video file – also of my cat. If rename to .PDF, it becomes a text document containing the script for this video. It can also be a valid webpage, a .ZIP archive, or a PowerPoint presentation, all by simply changing the name. This kind of file is sometimes called a “polyglot” (although, usually that term refers to code that works in multiple programming languages).

This kind of a file is not something that you will realistically need, but it’s a fun look into various approaches to headers and structures of file formats – something we don’t usually get to think about a lot.

Buried inside the video is also an interesting digression: is the file extension just a method of delivering the file to the right application? If I rename .jpeg to .gif, and both are routed to Pixelmator, should Pixelmator do its best to detect it’s a JPEG file under the hood, or fail with a “this doesn’t look like a GIF file” message?

The web has a similar challenge in the form of MIME sniffing – “MIME” is sort of the web’s equivalent of extensions, “sniffing” means detecting the file from its contents alone, ignoring everything else – and that had some security considerations, as it allowed bad actors to sneak in some malicious code under the guise of something more innocuous… basically what the video is doing for fun, but now weaponized.

This is all pretty technical for this blog, but inside the Wikipedia entry for MIME sniffing is this passage that caught my attention:

[MIME sniffing is still used by some browsers. However,] by making sites which do not correctly assign MIME types to content appear to work correctly in those browsers, it fails to encourage the correct labeling of material, which in turn makes content sniffing necessary for these sites to work, creating a vicious circle of incompatibility with web standards and security best practices.

Decades before MIME sniffing, Jon Postel captured the essence of that line of thinking by coining Postel’s Law – “be conservative in what you send, be liberal in what you accept” – but as enticing as it is, that has challenges similar to the above quote:

A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. […] Ensuring interoperability in this environment is often referred to as aiming to be ”bug-for-bug compatible”.

While Postel’s Law was about data flowing in and out of computer systems, the premise is to me a more evergreen design question, applicable to so many other things. Feeling “liberal in what you accept” can feel helpful, but can teach users bad habits and have bigger consequences. For any project where this applies, it’s worth asking: should we go out of our way to help the user even if they mess up, or should we be more rigid and teach them to follow the rules more strictly, as it will benefit them in the future?

The Command Line Interface Guidelines I linked to before had a great example of that:

You can ask if they want to run the suggested command, but don’t force it on them. For example:

$ heroku pss
› Warning: pss is not a heroku command.
Did you mean ps? [y/n]:

Rather than suggesting the corrected syntax, you might be tempted to just run it for them, as if they’d typed it right in the first place. Sometimes this is the right thing to do, but not always.

Firstly, invalid input doesn’t necessarily imply a simple typo—it can often mean the user has made a logical mistake, or misused a shell variable. Assuming what they meant can be dangerous, especially if the resulting action modifies state.

Secondly, be aware that if you change what the user typed, they won’t learn the correct syntax. In effect, you’re ruling that the way they typed it is valid and correct, and you’re committing to supporting that indefinitely. Be intentional in making that decision, and document both syntaxes.

I got pissed at Chrome the other day. This is not the first user-hostile thing Chrome did – off the top of my head, I remember the updater fiasco from some years ago, and the more recent auto-installation of a 4GB file – but as you’ll see, this one is squarely in my wheelhouse.

The transgression: Chrome took over a shortcut on my Mac – Ctrl+G – and it used it to throw me into Chrome’s version of Gemini that I have never used or was interested in using. Moreover, it decided it’s okay for Ctrl+G to put me there even if I pressed the shortcut outside of Chrome.

I was never asked by Chrome if it’s okay to do so. The way I found it installed it was in a very unpleasant way: I tried to use Ctrl+G in my coding editor to jump to a specific line, and I got this instead:

Stuff like that can make you feel like you lost your mind. I have no idea what this window is supposed to do, where did it come from, or even – initially – why it appeared. Note that it doesn’t even identify itself as either Chrome or Gemini, unless you read the scary caveat. It feels like the UI equivalent of breaking and entering.

Unsurprisingly, the pop-up doesn’t confess to stealing the shortcut, or allow you to toggle it off in any way:

It is possible to undo that behavior, but one has to connect it to Chrome first, and then go deep into its settings – first by clicking on “AI innovations,” and then by clicking on “Gemini in Chrome” – to find it:

Let’s not beat around the bush: This is effectively malware behaviour. It’s bullshit. It’s cancer. It’s deeply disrespectful toward the user. It’s prioritizing hollow metrics at the expense of everything else. But I don’t want this blog to chase news of the day or feed the outrage machine, so let me try to turn my anger into something useful.

We can start here: There are some global keyboard shortcuts that are genuinely good. A video call mute shortcut, screenshotting, “next slide” if you’re presenting in Zoom. Everything related to computer operation – volume, brightness, media transport controls – needs to be available regardless of focus or context. (In my keyboard customization essay, I introduced my own global keyboard shortcuts, for example for scanning the next page.)

But, an app installing a global keyboard shortcut without user consent is bad. This can never be anything other than opt-in. At the very least, Chrome should have shown me a clear UI that said “We’re thinking Ctrl+G would be fun for you to use. You okay with that?” and a button for me to press to confirm.

(Note: Ctrl+G is the shortcut for Macs. As far as I can tell, on Windows it is Alt+G.)

From people’s reactions, it seems this shortcut is auto-enabled for a subset of users – perhaps people who used Gemini before, or people on a plan that happens to include it. No matter how specific or small that group is, or how useful they might find the Ctrl+G pop-up, the issue remains: I have never consented to the app doing this.

I also partly blame macOS for ceding its responsibilities here. Mac’s keyboard customization features are a mess, and Mac doesn’t have a modern command repository. It’s not just that apps can register global shortcuts as they want, without the user knowing. It’s also that there is no shared inventory of them; if an app “swallows” a shortcut but does nothing noticeable with it, it can be really hard to figure out why a shortcut seemingly just stops working.

(Other apps that I remember having problems with “stealing” global shortcuts, and apps that a few readers posted are: 1Password, Notion, and Perplexity. I’d be curious if you have other examples!)

In light of macOS’s deficiencies, as an app, if you offer any shortcut customization – especially if you allow global shortcuts – I think it’s important to have a page that lists all of them shortcuts in one place. This is not what Chrome does, as various shortcut options are hidden on various pages in settings. Even Zoom, which is not generally known for having a great user interface, does better here:

And, since we’re back to Chrome, what a fall from grace! When Chrome started in the late 2000s, it felt like a browser that had user’s interest in mind, and protected people from ill-behaving websites. Today, it’s the operating system that needs to protect us from Chrome.

Also, don’t call a tab “AI innovations.” It’s tacky as hell. The market gets to decide what’s innovative and what is not.

A computer science professor Paul Cantrell, on Mastodon:

Creative work keeps taking roughly the same amount of human labor / attention / care, even as new technologies accelerate or remove things that used to take time.

This is because creativity is fundamentally not an efficiency problem; process is not just the means of producing output, but rather a labor vessel that holds the near-invisible work that is truly important.

One can feel the care that goes into creative work without being aware of that work, or even being aware that work of that type exists at all. This feeling is approximate, loose, vague, but cumulative and eventually all-important; work with no care behind it wears thin and tends to fade as people live with it over time.

This really resonated with me.

Elsewhere, Ginger Bill, in a recent – meandering, but thought-provoking – essay titled “Good tools are invisible”:

I constantly see some people praise it not for what actually makes it good, but by taking the things it’s bad at and turning them into a puzzle to have “fun” solving.

I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script. […]

That’s what I mean by “invisible tools”. When you’re proficient with your editor of choice—whatever it is—it disappears into the background. But the moment it cannot handle something easily, it stops being invisible. What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great. […]

The text-editor-macro anecdote I mentioned is really about a gap between feeling productive versus being productive. There’s a sensation of cleverness that comes from solving a fiddly problem, and it’s easy to mistake that feeling for actual output. A tool that makes hard things feel heroic and clever feel like an achievement can register as “powerful” while quietly being slow. The honest test isn’t how engaged or clever you felt, it’s wall-clock time and how many mistakes you made getting there.

This I had more of a mixed reaction to.

I think it’s necessary to expect from tools to get out of the way, but there’s also nothing wrong with having fun with them.

My simple go-to example is this: When writing code, I sometimes use Find & Replace All, and am done within a few keystrokes. But sometimes, I press Find and then replace one at a time, jumping methodically through the file, and seeing each string in situ before changing it. I know the tool could do it all for me. I know I could be more efficient. But this intentional slowing down allows me to refamiliarize myself with the code, visit its forgotten nooks and crannies, and make sure I understand where and how the thing I’m changing is actually used.

The editor I use allows me to not be efficient when I choose not to be. In my work, flow operates at different speeds; a good tool understands that and doesn’t force me into a particular one.

I think ultimately indeed, the tool does need to disappear, and make you be in charge of whatever speed you want to operate at, and how much friction or difficulty you choose to face (do you bump the lamp or not?). But it’s not as simple as always “reducing wall-clock time and mistakes.” Like Cantrell says above: Creativity is fundamentally not an efficiency problem.

Around the time I was writing about iPhone’s Safari breaking the expected “tap to jump to the top” gesture, a conversation on social media pointed to yet another thing that this tab control does strangely.

A typical use of Safari means two groups of sites: a regular set on the right, and “private” pages on the left (this is what Chrome calls “incognito mode”):

As expected, you can tap on either label, and switch to the relevant group with ease:

It also feels like you could slide it – and you can, except…

…you immediately encounter a Scroll Lock problem. You are not dragging the pill – you are dragging what’s underneath the pill. To switch, you have to go the other way:

You can immediately intuit some inherent unpleasant complexity of the whole system – not just in it “going the wrong way,” but also in how it creates room and then contracts it, in two separate steps, after you’re done.

The reason is that you can actually have more site groups than just the initial two. You can even drag to where the new site group would be, and create it this way:

I normally welcome these kinds of accelerators. But here, this feels overdesigned and confusing, as if someone drugged the tab instead of dragging it. The very same natural gesture – a left swipe – that should feel safe and send you to Private, will now put you in a scary new full-screen/​keyboard-out flow you almost never need.

Why this relates to system design is that on/off toggles in iOS were recently redesigned to resemble oblong pills:

Those do respond to dragging as you’d expect:

Along the same lines, on the springboard pagination pill, dragging to the right means the next page:

And so now the system is schizophrenic and identical-looking design primitives mean the opposite things. It’s as if the computer itself kept randomly pressing Scroll Lock for you, preventing you from developing a solid understanding of the system first, and motor memory second.

I think the mistakes made here were twofold. First, the design overoptimized for two unnecessary things: people actually using site groups (not common), and ease of use in creating site groups (not important). My slightly cynical hypothesis is that this design presented really well in demos, which sometimes can derail a project. A more cynical theory is that this led to “accidental discoverability” that made the site group metrics look better.

Second, and more important part: This particular design received an exception that it didn’t deserve. No one noticed the systemic challenge of similar UI elements doing opposite things, or people who did were not effective in pushing back. The metrics for new feature discovery are easy; the metrics for user confusion or frustration do not usually exist.

This is how interaction systems slowly fall apart. As I mentioned in the first part, 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 know the feature is actually called “tab groups” but I called it “site groups” intentionally, because otherwise it’s a tabbed control controlling tab groups, and things get confusing really quickly. Also, thank you to Martin Hoffman for initiating this post.

A fun 19-minute video from commonLuke trying to write a short Fibonacci program in increasingly esoteric languages:

Here are the languages:

• Python, Scratch, and assembly (as control),
• LOLCODE, a language resembling lolcat memes of yore,
• Piet, a language whose output looks like Piet Mondrian’s abstract art,
• Brainfuck, whose programs are made chiefly of punctuation,
• COW, a version of the above where each of the few instructions is a variant of “moo,”
• Whitespace, whose code consists only of spaces, tabs, and returns,
• Chef, where programs resemble cooking recipes.

My favourite was Shakespeare, in which the whole program resembles a play. Believe it or not, but this code outputs “HI”:

A New Beginning.

Hamlet, a literary/storage device.
Juliet, an orator.

Act I: The Only Act.

Scene I: The Prince's Speech.

[Enter Hamlet and Juliet]

Juliet: Thou art the sum of an amazing healthy honest noble peaceful
fine Lord and a lovely sweet golden summer's day. Speak your
mind!

[A pause]

Juliet: Thou art the sum of thyself and a King. Speak your mind!

Thou art the sum of an amazing healthy honest hamster and a golden
chihuahua. Speak your mind!

[Exeunt]

It was interesting for me to see programming languages that intentionally remove some of the niceties and affordances we learned to take for granted. My guess is most of them are just art, or jokes, or a certain one-upmanship. But I couldn’t help but think of Arika Okrent’s excellent book In The Land Of Invented Languages. The book is about “human” languages like Esperanto and Klingon, but it’s much more interesting than I imagined, and maybe even quite a bit sadder: a story of people afflicted with a certain perfectionism who are not willing to accept languages simply cannot be perfect.

As a teenager I adored Norton Commander, learned some UI magic from early videogames, and dreamed of a Mac my family couldn’t afford. But I think the first product that taught me something truly memorable in terms of user experience was, of all things, Excel 97.

Excel 97 cooked. It was rendered in brand-new, gorgeous Tahoma, had keyboard underlines everywhere, and felt complete in terms of features. Sure, you could maybe sense the beginning of the bloat with the reorderable menus and the bolted-on Clippy, but Excel 97 felt tight and zippy even on an abominable computer put together on a high-schooler budget from used hardware pieces that were never meant to meet.

But what made me love Excel 97 was one specific thing: the Repeat command. You could invoke Repeat via Ctrl+Y, but my fingers learned to love its stranger alter ego, F4. This is what pressing F4 did:

It was a bit more clever than just replaying the previous action. If you changed the font and its size, it would repeat both:

And it didn’t only repeat formatting, but also some actions, like inserting new rows, or merging cells:

There are, of course, many other solutions to make these things less tedious:

• make a complex selection first (if possible), and format later,
• use styles instead of naked formatting,
• copy/​paste formatting only,
• paint format from one cell to another,
• record and repeat keystrokes,
• save individual actions into bigger macros and reuse them.

…and some of them were even available in Excel 97.

But it was Repeat that stole my heart. I think this is because it was two types of magic combined: the magic of motor memory + the magic of smart software.

The first part meant that soon, it didn’t really feel I was pressing F4. The shortcut lodged itself in my fingers and in time, it became a gesture as natural as pressing Backspace or arrow keys. All the other alternatives above required thought or bureaucracy, but Repeat was mindless – I would occasionally watch my hand perform it on its own.

The second part is that F4 felt like it was reading my mind. There were no options; Repeat just always seemed to do the thing I expected from it. As I understood this kind of functionality more, years later, I learned to appreciate the deeper thinking necessary to make it work. Repeat wasn’t actually repeating keystrokes and commands – it was some tricky dance of adjectives pretending to be verbs, with groundwork necessary so that the system felt stable and consistent.

The feature wasn’t flashy. It didn’t even have a separate toolbar button. But it was beautiful.

Repeat is still there in Excel on my Mac today, in Google Sheets, and a few other apps like BBEdit. It’s often an extension of redo, although I prefer thinking of it as something independent. Some apps like Sublime Text or Keyboard Maestro have a quick record/​repeat function that feels similar, although it’s not as smart – this one is solely repeating keystrokes, and requires you to start recording first. (Part of Repeat’s beauty is that it works retroactively.)

If you look at the keyboards on my desk, they all appear blank…

…with one exception:

Repeat was fantastic. I wanted it as a user elsewhere. Then, as a designer, I wanted it for my users.

In time, I learned to appreciate other things like it, but both the solitary legend on my keyboard, and the current favicon of Unsung, are an homage to the original, 1997’s Repeat. (Original to me, at least. Repeat existed in Office 95 too, and perhaps in some other apps before that.)

If I got to spend my entire professional life designing hard-to-make, invisible things that make other people feel powerful and awesome, it would be a life well spent.

Let’s Game It Out is a YouTube channel where Josh Knoles occasionally grabs a modern videogame and tries to play it in a particularly creative way – finding bugs, breaking things, doing an action more times than anyone thought possible. What makes it even more fun is that what’s tested often are early access, unfinished games. Here’s an example 27-minute video of a game called Parking Tycoon:

There are many more. I could tell you that occasionally putting one on teaches me something about bugs or lets me put myself in the mind of a very inventive user. Sure, occasionally, perhaps. But mostly these are just fun to watch.

Bear (a notetaking tool) has simple image resizing, with one extra nicety – if your images are near each other, resizing one will snap to the width of the other:

In the Finder, columns snap to the width necessary to keep all the names untruncated – and not one pixel more:

(Sidebar: This is also the only place I’m mentioning today that nicely uses the trackpad’s haptic feedback at the snap moment. I tried to indicate it in the video; this is not the final visual treatment I’m thinking of, but let me know if this kind of visualization of haptics feels useful to you!)

macOS does something really interesting when you get its windows close to each other. Instead of typical snapping – pulling the thing you hold toward the other item like a magnet – it instead prevents you from going further for a while, in either direction. Perhaps the right analog here would be glue:

If initially feels a bit funny, but I think I like it. It’s less aggressive and avoids needing some sort of cancellation (an option or a modifier key) if you don’t want it, because it never feels in a way.

It also works for matching heights, like in Bear:

In Figma, building atop regular snapping, we introduced something I awkwardly called “self-snapping”: if your objects are inside a container, the container will snap its padding to whatever it sees on the other side, without any explicit auto layout/​flexbox:

I am sharing these five examples (and one from before) because I think they exemplify a nice thing: precision without bureaucracy. In each case you could imagine an explicit heavy option somewhere in the menu…

• Bear: Set Image Width…
• macOS: Match Window Heights
• Finder: Restore Column Width
• Figma: Unify Padding

…that would feel slow and cumbersome.

Instead, these take the freedom of direct manipulation and sprinkle just enough almost-invisible structure in a moment where that structure is undeniably useful. (Of course, you still might want explicit options somewhere in the menu or your command palette, if only for accessibility reasons.)

I like that these quiet features have your back and make you look good, and that their creators understand that something almost aligned can feel worse than something completely misaligned.

Earlier this month, I talked about a rotation button in photos that behaved really nicely in iOS, and not so great on the Nothing Phone. Here’s a story of a similar fumble iOS once made that might bring the point home even more.

The calculator app has been preinstalled on iPhones ever since their debut in 2007. For the longest time it hasn’t been anything more than a standard four-function calculator with a decades-old feature set. If you’re not careful, however, you can mess up even that.

Ten years into iPhone’s history, iOS 11 introduced a problem just like the Nothing Phone rotation – quickly tapping on keys would show them as responding, but the actual action wouldn’t be registered. Michael Tsai’s aggregator’s first entry has a video from Stephen Heaps:

It shows typing 1+2+3+4 where iOS forgets one press of +, resulting in 1+23+4 = 28. Many more people posted about it afterwards, and showed various other examples.

It is oddly enthralling to see a computer fail at basic math. But what’s particularly historically interesting and perhaps even more embarrassing for Apple is the absolutely rich history of solving this kind of a problem.

Calculators evolved alongside typewriters as the earliest devices with button-like (as opposed to piano-like) keyboards. But the stakes were different.

Imagine a badly constructed typewriter and all the ways it can disappoint you: the letter might be faint if you press the key lightly or puncture the paper if you press it too hard, the output might be misaligned, or the typebars will jam in some way, forcing you to go again.

A typewriter has to work hard to divvy up a blank, analog piece of paper into a reliable, pleasant-looking grid via escapements, ratchets, and so on. But a calculator’s work to convince the analog world to be digital was much more important. After all, it’s not likely that the typewriter key you pressed will output the wrong letter – but on a badly constructed calculator, a light press of 5 could absolutely output 4, or 6, or 4.5.

And, while the typewriters only take your words verbatim, the calculator’s job is precisely to create new numbers out of the numbers you type. An imprecise mechanism can mess up that math. A jam could perform a partial or nondeterministic calculation. Adding 1 to 999,999 and the force necessary for the resulting cascading carry could break a device in the middle of work.

On top of all that, languages have a built-in redundancy. Evn if yuo mak many typoes, th sentece can stil be understod. But all numbers basically look alike. A calculator could make a mistake when it comes to a number that is absolutely vital for your payroll, for engineering, or for navigation – and you would never spot it.

Understanding all this, many calculator makers even already in the 19th century spent a wild amount of effort convincing people not just that their devices were helpful, and fast, and easy to use, but also that they could be trusted. Buttons were carefully weighted. Comptometers came with a locking mechanism. If a machine felt something didn’t go right, it would stop working and require a hard reset. The message was: “You can trust me, because I won’t ever show you bad math, and I’ll stop myself before I will ever lie to you.” Charles Babbage was so confident in his Difference Engine that he welcomed people to try to mess with its mechanical wheels in the middle of the calculation, convinced that even a sabotaged machine won’t ever make a mistake.

Just like with the Selectric decades later, those things were solved by people who cared, in the much harsher mechanical conditions.

Of course, I don’t expect everybody at Apple core iOS team to be a calculator UI historian (although it would be nice for at least one person on the team to be one!). It is embarrassing that no one on the team had enough imagination to realize that making a button respond to a quick press during animation, but not register it would cause all sorts of serious trouble. (The bug was fixed in iOS 11.2 by removing the animations, and subsequently the animations were brought back without the original problem in iOS 11.3.)

But maybe the bigger embarrassment is that Apple didn’t have a battery of tests to run on top of the UI at various speeds, mimicking fingers of what must be millions of people using the calculator app. That, too, has been a standard procedure for decades.

Those tests seemed missing in 2017. I hope 2+3+4 years later that’s no longer the case.

When you visit parts of the website of the Driver & Vehicle Licensing Agency in the U.K. outside of standard office hours, you will see this:

It seems ridiculous, almost like the famous 500-mile email bug, but Dafydd Vaughan explains how it came to be. It won’t be a surprise that the story starts with an old computer system, built around a day/night cadence where people would visit the agency during the day, the information would be collected, and all the data processing would happen overnight:

At the time, many of DVLA’s services – particularly those relating to driving licences were still backed by an old IBM mainframe from the 1980s – fondly known as Drivers-90 (or D90 for short). D90 was your typical mainframe – code written in COBOL using the ADABAS database package. Most data processing happened “offline” – through batch jobs which ran during an overnight window.

The team upgrading it in 2013 decided to not attack too many things at once, and swap the innards but keep the day/night system intact.

I’ll let you read some details inside if you are interested, and if you want to learn why the 2013 decision is still a 2026 (or at least 2025) reality. Like many of these, it is a story of heavy financial and technical constraints. But I will excerpt this bit, because I think many teams in any company – design systems, security, or “core” (whatever that happens to be) – would relate to it:

It’s difficult for an organisation to keep its focus and attention on a complex upgrade – particularly without getting noticeable benefits along the way.

The tricky part is that in many places you do end up in a legacy situation that is exactly as absurd as “an internet service having opening hours,” but you might be too close to the problem to even realize it.

Nikita Prokopov on his fun Tumblr-like site Grumpy Website that collects UI transgressions with light commentary:

Why log in when you have to, when you can instead experience the same Kafkaesque maze of pages, redirects, confirmation emails, copying codes, and searching for a second device—all a week in advance?

I agree with authentication experiences being absolutely horrible, especially in the corporate context. But I think the “your login expires in 5 days” callout is actually positive. Your reauthentication will happen anyway according to the security regimen. Instead of it potentially surprising you at a wrong moment – for example just before, or in the middle of the presentation in front of a boss – you could get ahead on that process during the next moment of downtime, and have some peace of mind.

I know Slack has a similar warning, although I don’t happen to have a screenshot handy; I imagine a few other places do, too.

(However, that gesture doesn’t give apps permission to handle expiring credentials badly. There should be no excuse for losing anything the user is doing – for example writing a long comment – just because the reauthentication kicks in in the middle of them doing that. Even the app losing its mind for a while just as its separate parts are waking up to the reality of reauthentication at their own pace and throwing strange errors, but the login screen hasn’t reappeared yet, can be really confusing.)

Have you head of the Swiss Cheese model? You see it sometimes in descriptions of how complex systems fail. The visual usually goes like this:

The whole idea is: even if you have multiple layers of safety – like many slices of cheese – there are always holes in each slice. Typically, a hole in any slice is covered by a non-hole in the previous one or the next one. (For example, a car might not allow you to grab your keys if you have not shifted to park – or, if you start driving with a handbrake on by accident, the car might yell at you.) But occasionally, the holes just happen to line up, and a larger disaster strikes.

The model is used in analyses of past accidents, and prevention of future ones. It has proponents and detractors. It’s hard to talk about its applications because the most common examples are horrific. In my book, I wrote about Therac-25, and that was a really unpleasant chapter to research and to write. Other go-to case studies are equally bleak: Chernobyl, Challenger, the Tenerife airport disaster, the Deepwater Horizon explosion.

But I wanted to share it because in my head it applies to UI design also, and sometimes helps me think of how small details add up to a larger whole.

In this first part, let’s start with a more traditional example, although a non-drastic one. Here’s a story of Knight Capital Group, a financial services and trading firm. I’m going to hand off the summary of the accident to Henrico Dolfing:

On the morning of August 1, 2012, Knight Capital Group opened its systems for what should have been a routine trading day, yet within minutes the firm began sending a flood of unintended orders into the U.S. equity market, buying high and selling low across dozens of stocks in a pattern that made no economic sense and could not be stopped through normal controls. What initially appeared as unusual market activity quickly escalated into a systemic failure inside one of the largest market makers in the United States, with algorithms behaving in ways that neither traders nor engineers could fully understand in real time. […]

By the time the issue was identified and the system shut down roughly 45 minutes later, Knight had generated more than 4 million executions across 154 stocks, covering approximately 397 million shares, and accumulated positions worth billions of dollars, resulting in losses of more than $460 million […]. The scale of the incident was not only financial but structural, as a single deployment failure had propagated through a system responsible for a meaningful share of U.S. equity trading. […]

Here’s what happened.

Long ago, the firm built a pretty boring function called Power Peg to automate some transactions. The function used a standard shared limiter that made it stop executing when all the required transactions were fulfilled. After some years in use, the function was deprecated in 2003 and stopped being used then, but crucially, the code was never actually removed.

Some time in between 2003 and 2012, the limiter functionality was upgraded, and the old code stopped being compatible with it. All code in production was rewritten to use the new limiter, but the Power Peg feature wasn’t, as it was already deprecated and not in use.

In 2012, the firm started writing a new program for automated transactions. Its creators decided to reuse the same software flag that previously activated Power Peg. The existence of the old code was known at the time, and the idea was that the code would be overwritten by the new program, so the reused flag would only trigger new code.

In July 2012, the new code was finished and the firm started to install it on all the servers, overwriting Power Peg. The firm intended to deploy the new code to all eight servers, but a mistake resulted in it only arriving on seven servers.

No one caught that mistake.

At this point, you can piece it all together. At this point, I imagine many of you have been wincing more and more with each passing paragraph.

On August 1, the flag for the new functionality was turned on. Everything was fine on seven servers, but on the eighth one, the flag reawakened dormant code that immediately started executing. As the old code was not compatible with the new limiter, it was never limited, cascading into millions of transactions in less than an hour, and a lot of collateral damage; the subsequent market reaction to the news of the firm losing over $400 million and caused its own stock to tank.

Oh yeah, I didn’t mention this yet – the failure killed the firm. (Well, it resulted in a merger, but that seemed to be a way to save face after Knight Capital Group almost went under.)

How does the Swiss Cheese apply to this? You can see it as five holes in five different slices of cheese:

• it was a mistake to not actually remove the old code
• it was a mistake to reuse the same flag
• it was a mistake to not deploy to all 8 servers
• it was a mistake to not have a procedure for someone to double check the deployment
• it was a mistake to not have a way of auto-detecting (and perhaps auto-stopping) the runaway processes when the regular limiter failed

What’s important to understand about this model is that either of these in isolation would objectively be a small mistake, and caught by the other slices. As a matter of fact, any four of these happening would still not add up to a catastrophe.

But in this case, the five mistakes lined up perfectly.

Many analyses of such accidents blame a single event in the chain – in this case often the sysadmin that didn’t deploy the code to eight servers properly – but this is primarily because we like stories of individual agency, and are not well equipped to understand stories of systems. (Even Star Trek added a Borg Queen.)

That’s the accident eventually dubbed “a Knightmare.” More examples of systems closer to our hearts in following parts.

I am generally not someone who cares much for easter eggs (unless they come with interesting stories), but John Gruber’s one-liner made me pause for an unexpected reason:

Joanna Stern explains why this emoji is correct today: 📅. (This one too: 📆)

I thought the two different calendars was some trickery, but the answer is simpler than that. I did not realize that, inexplicably, there are two distinct calendar emoji: one for calendar, and one for a tear-off calendar.

The way I learned about it was to use a tool I made a few years ago called text.makeup:

I thought this would be a nice opportunity to share it with you. If you’re debugging a string you don’t understand, or are just interested in learning about various Unicode or encoding secrets through playing (see the left sidebar!), it might be a fun thing to use.

I just updated it with the most recent emoji (and Unicode goodies) that will drop after September this year.