★★☆☆☆
2018 / 92 minutes

General Magic was a company started in 1990 by some of ex-Apple staffers, working on a pocket communication device and its operating system (Magic Cap, sporting a fascinating room user interface). The product launched in 1994, but swiftly failed in the market, similarly to and concurrently with its chief competitor, Apple Newton. Many alumni of the company – including Megan Smith, Kevin Lynch, Tony Fadell, and Pierre Omidyar – ended up having successful careers in tech after that, to a point that General Magic is referred to as “Fairchild Semiconductor of the 1990s.”

The eponymous documentary, released in 2018, was disappointing to me. Sure, it is well-edited, and particularly shines owing to a lot of archival footage shot during General Magic’s happy years.

Unfortunately, we get to see none of the sort of details I was hoping to see: no pre-release interface or hardware, no discussion of product nuances, no solid reflection on the company, the culture, or the zeitgeist. The movie drops so many fascinating questions and avenues, but doesn’t really follow up on them:

• At some point, Andy Hertzfeld reflects on setting a bad example by focusing on small playful details instead of rallying the team to ship stuff. Where did this realization come from and did that change him as a person going forward?
• In hindsight, did the company benefit or suffer from the culture of freewheeling “superstars” who are also perfectionists? In a strange, brief vignette, a few people talk about not wanting to have any managers – but that is not picked up again or resolved in any way.
• How did the company manage to hire all of this past and future talent? Are there any repeatable lessons in here?
• During the launch, there is a brief slide with “whole person thinking,” which felt unique for a tech product reveal. Near the end of the movie, Kara Swisher talks about worrying how mobile devices can affect and perhaps even impair human-to-human communication. Those two threads are not connected.
• About the only lesson learned and spoken out loud comes from Tony Fadell, who says: “with the iPod, we iterated a lot faster.” Would this have mattered if the premise of the movie seems to be that General Magic was too early on the market anyway?
• There was a mention of a skeuomorphic room interface done pretty much overnight by Andy Hertzfeld. From the perspective of today, it is the device’s perhaps most distinctive characteristic, but it’s not covered more than that one mention.
• In another very rare specific example, there is a beat talking how iPhone’s (very controversial, early on) software keyboard owes its existence to General Magic’s team trying that first. How did whoever created it feel about it?
• An external observer suggests that General Magic missed the early ascendance of the web, but we don’t see anyone from the company reflecting on it.

Unfortunately, I kept thinking of the movie as “generic magic” – a sort of interchangeable valorization of Silicon Valley’s “failure is secretly success in the fullness of time,” defaulting to romantic or rousing music, that must have felt obsolete even in 2018. It felt like the documentary could very well talk about one of the many other companies and efforts, which is frustrating, because there was something special and unique about General Magic.

I also kept remembering The Soul of the New Machine, Andy Hertzfeld’s own Folklore.org, and even Halt and Catch Fire, all of which more adeptly interspersed personal and emotional drama with specific details you could learn from and take home with you. I think General Magic deserved more.

(I do want to recognize that perhaps this wasn’t a movie for me. The documentary is free on YouTube if you want to check it out – it’s consistent throughout, so if you like the early minutes you might like the whole thing.)

To play with Magic Cap, go to Infinite Mac, click on Macintosh Garden tab at the bottom, search for “magic cap”, click on magic_cap_simulator.sit, go back to the emulator, double click on the Outside World icon, double click on Downloads, double click on the .sit file, wait for it to unpack, close the Downloads window, reopen it, double click on the Magic Cap Simulator icon.

Have you ever seen this?

The best way to predict the future is t̷o̶ ì̴͇n̵͓̆v̶̝̕ȇ̷̝͈̩͊̇̾̄̂̀̈̔̀͛͋͆̓͒͘͝ͅn̸̦̙̣̤͓̜̼͙̲͔̺͚̮̬͆̇̇͐̇̽̒̎t̵̮͎̃̒͒̋̂̏̒̀̿͌͗̄͑̀̀͒̈̚͠͝ ȋ̸̧̛̭̠͈̰̰̦̹̥̜̖̈̂̀̽̿̋̊́̇̍̓̆̉̄̄̊͊̒̎͋̂̒̍̽̄͝ͅt̶̨̢̺̱̻̭̣͉͕̥͚̯͍̣͕͔̬̥͔̘̼͌̉̀̄̊̆͛̽̍̐̔̐̀̾̋̆͒̏̏̋͋̽͗̌͋͗.̸̧̨̧̡̢̪͙̦͙̝̜̦̞̳̤͖̟͍̮͖̘̙̳͉̳̲̲͉̠͎̽̍̓̒̅̿͂͑̎͊̋͒̈́̅̈́̆̽̒͛͐͛̉̀̈́̈̉̏̏̋̒͘͝͝͝

In the lore of the web, this kind of a strange glitchy text is known as Zalgo:

Zalgo is a meme where a popular picture/​comic is edited in a way that “corrupts” it, producing scary results. The term “Zalgo” refers to the being apparently responsible for the corruption, whose name is uttered by its victims in an eldritch manner.

I’ll let you read up on that at the above link if you are curious, but what’s interesting for us here is that… Zalgo is text. You can grab the line above. You can copy and paste it. You can even try to edit it. But… what is that, and why is it possible to construct text this way?

In Unicode, ä is a completely independent character from ą, and they are both completely unrelated to a – any type designer treats them as a variant of the same base letter, but there’s nothing preventing them from making them look very, very different.

But now think of the Vietnamese language, which has six tones mapping to six accent characters, and many of them can be combined into pairs:

This gives us 104 accented letters, and 30 doubly accented letters, just for this one language.

Sure, you can imagine adding all of them as independent characters, but at some point another idea appears on the table: What if we just allowed a system where you can add an accent to any letter?

Instead of outputting ä as one letter, you could output a followed by ̈  , which then would be recombined by the rendering logic into ä. And to get two accents, output a and then ́   and   ͆  , to get á͆.

Now, the zero-one-infinity rule says that once you open the door to two, you might as well allow three or even more. Add to it the fact that some accents go under the letter, and here you go: perfect conditions for the Zalgo meme that just creatively stacks up accents one after another – not for communication, but solely for aesthetics.

Today, there are a whopping 122 combining diacritical marks used in all sorts of occasions, and Zalgo generators know about them all. A fun thing to try in one of them is to let it do its thing, and then keep pressing Backspace:

Now you might ask, why do separate characters exist for ä and ą then? Why isn’t every accent combining? Two things: history (some pre-combined accented characters existed for as long as movable type was around) and complexity (combining accents are harder to process, to display, to edit, and even to design). There were many debates around this – you can open the History box on the above Wikipedia page and pore over the old documents to learn. (As a matter of fact, today all Vietnamese letters exist as precombined characters, too.)

A few bits that might be useful to know:

• Zalgo is a good reminder that while it’s hard to contain text, you can at least crop it – often you might see things like these, where in some places Zalgo is allowed to roam free, and in others the text is clipped so three or more accents fall outside of the clipped area.

• Eagle-eyed among you might have noticed above that ä and á͆ look different. As far as I understand, if the combination of a letter and accents isn’t supported by the current font, the entire combination falls back to a different font, rather than picking bits and pieces from different fonts.
• There are even more combining characters, and emoji use a similar system to add skin tone modifiers, gender, or turn a woman next to a fire truck into a female firefighter.

Lastly, I found this warning on the very Fandom page that explained Zalgo amusing:

Do not post Zalgo text in the discussion area or anywhere else on the wiki. Doing so will subject you to a ban.

Every warning tells a story; it seemed like more people were perhaps infatuated with the glitchy text than expected.

Nice recent addition to Gmail – a little warning if you’re replying to a thread you were BCC’ed on.

Please note that I’m not necessarily endorsing the execution details, as I consider Gmail kind of a clunky operation overall. You can’t swat the message away with a swipe, the wrong quotation mark is used, and I’m perplexed about the location of this message – something tells me it was really cheap to do it this way rather than put it close to the recipient field, to help you understand the relation.

But still, I appreciate something shining at least a bit of light at the complex relations between To, CC, and BCC.

Some time ago, I shared a video talking about games that leaned into their bugs and made them part of their lore.

One not listed there, perhaps because it’s the most obvious example, is Pac-Man’s kill screen.

A few weekends ago at an arcade game convention, I spotted something really interesting. It was an arcade cabinet of Pac-Man, but with a twist: The game was modified and set up to start immediately at level 255, with all its challenges: fast timing, very angry ghosts, ineffective energizers.

And once you beat that, you immediately face level 256: the infamous kill screen.

I don’t think I have ever seen anything like this before. It reminded me of this joke someone made once about the olympics: that each competition should begin with the organizers grabbing regular people from the street to participate, just so the viewers can truly realize how impossibly hard those competitions are.

I know a lot of software onboarding starts gently, walking you through basic scenarios to make you comfortable and to have you understand basic concepts. But sometimes I wonder: for professional apps, would it also be cool to start with a really advanced use that would get you excited? A really well-made, complex spreadsheet? A really sophisticated graphic? Instead of gently propping you up, what if the onboarding was about breaking something really complex down?

I played the game a few times. I didn’t finish the level 255, and I never saw the kill screen. But it was a great challenge; if I had more time, I’d definitely spend it trying to make it happen.

I spotted this kind of a keyboard shortcut pattern the other day. Here it is in Photoshop:

Here it is in DevonThink:

And here in Linear:

Those “ordinal” keyboard shortcuts feel nice and orderly, and look so elegant, too. But beware! The moment you’ll want to introduce a new option, or even reorder the ones you have, you’ll be in trouble: Either you preserve people’s motor memories, and then the elegant ordering immediately goes to hell – or you will have to change an existing shortcut to something new, and frustrate your users. Might be best to be really confident in your selection being forever locked before attempting this.

But then there’s a similar treatment here in Linear:

Or here in Raycast (when you hold ⌘):

Or here in Ghostty:

Those three look like the same idea, but they worry me less.

Why? Because these shortcuts more clearly point to a position rather than a thing. Here, the mechanics of the UI themselves convey that people, commands, or tabs are going to be moving around. Of course, some will get used to “1 means assigning to Marcin,” or “⌘3 means the Unsung tab” – the same way we get used to “second item on the Recent list” or “at the top of the third search result page,” if they start repeating as a pattern – but at least it feels to me that the interface here is more honest about what it can promise.

I often think about this, by the way: Not what the interface conveys in the moment, but what it promises in the long run.

For all these times we talked about Super Mario, we never covered another important game, Doom.

Here’s a 17-minute video from decino explaining how the Doom monsters move and attack the player (the “AI” in the old sense of the word):

What’s really fun about this video is how it uses annotated source code (in contrast to Super Mario, the Doom source code was officially released and open sourced), and particularly how it tasks the engine with explaining itself, setting sometimes elaborate stages just to show a principle or an algorithm – an absolutely perfect example of “show, don’t tell.”

decino has tons more of these kinds of videos (click on Popular!), distinguishable by their yellow covers, if you want to pick another aspect of Doom that interests you.

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.

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.

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.

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:

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:

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.)

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?

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.

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.

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.

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.