Over the years, I learned about many gotchas and strange differences between keyboard handling on Mac and Windows – pertinent especially to web apps, which use the same codebase to cater to both. I thought it might be helpful to someone if I compile them all in one place.

This post is meant to be a reference, and there aren’t any cute or riveting stories hiding inside – if this seems boring to you, feel free to skip to the next one!

Different names for keys

What Windows calls Backspace, Mac calls Delete. What Windows calls Delete, Macs call Forward Delete. (This means saying “Delete” without specifying the platform might actually be confusing.)

What Windows calls ⏎ Enter, Mac calls ⏎ Return. However, Macs also have an ⌤ Enter, although only on a numeric keypad (previously, it was even there on laptops!). On keyboards without the physical Enter key, you can simulate it via Fn+Return.

In most Mac software, Enter and Return do the same thing. There are a few exceptions – for example, Photoshop adds a new line on Return but commits on Enter, and some classic pro apps like Cubase or Pro Tools do different things, too – but it seems to be a dying tradition. (If you are curious about the history of Return and Enter, I wrote about it once.)

Windows customarily calls the secondary key Numpad Enter. I don’t believe Fn+Enter works to simulate it.

Generally, third-party keyboards use Windows verbiage – so, Backspace and Enter. If a keyboard offers Mac conventions at all, they usually only extend to modifier keys.

Modifier keys

⌃ Control on Windows is the equivalent to ⌘ Command on a Mac. (Paste, for example, is ⌃V on Windows and ⌘V on a Mac.) But, confusingly, Apple devices still have a Control key, too. This was originally meant for terminal applications, but these days many GUI apps use it as an extra modifier key of much lesser significance than Control on Windows.

This means that for apps, Windows devices offer Ctrl, Alt, and Shift – and Macs offer ⌘ Command, ⌥ Option, ⌃ Control, and ⇧ Shift. That’s one more modifier key, and thus more space to breathe. (We’re not counting the Windows key or the 🌐 Globe/Fn key since those are technically reserved by the operating system.)

Some keyboards offer extra key caps you can swap to match the platform, for example:

Others cover all the bases on fixed key caps, in an awkward way:

Many stick with Windows-only legends.

(Just swapping the key caps is not enough. The keyboard also has to swap the scan codes it sends, since the code for Alt is the same as the code for ⌥, and the code for ⌘ is the same as the code for ⊞.)

Words vs. symbols

Apple devices rely more on symbols on their keys and in their menus, although they don’t do so consistently. Here are all of them:

• ⇧ Shift
• ⌃ Control
• ⌥ Option
• ⌘ Command
• ⏎ Return
• ⌤ Enter
• 🌐 Globe/Fn
• ⇥ Tab
• ⎋ Esc (not printed on keyboards, for some reason)
• ⌫ Delete
• ⌦ Forward Delete
• ⌧ Clear
• ≣ Contextual Menu (only on full-size keyboards)
• ⇞ Page Up (only on full-size keyboards)
• ⇟ Page Down (only on full-size keyboards)
• ↖ Home (only on full-size keyboards)
• ↘ End (only on full-size keyboards)

Actually, I lied about the last four. On modern Apple keyboards, they are:

• ↑ Page Up
• ↓ Page Down
• ⤒ Home
• ⤓ End

Reusing the regular arrows for Page Up and Down is one of a few perplexing decisions from Apple’s keyboard designers. The arrow key symbols look like this – ◀▶▲▼ – but only on Apple keyboards. Here is an older and a newer Apple keyboard showing what happened:

(Luckily, the confusing dual arrow key situation only happens on less popular, full-size keyboards.)

Historically, Apple keyboards used symbols more on non-US keyboards, but starting with the 2026 models, they unified when they show symbols and when they show symbols and legends, across all keyboards. (The only key with just a text legend is Esc, making the appearance of ⎋ in menus extra puzzling.)

---

Windows keyboards typically use words – this is why in tight quarters you sometimes see shortenings like Ctrl, Bkspc, PrtSc, Del, PgUp, Win, and so on. (I don’t think Apple ever abbreviates their legends with the exception of Esc for Escape.) In some countries, the legends are translated – as an example, in Germany, Ctrl sometimes appears as Strg.

The symbols that crossed over to Windows side are:

• ⇧ for Shift
• ⇪ or 🔒 or a similar symbol for Caps Lock (on non-US keyboards)
• ⏎ for Enter – note the same arrow as Mac’s ⏎ Return
• ← for Backspace – note a different arrow than Mac’s ⌫ Delete
• ⇥ for Tab (you can also sometimes see ⭾, which is a symbol representing Tab and Reverse Tab together; Reverse Tab used to be a separate key on some 1970s terminals)
• ⊞ for Windows key – the style of the logo will be different depending on the age of the keyboard, roughly matching the Windows logo at the time; some keyboards also use a more abstract shape, or call the key Start or System instead of Windows
• ≣ for contextual menu key (a.k.a. Application Key) – just as Apple added that key on its large keyboards, Microsoft started removing it in favor of emoji key, Office key, and then Copilot key
• ⌃ for Control (especially in nerdy contexts)

I have not seen any other popular symbols on the Windows side of the aisle, and I am not even sure if the above would be widely understood. But here’s an example:

(I wrote a bit more about Mac symbols before, and also about the rare Canadian symbols.)

How to show shortcuts

In menus and other places, Windows joins the key combinations/​shortcuts with a plus, but Apple just glues them together:

• Windows: Shift+A, Ctrl+Shift+G, Ctrl+F11, Alt+Enter
• Mac: ⇧A, ⌃⇧G, ⌘F11, ⌥⏎

Here is the same Chrome menu on Windows and on macOS:

(In other words, you’d never say “⌃V is Paste on Windows” like I did above.)

Function keys

Both Windows and Macs have function keys.

On Windows, traditionally those were claimed by the operating system or the apps as shortcuts. Here are some examples of well-known function key assignments:

• Alt+F4 – close the app
• F1 – help
• F11 – maximize window
• F12 – dev tools in browsers

On Macs, traditionally the apps didn’t reach for function keys, as those were reserved solely for the users to do stuff with. (However, some combination of ⌃ and function keys are used by the operating system for accessibility options, and I occasionally see apps use function keys these days.)

Windows keyboards top off at F12, but some Mac keyboards reuse the three special PC keys, and even take over the unnecessary Num Lock/​Caps Lock/​Scroll Lock island, and end up going up to F19:

Access to extra characters

In text fields, Apple has a system where pressing ⌥ with printing keys outputs more characters, for example ⌥Q outputs œ, and ⌥7 outputs a ¶ pilcrow. Additionally, ⇧ works in this context, so for example ⌥⇧Q outputs Œ, and ⌥⇧7 outputs a ‡ double dagger.

Note that not only letters, but basically all printing keys have secret ⌥ and ⌥⇧ assignments. (Also note some of these are dead keys.)

Also, ⌥ assignments vary per location! The above was U.S. English, here’s Polish with a lot of differences:

This means it’s best to avoid ⌥-based shortcuts in text fields, since they might conflict with some important character.

By the way, while the above two are just mock-ups, on some physical keyboards (here: British English), some of the important ⌥ invocations are actually printed on keys:

---

Windows doesn’t have the above feature. However, Windows has an alternative feature where typing Alt+numpad keys allows to enter any character by its code. (For example, Alt+0128 outputs €. Num Lock has to be enabled. I don’t think it’s possible to do it without a numeric keypad present.)

Mac has a version of this feature, but it requires adding Unicode Hex Input keyboard and switching to it beforehand. Then, pressing ⌥20AC outputs €.

Right Alt key on Windows

While Mac modifier keys are completely symmetrical, Windows makes an exception for Alt. On many non-US keyboards, right Alt is also known as AltGr, and does something similar to ⌥ on a Mac: it outputs letters when pressed in combination with printing keys.

For example, on Polish keyboards AltGr+A = ą, AltGr+C = ć, AltGr+Shift+A = Ą, and so on with 15 more combinations. Many other keyboards do similar things.

The way it differs from ⌥ on a Mac is that these are usually reserved for core letters and punctuation necessary for each language, rather than the typographical smorgasbord that Apple provides.

For legacy reasons, and also for keyboards that do not have a physical AltGr key, you can also invoke all these using Ctrl+Alt combinations instead (so, Ctrl+Alt+A = ą). This means that just as you have to be careful about ⌥-based shortcuts in text fields on a Mac, so you should be of Ctrl+Alt-based shortcuts on Windows.

Just like on Macs, on some keyboards, selected AltGr options will be printed in the corners or fronts of keys:

Text fields

Text fields in Mac OS apps and web browsers/​websites use some of the standard Unix/​Linux shortcuts based on the ⌃ Control key:

• ⌃A – move to the beginning of the line
• ⌃E – move to the end of the line
• ⌃F – move to the right, or forwards (hold ⌥ to jump through words)
• ⌃B – move to the left, or backwards (hold ⌥ to jump through words)
• ⌃N – move down or to the next command
• ⌃P – move up or to the previous command
• ⌃L – scroll the window so that the text cursor is in the vertical middle
• ⌃H – delete (backspace)
• ⌃D – forward delete
• ⌃K – delete (kill) to the end of the line
• ⌃T – swap (transpose) the adjacent characters
• ⌃O – insert new line, but (contrary to Return) do not move the cursor there

You can combine many of the above with holding ⇧ to extend the selection.

A small group of vocal users love these.

---

Windows still supports Shift+Delete for cut, Ctrl+Insert for copy, and Shift+Insert for paste. I am not sure how many people use these.

---

On a Mac, in simple input fields, ↑ and ↓ jumps to the beginning and end (same as ⌘←→). This often conflicts with command line history, autocomplete pop-ups, and so on.

Windows doesn’t have this convention, and Home and End serve this purpose instead.

---

Macs support the iPhone-inspired convention of holding a key to show related accented characters, instead of triggering auto-repeat. Windows doesn’t have this feature.

Differing shortcut conventions worth knowing about

On a Mac, redo is typically ⌘⇧Z. On Windows, it’s typically Ctrl+Y.

On a Mac, refresh (in browsers, etc.) is typically ⌘R. On Windows, it’s typically F5, although browsers support Ctrl+R, too, and seem to be shifting to that being the default.

Reserved keys

Windows’s eponymous ⊞ Windows key is reserved solely for the use of the operating system, and so is Mac’s 🌐 Fn/​Globe key. (Although I am not 100% sure of that as I found one place you can create 🌐 shortcuts as a user – I’m just not certain if it’s intentional.)

However, each platform also has a lot of shortcut combinations that are effectively unavailable, for example ⌘⇥ and ⌘M on a Mac, or Alt+Tab and Ctrl+Shift+Escape on Windows.

These official lists can help:

• Mac keyboard shortcuts
• Keyboard shortcuts in Windows

If you’re a web app, you will compete for shortcuts with the operating system (like any app would), but also with the browser itself. You can typically take over shortcuts like ⌘S or ⌘P, but depending on the browser or the platform, some might be sacred and unavailable. No Mac browser will allow a website to claim ⌘Q, ⌘W, or ⌘T. Safari won’t allow a web app to override ⌘R. Arc browser won’t allow to override ⌘⇧C. (This is not a complete list.)

Jumping around

Tabbing and Shift tabbing is customarily used to jump between UI elements, but it behaves slightly differently in native apps.

On Windows, tabbing jumps through all interactive elements:

On Mac, Tab jumps only to those interactive elements that require keyboard to operate (such as input fields). You can toggle a System Settings preference and ask macOS to mimic Windows behaviour – see the last toggle below – but it’s not supported well everywhere.

---

PgUp and PgDn work differently:

• On Windows, they move the text cursor a screen up or down.
• On a Mac, they scroll the view up and down, but they do not move the text cursor if it’s present (so, they are more an equivalent of clicking on the scrollbar chute).

Similarly, Home and End work differently:

• On Windows, they scroll the contents (and move the cursor if present) to the top or the bottom of a view, or move the cursor to the beginning or the end of an input field.
• On a Mac, in views they scroll to the beginning or end without moving the cursor. In input fields, Home/End do nothing, but you can use ⌘←→ to accomplish the same.

On both platforms, Fn+↑↓ does PgUp/​PgDn, and Fn+←→ does Home/End. (Do you see how confusing it is to say that given that ↑↓ already mean PgUp/Dn on a Mac?)

---

Windows has a tradition of enabling access to menus and visible controls by pressing Alt and letter keys. This has evolved over time and is not as consistent as it used to be, but it might be worth knowing about.

Less popular keys

On a 100-plus-key keyboard, Windows might have:

• Insert – still used in some contexts for overtyping
• Print Screen – today taken over by screenshotting
• Num Lock and Scroll Lock
• Pause/​Break

Macs have:

• Help – rarely used, and now abandoned in favor of…
• ≣ Contextual Menu – shows the same menu as right click would
• ⌧ Clear – a deterministic backspace, these days seldomly different than the actual Delete key

Macs never had arrow keys on a numeric keypad nor a Num Lock key to enable it. (I’m breaking my promise! Here’s a fun bug story about Num Lock.)

In a strange twist of fate, it’s not only third-party keyboards that favor Windows legends. Some of Apple’s keyboards in between 1980s and 2000s showed PC legends, too! (This was to court PC compatibility of then-beleaguered Macs.) Here’s the classic Apple Extended Keyboard, showing legends for Insert, Delete (naming it Del to avoid confusion with its own), Print Screen, Scroll Lock, Pause, Num Lock, and Alt:

Did I miss anything or make a mistake? Let me know!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I like that they light up to show status:

One of the modules was a counter:

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

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

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

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

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

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

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

…with the biggest variety of modules…

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

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

Just as there is a ticking bomb built into cut/⌘X – if you cut something, and then cut something else again without a paste in between, you overwrite the clipboard without any way to bring it back – there is another one that awaits you when you use undo/⌘Z.

Here’s a typical undo chain, illustrated using Photoshop’s classic interface. You can do things, then undo into the past with ⌘Z to your heart’s content, then zipline back to the present via redo’s ⌘⇧Z:

But if you go far into the undo history and do something then – accidentally or intentionally – poof! Your entire undo stack, no matter how precious and storied it was, evaporates in an instant:

And it’s not even Back To The Future II rules where you can at least go back to the original separation moment and still get the better future for free…

…no, the entire original undo stack is gone.

The most popular solution for the cut problem, inasmuch as it really needs one, is a clipboard manager. Clipboard managers only move forward in time and record everything passing through the clipboard, so even if you override it with a careless cut or copy, you can ask the clipboard manager to resurrect the contents.

The most popular solution for the undo problem is something conceptually very similar – version history. It also always marches forward. Do something new? You’ll see a new version history entry. Undo it? New version history entry. Redo? New version history entry. Both the clipboard manager and version history are like paper ledgers, hostile to erasers and shredders, addicted to additivity.

(Mixing both universes, Figma’s version history will allow you to copy something from its past entry. But, naturally, you won’t be able to cut from it.)

I like this conceptual distinction, and you can see it in places outside of undo, too. Any browser has a tactical back/​forward button staring you in the face, and a strategic history log hiding deeper inside. Linux offers up/​down arrow keys for tactical recall, and history for the ledger:

It all feels like the correct proportionality – the simple thing comes with a quick UI, the heavier thing with an interface that matches its heaviness. This is why I got a bit nervous hearing about persistent undo, because undo is meant to be more like a fruit fly, like stockpiling things on your undersized cafeteria tray, knowing the journey to the table won’t last very long. Undo’s interface is not compatible with longevity.

But even for version history, the devil’s in the execution. Many tools don’t offer version history, and others add to it only at seemingly random intervals. Chrome’s back/​forward buttons are wonderful, but its history UI is a hot mess: slow, and with only an infinite scroll when it comes to exploration. Figma’s version history doesn’t make it as clear as it could (sorry, my bad, I never got around to fixing it) that restoring an older entry is not rewinding back to it like undo, but using ledger rules – so it might not feel as safe in use:

But I also wanted to go back to Photoshop and show you something interesting. One of the history settings offers “non-linear history”:

Turn it on, and a fascinating thing happens: There is no poof. Undo behaves more like a ledger, always marching forward:

It is an interesting idea. In practice, it’s confusing – time is not meant to work this way. But I feel this was really close to a nice solution that could be enabled for everyone: preserve the discarded branch, but keep it off of ⌘Z and only show it in the visual UI so you can get back to it this way, perhaps presenting it slightly off the main axis, perhaps, I don’t know, looking something like this:

Okay, technically the future collapse is *exactly* like Back To The Future II, but given you’re the only actor in the universe, you still have to recreate the future all by yourself. See, now I’m starting to sound like Primer.

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.

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.

I had no idea it was Alan Kay himself who was responsible for the mouse pointer’s distinctive shape. In 2020, James Hill-Khurana emailed him and got this answer:

The Parc mouse cursor appearance was done (actually by me) because in a 16x16 grid of one-bit pixels (what the Alto at Parc used for a cursor) this gives you a nice arrowhead if you have one side of the arrow vertical and the other angled (along with other things there, I designed and made many of the initial bitmap fonts).

Then it stuck, as so many things in computing do.

And boy, did it stick.

But let’s rewind slightly. The first mouse pointer during the Doug Engelbart’s 1968 Mother Of All Demos was an arrow faced straight up, which was the obvious symmetrical choice:

(You can see two of them, because Engelbart didn’t just invent a mouse – he also thought of a few steps after that, including multiple people collaborating via mice.)

But Kay’s argument was that on a pixelated screen, it’s impossible to do this shape justice, as both slopes of the arrow will be jagged and imprecise. (A second unvoiced argument is that the tip of the arrow needs to be a sharp solitary pixel, but that makes it hard to design a matching tail of the cursor since it limits your options to 1 or 3 or 5 pixels, and the number you want is probably 2.)

Kay’s solution was straightening the left edge rather than the tail, and that shape landed in Xerox Alto in the 1970s:

Interestingly enough, the top facing cursor returned as one of the variants in Xerox Star, the 1981 commercialized version of Alto…

…but Star failed, and Apple’s Lisa in 1983 and Mac in 1984 followed in Alto’s footsteps instead. Then, 1985’s Windows 1.0 grabbed a similar shape – only with inverted colors – and the cursor has looked the same ever since.

That’s not to say there weren’t innovations since (mouse trails useful on slow LCD displays of the 1990s, shake to locate that Apple added in 2015), or the more recent battles with the hand mouse pointer popularized by the web.

But the only substantial attempt at redesigning the mouse pointer that I am aware of came from Apple in 2020, during the introduction of trackpad and mousing to the iPad. The mouse pointer a) was now a circle, b) morphed into other shapes, and c) occasionally morphed into the hovered objects themselves, too:

The 40-minute deep dive video is, today, a fascinating artifact. On one hand, it’s genuinely exciting to see someone take a stab at something that’s been around forever. Evolving some of the physics first tried in Apple TV’s interface feels smart, and the new inertia and magnetism mechanics are fun to think about.

But the high production value and Apple’s detached style robs the video of some authenticity. This is “Capital D Design” and one always has to remain slightly suspicious of highly polished design videos and the inherent propensity for bullshit that comes with the territory. Strip away the budget and the arguments don’t fully coalesce (why would the same principles that made text pointer snap vertically not extend to its horizontal movement?), and one has to wonder about things left unsaid (wouldn’t the pointer transitions be distracting and slow people down?).

Yet, I am speaking with the immense benefit of hindsight. Actually using that edition of the mouse pointer on my iPad didn’t feel like the revolution suggested, and barely even like an evolution. (Seeing Apple TV’s tilting buttons for the first time was a lot more enthralling.) And, Apple ended up undoing a bunch of the changes five years later anyway. The pointer went back to a familiar Alan Kay-esque shape…

…and lost its most advanced morphing abilities:

Watching the 2025 WWDC video mentioning the change (the relevant parts start at 8:40) is another interesting exercise:

2020:

We looked at just bringing the traditional arrow pointer over from the Mac, but that didn’t feel quite right on iPadOS. […] There’s an inconsistency between the precision of the pointer and the precision required by the app. So, while people generally think about the pointer in terms of giving you increased precision compared to touch, in this case, it’s helpful to actually reduce the precision of the pointer to match the user interface.

2025:

Everything on iPad was designed for touch. So the original pointer was circular in shape, to best approximate your finger in both size and accuracy. But under the hood, the pointer is actually capable of being much more precise than your finger. So in iPadOS 26, the pointer is getting a new shape, unlocking its true potential. The new pointer somehow feels more precise and responsive because it always tracks your input directly 1 to 1.

(That “somehow” in the second video is an interesting slip up.)

I hope this doesn’t come across as making fun of the presenters, or even of the to-me-overdesigned 2020 approach. We try things, sometimes they don’t work, and we go back to what worked before.

I just wish Apple opened itself up a bit more; there are limits to the “we’ve always been at war with Eastasia” PR approach they practice in these moments, and I would genuinely be curious what happened here: Did people hate the circular pointer? Was it hard to adopt by app developers? Was it just a random casualty of Liquid Glass’s visual style, or perhaps the person who was the biggest proponent of it simply left Apple? We could all learn from this.

But the most interesting part to me is the resilience of the slanted mouse pointer shape. In a post-retina world, one could imagine a sharp edge at any angle, and yet we’re stuck with Kay’s original sketch – refined to be sure, but still sporting its slightly uncomfortable asymmetry.

The always-excellent Posy covered this in the first 7 minutes of his YouTube video:

But specifically one comment under that video caught my attention:

Honestly, I’ve never thought of the mouse cursor as an arrow, but rather its own shape. My mind was blown when I realized that it was just an arrow the whole time.

…because maybe this is actually the answer. Maybe the mouse pointer went on the same journey floppy disk icon did, and transcended its origins. It’s not an arrow shape anymore. It’s the mouse pointer shape,and it forever will be.

There are fun things you can do in software when it is aware of the dimensions and features of its hardware.

iPhone does a cute Siri animation that emanates precisely from the side button:

A bunch of Android phones visualize the charge flowing to the phone from the USB port…

…and even the whole concept of iPhone’s Dynamic Island is software cleverly camouflaging missing pixels as a background of a carefully designed, ever morphing pill.

But this idea has value beyond fun visuals. iPhone telling you where exactly to tap twice for confirming payment helps you do that without fumbling with your phone to locate the side button:

Same with the iPad pointing to the otherwise invisible camera when it cannot see you:

Even the maligned Touch Bar also did something similar for its fingerprint reader:

The rule here would be, perhaps, a version of “show, don’t tell.” We could call it “point to, don’t describe.” (Describing what to do means cognitive effort to read the words and understand them. An arrow pointing to something should be easier to process.)

You could even argue the cute MagSafe animation is not entirely superfluous, as over time it helps you internalize the position of the otherwise invisible magnets on the other side of your phone:

In a similar way, as it moved away from the home button, iPhone X introduced light bars at two edges of the screen – one very aware of the notch – as swiping affordances:

And under-the-screen fingerprint readers basically need asoftware/​hardware collab to function:

One of my favourite versions of this kind of integration is from much earlier, where various computers helped you map the “soft” function keys to their actual functions, which varied per app…

…and the famous Model M keyboard moving its keys to the top row helped PC software do stuff like this more easily:

(And now I’m going to ruin this magical moment by telling you the cheap ATM machine that you hate does the same thing.)

The last example I can think of (but please send me your nominations!) is the much more sophisticated and subtle way Apple’s device simulator incorporates awareness of the screen’s physical size and awareness of the dimensions of the simulated device. Here’s me using the iPhone Simulator on my 27″ Apple display. If I choose the Physical Size zoom option, it matches the dimensions of my phone precisely. The way I know this is not an accident is that it remains perfectly sized if I change the density of the whole UI in the settings.

Why am I thinking about it all this week?

The new MacBook Neo was released with two USB-C ports. Only one of the ports is USB 3, suitable for connecting a display, an SSD, and so on. The other port’s speeds are lower, appropriate only for low-throughput devices like keyboards and mice.

To Apple’s credit, macOS helps you understand the limitations – since the ports look the same and the USB-C cables are a hot mess, I think it is correct and welcome to try to remedy this in software. It looks like this, appearing in the upper right corner like all the other notifications:

I think this is nice! But it’s also just words. It feels a bit cheap. macOS knows exactly where the ports are, and could have thrown a little warning in the lower left corner of the screen, complete with an onscreen animation of swapping the plug to the other port – similar to what “double clicking to pay” does, so you wouldn’t have to look to the side to locate the socket first.

“Point to, don’t describe” – this feels like a perfect opportunity for it.

The breathing light – officially “Sleep Indicator Light” – debuted in the iconic iBook G3 in 1999.

It was originally placed in the hinge, but soon was moved to the other side for laptops, and eventually put in desktop computers too: Power Mac, the Cube, and the iMac.

The green LED was replaced by a white one, but “pulsating light indicates that the computer is sleeping” buried the nicest part of it – the animation was designed to mimic human breathing at 12 breaths per minute, and feel comforting and soothing:

Living through that era, it was interesting to see improvements to this small detail.

The iMac G5 gained a light sensor under the edge of the display in part so that the sleep indicator light wouldn’t be too bright in a dark room (and for older iMacs, the light would just get dimmer during the night based on the internal clock).

In later MacBooks, the light didn’t even have an opening. The aluminum was thinned and perforated so it felt like the sleep light was shining through the metal:

And, for a while, Apple promoted their own display connector that bundled data and power – but also bundled a bit of data, which allowed to do this:

Back when I had a Powermac G4 plugged into an Apple Cinema Display, I noticed something that was never advertised. When the Mac went to sleep, the pulsing sleep light came on, of course, but the sleep light on the display did too... in sync with the light on the Mac. I’ve tested that so many times, and it was always the same; in sync.

Just a little detail that wouldn’t sell anything, but just because.

Even years later, some people tried to recreate it on their own:

To do this I shifted the first gaussian curve to that its domain starts at 0 and remains positive. Since the time domain is 5 seconds total and the I:E ratio is known, it was trivial to pick the split point and therefore the mean. By manipulating sigma I was able to get the desired up-take and fall-off curves; by manipulating factor “c” I was able to control for peak intensity.

But at that point, in the first half of 2010s, the breathing light was gone, victim to the same forces that removed the battery indicator and the illuminated logo on the lid.

I know each person would find themselves elsewhere on the line from “the light was overkill to begin with” to “I wished to see what they would do after they introduced that invisible metal variant.”

I know where I would place myself.

This blog is all about celebrating functional and meaningful details, and there were practical reasons for the light to be there. This was in the era where laptops often died in their sleep – so knowing your computer was actually sleeping safe and sound was important – and the first appearance of the light after closing the lid meant that the hard drives were parked and the laptop could be moved safely.

The breathing itself, however, was purely a humanistic touch, and I miss that quirkiness of this little feature. If a save icon can survive, surely so could the breathing light.

Everybody who routinely takes screenshots on a Mac knows very well the motor memory heaven and hell that are the screenshotting shortcuts: ⌘⇧3 to grab the whole screen, ⌘⇧4 to grab part of it, hold ⌃ ahead of time to put the result in the clipboard, press space at the right moment to select a window, hold ⌥ at a different time to remove a shadow, and so on. (Yes, there’s more.)

It’s strange to talk about those shortcuts, because the world is divided into two groups: people who have never used any of these because they are the scariest shortcuts that induce RSI if you just think about them, and people who have used them for so long that their fingers do all the work. Either group would struggle with writing the above paragraph – as did I, needing to watch my hands first, and then take notes.

But: why do the shortcuts start with 3? After all, ⌘⇧1 and ⌘⇧2 don’t seem to do anything.

That wasn’t always the case. Turns out that once upon a time Apple was trying to create a larger universe of nerdy shortcuts for your Mac. The effort is so old – they were introduced in 1986 – that ⌘⇧1 was added as a quick shortcut to… eject the floppy disk. And, since you could also have an external floppy drive, ⌘⇧2 was assigned to eject that, and the shortcuts for screenshots followed in sequence: ⌘⇧3 to save the screen, and ⌘⇧4 to send it straight to your printer. (Even then, there was already Caps Lock thrown into the mix, too, switching between the entire screen and the current window.)

Early BASIC programmers knew to separate their line numbers by 10 because there will always be a line you want to insert in between, but keyboard shortcut designers do not have that luxury.

And so the nice system backfired immediately. Some Macs started coming with two built-in floppy drives, but still allowed you to plug in an external one. What would you press to eject that?

Well, of course it had to be ⌘⇧0, since ⌘⇧3 was already taken.

(In an absolutely delicious bit of rhyming, the 0 key itself is on the “wrong” side of most keyboards – except Hungarian – because it was added to keyboards before the 1 key was! It felt more natural to put it after 9 than right before 2.)

Things were quiet for a while. Floppies disappeared over time. Only in 2018, Apple evolved the old Grab app that it inherited from NeXT into a Screenshot app, and assigned it a new shortcut, ⌘⇧5. That was a nice improvement – video recording, a very helpful timer, a few smaller options, and a bit of a GUI thrown atop for convenience.

There are a bunch of system and change management lessons in here, but I want to talk about something else I just learned about.

Acorn 8, a graphic app, has a delightful screenshotting feature parked under ⌘⇧7 that does something incredible: it takes a screenshot, but does so in a way where windows are separate layers, grouped by app. It’s amazing; you can re-compose stuff afterwards, reveal covered stuff, remove windows, even change the wallpaper. A mouse cursor arrives too in its own tiny layer, like a cherry on top.

I’m sharing this both because I gather people who read this blog take a lot of screenshots – but also because this is software craft. I know “delightful” is (mis—? ab—?)used to refer to beautiful but slow transitions, and cute but distracting UI copy, but this is the stuff of true delight: using newly abundant technology to actually do something useful, and rewrite the rules of something that hasn’t been touched for ages, in a way that feels magical. There is still room for improvement – notably, you cannot just fire and forget a screenshot straight into your filesystem – but I find this kind of stuff inspiring.

I also know what you’re thinking: hey, what happened to ⌘⇧6? I’m not going to tell you. It’s probably not that hard to google it, but maybe you’ll enjoy trying to guess like I did. What was a feature of Macs that arrived after 2018 that Apple would want you to forget about even more so than the floppy disks?