As someone who’s been a keyboard shortcut tzar at a few companies, I developed a certain kinship with the unknown and unnamed others who have the same job elsewhere. It’s a fun but weird challenge, rewarding and unrewarding at the same time, a job of maneuvering a little dinghy between the winds of Motor Memory, the waves of Change Management, and the storms of Shortcut Conventions That Came Before You. It’s a job where you quickly learn you can never really win – but at least you can try not to lose very badly.

One day I’ll write about some of the proudest and darkest moments in my own keyboard shortcut design history, but today let me instead do a short “game recognize game” post. This one is about Arc, a browser that had at least three shortcuts I found myself nodding vigorously at.

In Arc, ⌘S no longer does save, but instead invokes show/​hide sidebar. As far as I can tell, no common shortcut for hiding and showing a sidebar emerged over the last decades, and ⌘S feels like a mnemonically clever takeover of a traditional save shortcut (which in the context of the web doesn’t make sense), and at the same time doesn’t conflict with a lot of web apps, which generally shy away from using it.

Save still does exist, but it has been moved to ⌘⇧S. This historically has been Save As and that also makes sense to me, as you can’t really save a website, just its copy of sorts!

Lastly, Arc’s internal screenshotting function is ⌘⇧2, right next door to the standard ⌘⇧3. Nice.

From its earliest days, Macs established an interesting convention – whenever you press a keyboard shortcut to an action that’s somewhere in the app menu, the matching top menu label blinks quickly.

Here, I am pressing ⌘A (Edit > Select All), followed by ⌘+ (Format > Font > Bigger), and then ⌘B (Format > Font > Bold):

I believe this is meant to help you connect those things better. While you might not need a map to an action that you already know a shortcut for, it might be helpful to tell you where to find other actions like it.

I imagine it also helps whenever you press a wrong shortcut – or the right shortcut under the wrong circumstances – and you want to deduce what happened or what was meant to happen. Knowing roughly where a command “lives” makes it easier to open the menu and look for it, even if you might still have to dig through all the submenus.

Recently, I spotted the programming editor Nova use a parallel technique. In its command palette, commands show their keyboard shortcuts, but if they’re hiding in submenus – also their menu path:

I am not sure how effective either of these techniques is, and both can feel a bit… busy. But they also appear thoughtful – we’re all spatial creatures, and I imagine helping you visualize a map of the entire system of commands can make it easier for you to feel at home.

Buttondown, a newsletter publisher, has a pretty standard CSS editor in its web app. You can edit the code and whenever you make any change, you can then press the Save button to make it go live:

The view also thoughtfully supports pressing ⌘S to do the same thing:

However, if there is nothing to save, ⌘S is ignored by the CSS editor, and falls back to the browser’s handling:

It feels logical: ⌘S only takes effect when the button is visible, otherwise why would a user press it? In a front-end sense, it might even seem thoughtful. We all witnessed web apps that greedily took over some interaction, and broke things in the process. Hell, I did that myself.

In theory, you – the user – take a careful look at the state of things, notice the button, and then press ⌘S.

But in practice? It’s none of the above. Fingers don’t look around. You might press ⌘S twice in a row. Or after an undo to an already saved state. Or after pressing another key so light it didn’t register. Or after just sitting down to an open document that’s already saved. Or because you weren’t sure if the previous ⌘S press worked. Or just to be sure. You might not know why, and you might not even notice. The beautiful raw power of ⌘S as a citizen of motor memory is that it’s automatic, mindless, habitual.

That’s why ⌘S here needs to be both deterministic and idempotent – if there is nothing to save, don’t let it fall back to the browser, don’t show an error message, don’t beep at the user. Just ignore the keystroke altogether.

It might feel funny, but there are tons of places in the UI that already look the other way. Off the top of my head:

• if you center align already center-aligned text in any writing app, the app just ignores you,
• if you press ⌘A to select all more than once, no one’s shouting at you,
• if you try to click a disabled button, the click gets quietly swallowed.

It gets a lot more interesting than these, but we’ll talk about more examples of “finger logic” in future posts.

In 2018, Tom Cruise and Christopher McQuarrie teamed up to make a short PSA about the dangers of frame rate interpolation, a.k.a. the soap opera effect:

It’s a strangely boring video from the men known for exciting filmmaking, but it captures a fascinating debate. TL; DR of their argument: Home TVs have an option to take a typical 24fps movie and create interim frames to make it feel like a 60fps production. It’s often on by default, but you should turn it off.

What’s interesting is that 60 or more fps is indeed in some ways objectively better: you see smoother movement, and you can notice more. Once you start paying attention, any whip pan or drastic movement in the cinematic 24fps appears very choppy…

…and, of course, that is completely missing the point. The argument for 24fps is that it’s simply cinema’s vernacular, right next to anamorphic lenses with their blue lens flares and vertical stretching. The movies are not about conveying information, but they are about conveying a certain feel. (And also, about tradition.)

I’m mentioning this because I spotted a similar battle happening when it comes to scrolling.

Go to any page in Vivaldi and hold a down arrow key for a while. That scrolls through the page, moving it in chunks, reacting immediately to the initial key press and then the synthesized autorepeat presses:

Firefox listens to the keys the same way, but it “upgrades” the choppiness to a 60fps movement by interpolating it:

And Safari does something different altogether – it approaches it more like a game physics engine would. It only listens to ↓ down (when it turns on the scrolling “motor”) and then ↓ up (when it turns it off):

This has an interesting effect: the movement is smoother than even Firefox’s – that’s because it doesn’t try to straighten something choppy, but it is itself smooth, by nature.

At the same time, this approach feels a bit loose, like driving an old 1960s car. It also takes away any control of speed; Safari pages always scroll at this rate, no matter your keyboard settings. (Arguably, however, control via the key repeat rate that other browsers respect is also an illusion, as it affects typing as well. Would you ever change it just to control the scroll speed?)

Of course, the analogy to frame interpolation doesn’t really make sense. Safari is not a soap opera, Firefox is not a smooth motion effect on your TV, and Vivaldi is not a cinematic experience. In contrast with movies and television, I don’t think there are any expectations or tradition here.

In this particular context, I believe Firefox and particularly Safari are better because this is about conveying information, and smoother scrolling does help your eyes and your brain connect all the little befores with all the little afters.

But I am sharing it mostly as a reminder that a keyboard is really just a button board by a different name. And sometimes it’s good to look at a key hold, and decide:

• is this a sequence of pulsating key presses,
• or is it a button being held down and then released up?

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.

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

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

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

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

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

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

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

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.

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.

The last post about the Nothing Phone not buffering its button presses reminded me of something.

Here’s IBM Selectric, a 1961 typewriter:

Past decades get compressed into a singular point in time, so we might all think of Selectric as “yet another old typewriter,” and I definitely did before learning about it. But the Selectric came 80 years after the first typewriters, and it packed so much user-benefitting innovation it really was an iPhone of its time. (Alas, I don’t believe there was a matching “are you getting it?!” keynote.)

Selectric was, honestly, a triumph of engineering. It popularized swappable typewriter fonts, showcased good industrial design, enabled jam-free typing, and even invented – although that came a decade after its introduction – an actual destructive Backspace. Crucially, on day one, its typing experience was so fantastic that many of the keys on keyboards we’re using 60 years later are still in the same place Selectric put them.

What’s even more impressive? Selectric was purely electromechanical. It had no software, no chips, and no electronics. Everything it has accomplished was expressed in the mechanical language of steel, grease, links, and levers.

Here’s one problem that’s trivial in software, but hard in hardware: How do you prevent people from pressing two keys at the same time?

This is a thing that plagued typewriters since day one, and IBM’s engineers came up with a smart solution: each key was connected to a bar (interposer), each bar had a little protruding notch (lug), and that notch would smoothly dip into a little horizontal row of steel balls (selector compensator tube).

The balls had just enough wiggle room for one notch, so if you tried to press a second key at the same time, the balls would now be packed tight, there would be no room to accommodate the second notch, and the key press would be blocked.

I thought that was really clever, but it was even more clever than that. If you read my essay, you know it starts with the very notion that fingers overlap: as one is going up, often another one is already pressing down. If you were to block any second press before the first press was completely done, you wouldn’t be able to type very fast – and Selectric was meant to be a professional typing tool.

Here’s where the choice of the carefully sized and arranged steel balls came into play. In practice, the second press was not completely blocked. The lug was able to slide just a little bit in between the adjacent steel balls. It was a half press – or, effectively, a half-character buffer. It was all fine-tuned just enough to not impede overlapping typing, while still offering protection from two keys at the same time.

Now, if Selectric did this, in a universe where creating even a half-character buffer meant a little row of carefully machined steel balls, and added weight, and anticipating future wear and tear, and multiple pages in the maintenance manuals… what’s your excuse?

In my three decades online, it has never occurred for me to try this, and I found it so delightful once I did – both Chrome and Firefox will quietly rewrite backslashes in URLs into slashes:

Not Safari, however, even though the URL living standard says it should.

I am very curious if the presence of backslashes in URLs is owing to Windows still showing backslashes in file paths, or just because people casually don’t see any difference between / and \, which are arguably both similar, and relatively alien in everyday typography. (“Solidus” is the proper typograpical name for this kind of a slash, partly to disambiguate it from all the other slashes with their equally fascinating names.)

Even before the “remaster,” my essay about the Polish S bug was routinely discovered by Hacker News and other places, so I thought I would take a look at all the commentary over the years and summarize.

First, pragmatically, these are the lessons for any keyboard shortcut designer:

• On Windows, AltGr (Right Alt) and Ctrl+Alt shortcuts are one and the same, and Right Alt and alphabetic keys are used for some languages to output regular accented letters. You should not prioritize Ctrl+Alt shortcuts anywhere your users write text.
• On a Mac, ⌥ and most keys generate characters. They do so even on English layout for extra typographical flair, but particularly in other languages, regular accented letters might hide there. Note that these are not just letter keys, but also digits and other keys. You should not prioritize ⌥ shortcuts anywhere your users write text.

I couldn’t find a good image, so I made these two as an example. First is Mac’s American keyboard with ⌥ held. Second is Polish keyboard with ⌥ held, with Polish letters highlighted:

Jumping to the promised comments, I liked this story:

Outlook has a shortcut Alt+S to send the current e-mail. In Polish “Hello” is “Cześć”. When you acidentally have non-Polish locale enabled and write “Cześć” in Outlook - you send “Cze” as your whole e-mail.

“Cze” is a very informal greeting, sth like “Yo”. There has been thousands of such e-mails in Polish companies sent to people who really shouldn’t be greeted with “Yo.” :)

Here’s a little summary of other similar bugs. I verified some of them:

• “Oh, that explains why I accidentally triggered Claude with Alt+Space, despite it being configured as Ctrl+Alt+Space.” Link
• “Noticed similar issues with official Australian VISA / immigration pages. You can’t simply fill some forms with your email address using Finnish keyboard. Why? Because they block usage of AltGr button on their page. They also prevent using clipboard blocking copy paste option for that sign. User has to be smart enough to switch to US keyboard and then enter @ sign and then switch back. So this is nothing new, but it’s absolutely rude from part of the site designers to vandalize basic functionality like that. Normally @ is produced by AltGr+2.” Link
• “In a similar fashion, you cannot type the capital letter Ł in Notion. You type the letter with ⇧⌥L on the Polish keyboard on a Mac. Notion uses the ⇧⌥L keyboard combo for its own purposes.” Link
• “Medium learnt its lesson in 2015. Google still hasn’t and you cannot type Ś in Sheets, at least not on MacOS.” Link
• “Meanwhile, in 2026 I suddenly cannot type capital Ś in Edge on Mac. I feel like I moved back in time 25 years or so.” Link
• “I wonder if it is a similar reason why currently on MS Teams I can’t type the letter ń.” Link
• “It’s just like the new Copilot 365. Every time I try to type Ć, Copilot pops up. I have to close the app constantly.” Link
• “I had a similar issue when ASUS’s bloatware background service decided to bind something to both Alt+S and Alt+A globally. I have to keep it disabled or else I won’t be able to type ą, Ą, ś and Ś without using Caps Lock to work around the issue.” Link
• “In an Nvidia overlay there is a shortcut Alt+Z. It’s pretty annoying because it triggers on both left and right Alt, so polish users cannot type letter ż without opening the overlay or rebinding it. Nvidia pls fix.” Link
• “The very same bug used to be present in early Windows mobile GPU drivers - with global hotkeys making it impossible to enter Ł (with Intel GMA 950) and Ć (with ATI Catalyst). Being a Polish geek, I used to earn lots of free dinners from frustrated friends who were forced to copy-paste those letters on their brand new laptops. Funny how the same bug recurs in different types of software due to an obscure locale-dependent edge case - and it’s much less known than, for example, the Turkish dotted/​dotless I.” Link
• “Installing KeePass used to silently disable ”ą” key (AltGr+A hotkey). KeePass broke system of every Polish user immediately after being installed.” Link

I’m sharing this for awareness. I believe many other languages/​writing systems also have this problem; the examples are lopsided toward Polish only because my original example was about Polish.

Lastly, I found this an interesting anecdote:

In Portugal we had a similar workaround in the early days of computers not supporting our alphabet properly. Like in Polish there are plenty of words that without diacritics get another completely unrelated meaning, e.g. caça vs caca, which you didn’t want the interpretation to be left to the receiver.

So tricks got invented, like adding additional letters for the missing diacritics, é becomes eh, è becomes he or eh as in the former case, the example above would be cac,a and so on. However it was still quite flexible, not everyone uses the same extension set.

I wouldn’t be surprised if every single language outside of English developed some sort of a way to cope and adjust to limitations of originally American-oriented computers. In my book, I wrote about Japanese and Turkish, and there is another book – The Chinese Typewriter – that spends a lot of time talking about this very issue for China.

If this subject is particularly interesting to you, venture out into the Hacker News waters to see more commentary: 2015, 2021, 2024, 2026.

Speaking of remastering (and diacritics), I grabbed my older Medium deep dive called The curious case of the disappearing Polish S, and put it on the new site.

It looks so much better than on Medium and while I was at it, I’ve redone all the visuals, and updated it a little bit.)

It’s still probably one of my favourite bugs to encounter. I hope you enjoy!

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

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

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

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

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

A nice blog post by Nathan Manceaux-Panot on Pending Design about the subtle design of the tabs underneath the search results in the programming editor Nova:

Through buttons right below its text field, the bar also lets you filter results: only show files, only show symbols, or only show symbols in current tabs. Here’s the thing, though: each one of these buttons has four distinct purposes. They’re not just for clicking.

The tabs are clickable as they normally are, but they’re also a treasure map (to tell you something is possible), a cheat sheet (to remind you how to do it again), and an onramp for faster keyboard navigation.

I’d add two more things to the celebration:

• I myself often forget onboarding is not just about the first run, but also about reinforcement. Here, this UI does a lot of reinforcing over time, helping you build the habit. Pressing the key highlights the tab. Clicking on the tab adds a key as if you pressed it, and so does using an advanced shortcut (e.g. ⌃⌘O instead of ⇧⌘O). Even slash as a symbol comes from path names, so you might naturally associate it with files.

• The search pop-up always has a nice contrasty appearance: dark when the background is light, or vice versa. Many modern interfaces go for white background for every UI element and surface. This seems like solely an aesthetic choice, but has more consequences when it comes to visibility of things, and even hierarchy. I am personally always excited when I see a duochrome app these days, because it feels like the team knows what they’re doing and isn’t just chasing visual trends. (Below is an example from Bear.)

The biggest smallest GUI design schism between Apple’s platforms and Windows isn’t the black vs. white cursor or where to put the menu bar. It’s the presentation of keyboard shortcuts.

On a Mac, the shortcuts are iconographic. Command is ⌘. Option is ⌥. Shift is ⇧. Control is ⌃. Fn is 🌐. There are also icons for all the other non-printing keys, from the relatively well-known Tab (⇥), through the perennially confusable End and PgDn (⤓ and ⇟), to the absolutely cryptic Esc (⎋).

On Windows, the keyboard legends are mostly text. PC lost the icon battle in the early 1980s – IBM had them on their 1970s computers, worldwide, but apparently American users of the early IBM PC hated them – and the names are spelled out (Shift and Enter and Home), or close to it (Ctrl, Esc, PgDn, Prt Sc).

Why did Apple go this way? My speculation is the revered Braun and generally hi-fi hardware: a lot of stuff sold in Europe defaults to iconography in part because that makes exporting easier. Icons are also more compact – putting ⇧⌘C in a menu or a tooltip takes up a lot less space than Shift+Ctrl+C – and more beautiful when done well. Here’s Figma’s right click menu on Mac and Windows:

But there are also challenges, as icons are more cryptic and confusing. “Command” tells you something about itself out of the box, but “⌘” is completely abstract. (Arguably, only arrow keys and symbols like ⇥ and ↵ explain themselves visually.) The attendant issue is that icons are hard to talk about if you don’t know their names, hence tons of jargon like “propeller,” “splat,” or “beanie” for ⌘, for example.

It’s a hard situation. Here is one of Mac’s own menus being thoroughly inconsistent, and an example of CleanShot using both the icon and the label to be sure:

“Why not both” seems to be the best way in places you can afford it. Apple started doing that on the keyboards too, but it took them decades to get there for modifier keys alone. Even on the 2026 computers, many other keys like Esc and Tab are still single-legended:

With all that in mind, I want to show you what I saw the other day in Google Docs, on my Mac:

This is one of those cryptic things that I would love to understand the thinking behind. Because, on the surface, this breaks so many rules:

• A strange hybrid of Mac and Windows styling: some modifier keys are spelled out, and the others are iconographic. (It’s very strange to see ⌘ conjoined with others using a plus!)
• Complex and generally uncommon dual key shortcuts – to collapse the sidebar, you really need to press ⌃⌘A and then press ⌃⌘H, in sequence.
• Three-modifier-shortcuts are in general really unpleasant and Google Docs does not seem complicated enough to warrant them.
• (You can’t see that, but they’re also unreliable! ⌃⌘A ⌃⌘H doesn’t always work and seems to depend on where the focus is.)

There is also a visual argument that cannot be ignored. We’ve been there once before; if in your menu keyboard shortcuts start overwhelming the commands themselves, you are probably doing something wrong.

The only explanation for this I can think of off the top of my head is this: these were invented somewhere else (Word?) and inherited by Docs to respect motor memory of the users transition from the older app. That still doesn’t cover the presentation, plus there is a way for Docs to redesign the shortcuts to be better for people who are starting anew.

Ultimately, I think all of this also breaks a cardinal rule: it makes keyboard operation feel more scary and intimidating than it needs to be. Shortcuts are scary enough on their own, and they don’t need any help in this area.

Chrome’s find option, like every search coming from a good home, does something clever with accented characters – it normalizes them:

No matter whether you search with a proper accented character, or with its basic Latin equivalent, all the same stuff matches: The “ø” letter is treated the same as “o” both in the input field, and then in the search itself.

Yet, Chrome’s tab search inexplicably doesn’t do that, which confused me when working on a post about diacritics earlier this week. Here, it should match all four open tabs:

Tab search was introduced years ago; the Occam’s Razor says this isn’t a recent bug, but that the feature has always behaved like this. I filed the bug, but even if it gets fixed quickly, I think this doesn’t reflect well on Chrome’s team. If the right code already exists for ⌘F, why not reuse it? If it cannot be reused, why not repurpose at least its unit tests or the QA process to make sure this doesn’t fall through the cracks? Normalization should be treated as a core property of any search, rather than an optional “nice to have.”

But, Marcin, didn’t you just invalidate your assertion that diacritics actually matter? After all, wouldn’t you input “nestlé” instead of “nestle” if they did?

To this, I have a few answers:

• Input is not output. This is no different than autocorrect, autocomplete, or other IME helpers.
• The very fact that on many keyboards accented characters are hard to input is itself a sign of anglo-centrism of companies that made early typewriters (Remington, which established a lot of European layouts like QWERTZ and AZERTY, employed a person who bragged he didn’t actually speak any languages in a “how hard could it be” way) and then most microcomputers.
• There is this really interesting rule, also known as Postel’s Law: “be conservative in what you output, but liberal in what you accept as input.” It’s not universally applicable – sometimes it’s better to teach the user to be more explicit if it benefits them in the longer run – but it feels appropriate to me here.

Why does it matter specifically for the ⌘F and the tab search experience? I have this personal theory: the simplest the search, the more the users will blame themselves if it doesn’t work, and assume the tab or the string just isn’t there, rather than rewrite their query. That’s what happened to me. I assumed that the tab wasn’t open and tried to get to it again, wasting time and effort.

The rule might be universally true for any UI surface – the tighter it gets, the less likely we assume it can break. After all, there is a manual for a typewriter, but there isn’t one for the pencil! And these UIs do feel positively basic; they are small windows with basically one input field and an immediate as-you-type reaction.

Randomly found this 2014 Dribbble from Jamie Nicoll and it made me smile:

For context, Save For Web was a popular export function in Photoshop at the peak of its use for web design, but assigned a rather unpleasant ⌘⌥⇧S shortcut. Using it often turned your hand into a… claw of sorts.

There was a Tumblr cataloging real and humorous photos of people pressing Save For Web. You can still find parts of it on Internet Archive, and here are some choice photos:

This is funny, but I actually found it enlightening – and lightly frightening – to ask coworkers how exactly they press common shortcuts like ⌘Z, ⌘C, ⌘V, and so on. There was a lot more variety than I expected.

(My basic heuristics say: three-modifier-key shortcuts should not be assigned to anything used often.)

In our Unsung yellow pages, in between people writing Chrome plugins to fix UI of other apps, and gamers creating mods to fix bugs that the developers leave behind, we need to make some room for another category of apps.

Some time ago, Daniel Kennett created a little utility called Keyhole with a singular purpose:

Have you ever been annoyed by your Mac’s media keys triggering a random video in your web browser, doing something else weird, or by them doing… nothing? Even though your music player is right there?

Me too! And so Keyhole was born.

Keyhole intercepts media transport key presses before the operating system gets a hold of them, and promises to do a better job dispatching them to the right place.

This week Kennett added another feature – the app will monitor the repeat setting that apparently occasionally gets out of whack, and fix it for the user.

We could call these kinds of apps “janitor apps.” I know of a concept called cron jobs, but I’m assuming these quiet workers do backend-y things like moving files around, cleaning up databases, pinging servers, and so on. I am less aware of work like Kennett’s that fixes stuff on the UI layer.

Is it strange that I find this kind of an app pretty… noble? Of course, Apple should fix it; perhaps Bugs Apple Loves could even introduce a serious multiplier for “a bug bothers someone so much they fix it for Apple.”

Of note in the last dialog box: “Keyhole has fixed Music’s repeat setting X times.” I think this kind of a counter is pretty brilliant.

To follow up from yesterday’s post, in Figma, object selection actually goes onto the undo stack. This is because in a professional tool with objects in multiple levels of hierarchy, it might take a while to construct a selection to work on – and since selection is always just one accidental click away from being completely cleared, undoable selection is extra protection.

However, at the same time renaming a file – or changing settings like file access – is not undoable. This is in part because we didn’t feel people would understand they could cancel out their rename this way (Safari too used to have “reopen last tab” under ⌘Z, until it reverted to Chrome’s ⌘⇧T), but mostly because you could accidentally undo through a file rename during regular work if you were not careful, without noticing, and that felt like it’d have more profound consequences.

In some ways, it helped me to think of these not as “ineligible for undo” but rather “living outside of time.” The moment a file is renamed, it will always have been named that way. (For the purposes of undo, at least. You can acknowledge anything you want on the version history screen.)

I’m not saying these are universally correct choices – as a matter of fact, some users find undoable selection (at least initially) pretty confusing! – but mostly sharing these as examples of intentional thinking about what deserves undo, and what should be exempt from it and taken care of elsewhere.

I have been working on an essay about how to gently get started and have fun with keyboard customization. I am finding myself surrounded by programmable keypads…

…and I am going out of my way to try various new shortcuts and automations, big and small, just so I can write a helpful article.

In Photoshop, one of the classic dialogs I use a lot when scanning things is brightness + contrast:

It doesn’t come with a keyboard shortcut, so I mnemonically assigned ⌘B (for Brightness) to it. ⌘B is easier than using your mouse to select a menu option, but still tedious in the long run; every time I have to input brightness and contrast numbers, then click on Use Legacy which is not sticky, then realize that enabling Use Legacy inexplicably resets the values I just typed so I have to input them again…

…which really isn’t as much fun 20th time in a row, 20th year in a row.

So imagine my surprise when one day I invoked the dialog, and it came up looking this out of the box:

It somehow remembered the previous settings. How? Why? Was that a new thing? Was that a bug? Did the stars align or did they misalign? Figuring out how to make it do this every time would have save me so much trouble.

I dug deeper and figured it out. On the way to ⌘B, my fingers grazed the ⌥ key. This invoked a “use same settings as last time” option I never knew existed. This option would have been a lifesaver, has been there for god knows how long, and I just discovered it by accident. Moreover, it wasn’t just a feature of this dialog. One can hold ⌥ for many more Photoshop dialogs – a thoughtful system to make repeated tasks faster.

Damn.

This reminds me of something. I am curious if you’ve seen what I’ve witnessed probably ten times by now: once in a while my corner of the internet overflowing with awe when someone shares that on the iPhone, you can hold the spacebar and it functions as cursor control:

Inevitably, tons of people are always amazed and excited, proclaiming this is the best thing since sliced silicon wafers…

…and that always make me a little sad inside. Both this and my ⌥ story feel like failures of onboarding, of software growing with you and sharing its motor-memory nooks and power-usery crannies. If a helpful thing exists, but people don’t know about it, it feels worse than it not existing. Imagine all these interactions made more pleasant, all these hours saved, all these flow states undisturbed.

I want to spend more time on this blog highlighting onboarding and conveyance done well – I just shared a tiny example a few days ago – particularly since this feels to me like an area underinvested in. If you have a story of an app or a service doing this well, I’d love if you could share it with me so I can highlight it and we can learn from it.

A few years ago, I suggested adding a new interaction to Figma. If your text cursor was on a misspelled word (anywhere inside, or the edges), you could press Tab to quickly accept the suggested correction, without even seeing it:

Independently, Google Docs approached it from a slightly different angle, but landing on a similar interaction – in their version there’s a small visual callout, although you can still press Tab (and then Enter) to accept the suggestion:

I know the Tab key has a lot of jobs – from indenting bullet points to jumping through GUI elements – but in this context this new addition doesn’t seem to be in conflict.

(Should I write a long photoessay about the Tab key, similar to the ones I wrote for Return/​Enter and Fn keys?)

Since we added it, I’ve really loved how it feels. From various typeaheads and autocompletes elsewhere, Tab has a strong “forward movement” energy so it makes conceptual sense, and it’s just really fun to go around and quickly fix your writing this way.

I think a lot about how to make keyboard interactions feel superpower-y: a good keyboard shortcut on a large key, a tight interaction, a blink-of-an-eye velocity – something that’s eminently designed to lodge itself in your motor memory as quickly as possible, as it builds on top of prior motor memory. I’m biased, of course, but I like the “no scope” Figma version more, and it has that feeling to me.

I just published a new photoessay about the history of the Fn key, and particularly what Apple has been doing with it recently.

Do we need yet another person crashing out about Apple’s design decisions? Am I doing it only because it’s fashionable to be on Apple Design Hate Train these days? I’ll be honest: I don’t know.

But I have been bothered by Apple’s approach to this aspect of its keyboard design for a while, because it starts breaking what I think is really important in using a computer well: keyboard shortcuts.

I hope it’s also a fun visual history of the most tricky of modern modifier keys.

(And if you like it, I linked to a few of my other keyboard essays in the footer.)

I just stumbled upon a nice little power-user innovation in Chrome’s Web Inspector.

In Safari, and previously in Chrome, when editing CSS properties, you’d get a usual editing typeahead for the property name, and then the same on the other side for the property value.

In newer versions of Chrome, the typeahead menu works as before on the right side. However, the menu on the left side also includes the right side.

I think this is really clever in this context – not just to speed you up, but also to aid understanding. Just like the inert mouse up and down in the previous post could serve as a safe “peek” into the values, this new interaction can quickly allow you to explore the CSS space if you are curious, or if you only lightly remember part of the name, or even just one of the values.

This blog is authored in Apple Notes, and some time ago Notes added quick linking via typing >>, and that has a similar effect: The interactions are so nimble and precise that it is very easy to link to something, but a nice side effect is that it also feels very welcoming just to type a few letters to remind yourself of a title of an article, and then cancel out.

The downside of the Chrome change is, well, more stuff matching, but I think the audience for this UI is going to be okay with that.

One of the most mysterious keys on the PC keyboard has always been Scroll Lock, joining Caps Lock and Num Lock to create the instantly recognizable LED triumvirate:

Scroll Lock was reportedly specifically added for spreadsheets, and it solved a very specific problem: before mice and trackpads, and before fast graphic cards, moving through a spreadsheet was a nightmare. Just like Caps Lock flipped the meaning of letter keys, and Num Lock that of the numeric keypad keys, Scroll Lock attempted to fix scrolling by changing the nature of the arrow keys.

This is normal arrow key usage in Lotus 1-2-3, doing what you’d expect, if likely a bit slower:

And this is Lotus 1-2-3 with Scroll Lock enabled. Here, the arrows do not move the cursor, but move the spreadsheet:

(You can play with it yourself!)

In time, scrollbars helped with the problem, then mice with wheels solved it in one direction, and then trackpads in both. (Although even though my 2025 Windows laptop doesn’t have a Scroll Lock key, its onscreen keyboard does, and the key still works in Excel.)

But, I grew to believe that UI problems never fully die, and often come back dressed up in new clothes.

This is the TV app on my Apple TV, doing movement as you’d expect:

But Netflix a while back picked a different approach – scrolling almost as if Scroll Lock was on:

More recently, I saw that approach spread to HBO Max and YouTube apps as well:

Is this good? To me personally, the Scroll Lock-esque approach feels strange and claustrophobic. I see the (hypothetical) value of keeping the selection in one place, but the downsides are more pronounced: things feel lopsided, going back in this universe is flying blind, and the system creates strange situations at the edges, where Scroll Lock struggled as well.

And yet, given I just dated myself by reminiscing Lotus 1-2-3, I’m curious how it feels to others.

I’m slightly suspicious of this story (and the video inside) that Unix commands were made so short (cp instead of copy, mv instead of move, ls instead of list, and so on) because the console keyboard had really unpleasant keys.

I imagine it must be a confluence of many things, not just this one. Shorter means faster even with amazing keyboards. Shorter also means the commands travel quicker over the slow modems of the era. The downsides were limited: the early nerdy user base of Unix could handle the extra confusion.

On the other hand – no pun intended – I typed on the keyboard on the picture and I can confirm it is absolutely, positively atrocious, with the tallest keys you have possibly seen:

At any rate, it’s a good a reminder of the power of motor memory, and the difficulty of change management. Even the worst keyboards imaginable are so much better now, and the modems so much faster. And yet, the short and confusing commands remain to this day.

Fun little story by Bruce Horn on folklore.org about the original Mac and how modes are sometimes good:

We went to quite a few stores in the week or so after the introduction, and found that, without exception, every Mac’s floppy disk had a garbage name! They were all named something like ”;lkakl;rt;klgjh”, as if someone had just randomly typed characters to see what would happen. Which is exactly what they did.

In the Finder, the startup disk would appear on the desktop, in the top-right corner, ready to be opened. The Finder would initially select it; once selected, typing would replace the current name, following the modeless interaction model that I had learned in the Smalltalk group from Larry Tesler. This meant that whatever anyone typed when they first came up to the Macintosh would end up renaming the disk.

On the early Mac, just typing with any item selected renamed it, which caused all sorts of trouble.

The eventual solution for renaming that survives until today was: click to select and then click again to rename… but don’t click too fast, because that’s double-clicking, and that means something else. Windows, starting in Windows 95, did something similar, but also put rename under F2 – so at least you didn’t ever have to wait.

I liked the emergent behaviour from some graphic apps which put rename under ⌘R. It’s not that hard to make Finder work that way – see below – but I have always been curious why Mac or Windows didn’t steal this solution.

(Added later: People reminded me that of course Enter also renames, and does so immediately. I wonder why it slipped my mind in this context – possibly because in any other list or similar place, Enter would be the equivalent to opening? Maybe I’m discovering in slow motion how unusual Finder can be in its details compared to conventions we established after.)

Appreciate little moments showing utmost keyboard orientation in Raycast.

The millisecond you hover over the back button, the app says “you should be using the keyboard for this”:

I am not sure you often see tooltips on buttons, with keyboard shortcuts only:

Every select menu – even those with literally two options – has an inline search:

Party like it’s 1983! Or 1982! Or 1967!

Also, unrelated, love the clarity of this panel. This is what’s synced. This is what’s not.

A really interesting convention I just spotted in DevonThink that shows the shortcuts as soon as you hold ⌘, although it feels a bit clunky and cheap in execution.

(The main worry here for me would be that it’s distracting if you already know the shortcuts. I haven’t noticed it disappear if you use it, but maybe it does after a while.)