It is one thing to draw attention to a hiding place that can be seen, but it’s a different challenge altogether to have to point to something that’s not even on the screen.

Let’s rewind to iOS 18 two years ago, and what happened when you swatted away a notification – the movement was nicely reversed, with the UI going back where it came from.

A year later, in iOS 26, the movement was generally similar, with a new, more bubbly and “physical” treatment – but also a rather big bug where the background disappeared on the way out. Yikes.

This year’s iOS 27 redeems itself in two ways. It not only fixes the animation quality, but it does something even better – it starts and ends the notification reveal in a little bar under the clock.

As far as I understand, iOS has consistently been using those kinds of edge bars as signifiers of available edge swipes ever since iPhone X, and this new transition feeds nicely into this system. There is a difference between top drag from the left (notifications), and top drag from the right (control center), and this not only helps convey that, but also perhaps teaches some users about what an edge bar means – so that they know what to do if they see it elsewhere.

I do miss the movement simplicity of iOS 18 – a lot of liquid glass feels too… liquid to me – but I like that this evolution also improved the animation on a slightly higher level.

Yet, one has to be careful.

Here’s YouTube’s animation that plays when you invoke “save to Watch Later”. It’s a concept similar to the iOS 27 choreography above – seeing the item hide itself inside “You” should help in knowing that’s the place to go to get it back – although the execution feels rough and not up to iOS standards:

However, the team hasn’t fully thought through the implementation, and this is what happens on the iPad:

I believe this is a bug where the left padding from the toolbar below was not added to the confirmation toast position – but its consequences are not just the animation feeling janky. It also teaches the user a wrong lesson, as the item accidentally lands on the Home icon instead.

While I didn’t have as much fun with car lights, I experienced another nice motor memory moment last week when using CarPlay.

During my drive, I wanted to ask the new Siri something – but as only an occasional driver, and my phone out of sight, I was puzzled as to how to actually invoke it.

I did see the new Siri app icon appear in the sidebar on the car’s screen, but tapping on that only showed me a list of prior conversations. Sure, I could probably initiate a new chat by tapping the button in the top right corner, but that corner felt really far away from where I was sitting, and didn’t feel inviting to someone who – just as a reminder – was driving a car at that time:

So before giving up, I did one thing that somehow felt very natural – I pressed and held the “home” button in the bottom left corner:

And… it totally worked.

I feel that with any good motor memory story, your fingers do something seemingly on their own, and then it’s up to you to figure out why they did so.

I believe in this case they did so because Apple built a good set of overlapping gestures and expectations:

• In many other places – iPhone, Apple TV – you long press a physical button to invoke Siri.
• Also, on Apple’s touch devices and on Apple TV, “long press” on a touch target has been a consistent entry point to an “advanced function” in a same way right click is on desktop.
• Lastly, on earlier iPhones asking for Siri was literally a long press of the physical home button:

So, kudos to the many designers on sustaining a stable gesture system that lasted decades, and embedded itself in my fingers so well that it felt completely natural to invoke in a situation I really wasn’t allowed to split my attention or play with the interface.

An extra delightful moment in that last video – note how the physical home button and the virtual Siri button match in size.

1.

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

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

2.

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

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

3.

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

4.

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

5.

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

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

6.

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

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

7.

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

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

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

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

Completely unrelated to software, but sometimes stepping outside is what’s needed to develop perspective and find creative solutions – this is Practical Engineering’s video about the many electrical plugs and sockets in America:

There are a lot more socket kinds than I expected, and sprinkled in between are some useful observations about system design, change management, power users, backwards compatibility, and consistency vs. inconsistency – in my head, that last part puts this video right next to the previous post in my brain, even if they seem nothing alike.

Also, that early video snippet from the 1920s?

Jesus Christ. What a UI.

A few nice moments that caught my attention in Marek Minor’s case study of designing icons for Cursor.

The diagonals for “cancel/​wrong” icons are always backslashes, and all the “positive” icons are always slashes:

There is a system that provides 1-to-1-and-only-1 mapping between a concept and an icon:

The point of the table is that each “What’s the icon for [X]?” has exactly one answer, and keeps having exactly one answer as the product grows. Without it, a set slowly develops two icons for the same idea, and at that point it stops being a system.

And, on the page itself, a few nice blink-comparator-like vehicles with subtle text animations:

Ivory is a Mastodon client, and their account switcher has a few interesting mechanics.

The standard one is that you can tap on your avatar, and get a menu in response:

But you can also drag down on the avatar, and get a different reaction:

This, I believe, is meant to be a slightly faster way. The settings option is gone to simplify, and the whole thing looks and feels more… gestural, in lack of a better word.

But I think it also serves one more purpose. The moment I saw this, I thought to myself “I wonder if I could just swipe on the icon itself?” and, lo and behold, this is actually possible:

Why does it matter?

I think for some power users of social media – perhaps people doing it professionally – you switch accounts all the time, and investing in this interaction being fast and smooth is important.

This whole small interaction system feels similar to switching apps on a Mac. You can choose an app in your dock with a mouse (the slow, but well-lit way). You can then learn to use ⌘⇥ and hold ⌘ to get to it quicker from a temporary menu. Eventually, you will also start tapping ⌘⇥ quickly, skipping any visible UI surface altogether.

There is also something great in seeing an interface that grows with you, or one where you can say “I wonder if…” based on your prior interactions and expectations, and the interface actually rewarding you for that thought.

Dragging and dropping files with your mouse in the Finder is nice, but there are many moments you wanna reach for the keyboard instead. Finder supports that. You dragged the file to a wrong place by accident? ⌘Z can undo it in a jiffy. You already have the right windows open? ⌘C and ⌘V can start a copy faster than the fastest of mouse gestures. And for cutting, there’s always…

…well, no, there isn’t. To the best of my knowledge, the Cut item in the menu never lights up around files or folders; you simply cannot ⌘X or cut in the Finder.

I think I understand the reasoning here. Of the Fantastic Four that is ⌘ZXCV, it’s ⌘X that is the truly dangerous one. Putting something in a clipboard is always a balancing act – a moment of inattention, and ⌘X turns into Delete. We generally accept it for text because the stakes are not very high, and text undo is basically too cheap to meter. Even then, occasionally, disaster strikes.

For files, the stakes are quite a bit higher. The creators of the File Explorer in Windows knew all that – yet, Cut still works there:

The way this is done is that the file isn’t immediately removed and put on the clipboard. No, only the intention of cut is registered – one half of the handshake, if you will – but the file stays put and nothing happens until the deal gets closed via a subsequent paste.

Or, almost nothing. There is a signal that ⌘X took effect – the cut files turn slightly transparent to indicate they put on their shoes and they’re ready to go. But if you don’t finish the paste, they become solid again the moment you cut something else, or when you restart the computer. (I wouldn’t be surprised if there’s a timeout, too, although I couldn’t verify that.)

I am not sure why macOS doesn’t do it the same way, particularly since they have a half-finished state designed already, for copying larger selections:

This feels like a strange omission I don’t fully understand, particularly given that it was vintage Mac OS that put the ⌘XCV combination on the map:

What’s even stranger is that the Finder has a command to move files – but an unusual one, buried inside the secret area in one of the menus, as an ⌥ alt to Paste:

It works. By putting the action on the other side, it avoids the “file floating in outer space” challenge, too. But it’s so undiscoverable that even though Move Item Here was introduced in 2011, I only learned about it a month ago as I started researching this more – and even though I know about it now, it still feels profoundly alien, being on the wrong side of the cut/​paste continental divide.

In a reversal of typical state of things, it feels to me is that it was Mac that did a simple/​cheap thing, and Windows that spent extra effort to dress it up into clothes of an existing Cut for reasons of familiarity, consistency, and better experience. Sure, a keyboard way to move files like Move Item Here is somewhat valuable, but nowhere near as valuable as a traditional cut, put under ⌘X ahead of ⌘V, working the same as everywhere else for years, even for decades, as one of the first denizens of motor memories all around the world.

Ilya Birman on his blog talks about interfaces that unnecessarily slow people down, in a series of two posts.

In the first one, titled “Let me click,” Birman shows a few places that force the user to go through a roundabout series of clicks, instead of taking a direct route:

In Aegea’s comment settings, there is a “send by email” checkbox with an email-address field associated with it. If the checkbox is unchecked, there is no point filling in the field: the address is not needed for anything else. If the checkbox is checked while the address is blank, the system cannot send anything as it does not know the address. In short, these controls are interconnected.

Logically you could disable the input altogether if the checkbox is unchecked — there is no point filling it in anyway. But that is irritating. What if I want to enter the address and then turn on the checkbox? It would be even worse not to let me turn off the checkbox when the address is filled in. I want to turn it off — let me click!

In a follow-up, Birman talks about a specific example from the podcast app Overcast, whose creators faced with a tricky systemic challenge:

For any podcast, you can set how many episodes to keep downloaded on the device. Say you set the limit to three, then stop listening to a podcast regularly: the next three episodes download, and after that it stops downloading them — why waste the space? […]

[But,] what if someone manually asks to download an episode when they already have three downloaded? You can’t just immediately delete it to keep things tidy. […]

Finally, Marco’s wife Tiff suggests a solution to all the problems: just don’t let users download more episodes, she said, and show them a message, roughly: “Your episode limit is three, but this would be the fourth, denied”.

Marco liked the solution. I didn’t. Sure, it solves Marco’s problems, but not the user’s.

I haven’t seen the Overcast block in action, but all of Birman’s examples across both blog posts rang true to me. Motor memory wants what it wants, and stops for no one.

I wanted to add two things from my end.

1.

Birman presents this as “Let me click,” but I wanted to offer two alternative/​complementary principles that helped me before:

• Let me do things in any order. Here’s Google Home app, where I can change the temperature and the time for holding – but if I change the time first, it frustratingly resets when I subsequently change the temperature. It forces one specific order in an interface that suggests any order is okay:

• The current action has the most momentum. The user is right there, active, tapping on things, wanting to get stuff done. If Overcast indeed throws a “your episode limit is three” message, then it forces the user to remember how to get to the settings and change it. The momentum is lost. The decisions of past me should not be as important as the decisions of present me.

2.

I agree with all the examples given by Birman, but things can be stranger, and sometimes letting people click or do things in any order can make the interface harder to understand.

In Figma, each text box dimensions could be set to be completely automatic (automatic width and height – used for short labels), with only specific width (and automatic height – used for paragraphs of text), or with manual width and height (used for graphic elements):

You can also see that in text boxes where width or height are automatic, the fields for those values are grayed out, and cannot be changed. In order to change them, you have to switch to a particular mode first, which makes the relevant fields active. This is to help people understand how those things relate to one another in a pretty tricky space, but it effectively means sometimes Figma won’t let you click, and will force you to do this in one specific order.

But this is only in those fields – you can always grab the object on the canvas and resize it, and it will switch to manual on its own, respecting the drag’s momentum:

The inconsistency here is intentional. I’m not saying these are the right choices, and we indeed heard from some users frustrated that they cannot click easily when they already understand the system (unfortunately, I am aware of no good affordance for “breaking” a disabled field in modern GUIs, like a molly guard). I mostly wanted to share that these things can be hard, and the balance between “let me click” and “not being able to click can be helpful in understanding the system” tricky to achieve.

I keep thinking of the story from a decade ago when someone’s phone rang at the front row of a New York Philharmonic’s concert, prompting an actual performance halt, and anger from both the conductor and the audience. The ashamed patron’s eventual explanation was: “I turned the phone to silent, but I also had an alarm set up.”

Let’s assume this is actually true (in people’s reports, the phone rang the marimba ringtone, which isn’t standard for alarm – but people’s recollections are routinely flaky, too). This, I think, is a perfect example of “let me click” in action. You can set an alarm for a certain time, and you can subsequently turn the phone to silent. You can also do it in the opposite order. You just gave your phone two inconsistent instructions, and the phone logic decided in either case the alarm will win.

I can’t think of an easy interface solution here. It feels correct for the order to not matter here. It’s hard to imagine disallowing you switching to silent mode with any alarms on, since the silent mode also affects calls. It’s also hard for me to imagine any effective UI warnings at any given moment in the process. (Besides, back in the day, iPhone used to give you a gentle one via a little alarm icon visible in the top bar.)

The silent mode and the alarms are, as Birman put it, interconnected – but their connection is ultimately tricky to explain to the user.

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.

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

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

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

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

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

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

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

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

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.

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

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

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

The 2007 exchange went as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Those do respond to dragging as you’d expect:

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

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

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

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

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

I know the feature is actually called “tab groups” but I called it “site groups” intentionally, because otherwise it’s a tabbed control controlling tab groups, and things get confusing really quickly. Also, thank you to Martin Hoffman for initiating this post.

To me, “tap anywhere at the top to scroll to the beginning” is an amazing and underappreciated mobile gesture:

It not only provides an alternative to desktop‘s Home and ⌘↑ keys, but the student laps the teacher here; it’s actually better than every way to scroll to the top on desktop (do you like pressing ⌘↑? do you even have a Home key?), and it’s an icing on a cake of a regular flick to throw the page to the top already being pretty nice.

Tap to return to top is also distinctively mobile in that it allows you to tap just anywhere near the top edge that’s not already a tap target; as far as I can observe, traditional GUIs detest being imprecise in this way, always asking you to click on something specific (although window moving on macOS in the post-title-bar era is also starting to feel similar).

The iPhone gesture seemed to work so well that, over the years, more patterns started borrowing from it. In Bluesky and tons of other apps, you can tap on any tab with scrollable content a second time to scroll all the way to the top. (Again, something that’s hard to imagine on desktop, where you pretty much almost never think of clicking on an already-selected item.)

It’s not just the top, either. In Podcasts, tapping Home goes back to the left:

And in Photos, to the bottom:

To me, the whole “tap to return to the beginning” gesture universe feels ascended to be the core property of the interface. In that way, it is similar to scrolling, undo, copy/​paste, arrow keys moving the text cursor, and so on, all inducted to the National Register Of Historic Gestures.

Why? Because these gestures can only blossom if they work consistently, everywhere. You need to start trusting them so much they slide into your subconsciousness. Breaking the gesture in one place will make it less trustworthy in other places, too, ejecting it from motor memory back to the level of deliberate effort, and therefore making it a lot less usable. “Does this thing work here or not?” is a death knell of flow.

The fact that tapping on tabs is idempotent means there’s also no penalty; if you’re already at the beginning but are not sure, tapping it mindlessly won’t hurt or send you back somewhere else.

This is all great. And this is why I’m unhappy Safari started mucking with it.

Safari has tabs at the bottom – starting with two (regular set and “private” set), although you can add more. Above is a long list of site cards, with newest at the bottom. It’s exactly the same situation as in Photos, and yet tapping on either tab doesn’t restore the scroll position. Instead, it opens the settings dialog:

And, tapping around the buttons does nothing.

I would imagine Safari is a pretty important app used by many people, and so this feels like a bad place to introduce an inconsistency that could have a more serious consequences of un-teaching people about tap to scroll to top in the long run.

The funny thing is that the solution is already there: you can tap ··· in the upper left corner to get to the same functionality. The long press on the tab also opens the same menu.

Messing with a “tap to go back to the beginning” system gesture like this means to me the design team doesn’t fully share the understanding of the value of their own creation, or maybe that stewards of the gesture system are not vigilant… or perhaps the awareness is there, but the caretakers aren’t recognized, rewarded, or empowered enough.

It’s similar to the “no, thanks” example I shared before, a possible worrisome tragedy of the UX commons in the making if the respective teams do not change course. Because, wedging that sort of an exception in – even if you have a great set of reasons in the moment – creates a precedent. Inevitably, from my experience, the next team that will want to override scroll to top, or misuse “No, thanks,” will now require less of a justification.

A funny 12-minute video by Chris Spargo about why traffic signs in the world are standardized only to some extent. This was interesting to me generally in the context of Europe being more iconographic, and America being more “word-y” in their sign design, which extends to devices, keyboards, and (presumably?) software.

The story why [the old STOP sign] got replaced by the American version is also the story why the rest of our signs still look different, and why they probably always will.