At the end of the previous post in this unexpected series about iOS Safari’s tab control design, I wrote:

This is how interaction systems slowly fall apart. […] 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 didn’t quite get this right, as it seems this has already happened. It might have been Safari that used a “blessed” interaction from elsewhere. Conversations with a few readers helped me piece together a larger story of how we got here. I fired off some of my old iPhones and emulators to verify them, and so let’s go back in time all the way to 2007.

Step 1: These rotary controls for timers have been here since the first iPhone. Note how you drag the background, not the selection, but that works because the background is styled as a physical object, you see the options extending in both directions, and the selection remains fixed in place.

Step 2: In iOS 7 in 2013, the camera app adopts a similar treatment, but on a horizontal plane. This is roughly as above, flattened, but with the background still extending in both directions, showing adjacent options. This also made some skeuomorphic sense because this control is very “mechanical” – you could imagine such a wheel on a real-life camera.

Step 3: In 2023, Safari follows in those footsteps for its tab groups (which originally was a more traditional menu). It might have felt like the right thing to reuse, but the control doesn’t feel as refined as the Camera’s. It also introduces the problems where tapping no longer scrolls to the initial position (mentioned in part 1) and the too-eager tab group creation overflow (mentioned in part 2).

Step 4: This is where the trouble begins. Camera gets redesigned for iOS 26 and liquid glass. The team decides to rearrange and simplify the control visually, but at a price of making the interactions feel more complex: there are now only two items visible by default (the background doesn’t extend to hint at other options in its resting state), the current selection no longer stays in place, and the control generally suggests tab-like interactions but doesn’t provide them.

Step 5: At some point in the beta process, the Camera team perhaps realizes the same thing I found challenging in part 2 – these now look like pills, and elsewhere the system taught us finger drag moves pills rather than the background. In iOS 26 beta 4, the direction is reversed compared to all previous versions of the app.

Step 6: Seemingly almost immediately, people complain, since many years of motor memory are now compromised. So, in beta 5, Apple adds a setting called “classic mode switching” – similar to natural scrolling years before, on macOS side.

Step 7: However, not long after that, in beta 6, Apple removes the setting and reverts to the original direction from steps 3–4.

Things that come to my mind:

• Inverting the control to go the other way in step 5 was where the consequences of previous steps reared their ugly head. I imagine perhaps the strength of complaints surprised Apple, which found itself without a backup plan, between the rock and a hard place: earning either the immediate ire of power users (whose motor memory was disrespected) or the future ire of other users (who will experience no consistency between pilled controls going forward).
• Adding a setting would be kicking the can down the road, but so is – as I hoped to establish in part 2 – leaving things as they are: There’s still a systemic problem where controls in Camera and Safari are now at odds with other pilled controls.
• What makes a control a control is not paper principles, but a collection of details working together. Removing the extended background, restyling the control, and making the selection no longer stay in place might feel like small changes in isolation, but at some point Theseus would like a word. I see this sometimes in other surfaces, where individual UX changes compound over time, become basically dead reckoning, and result in a boiled frog.
• I wonder if Apple succumbed somewhat to the “dumb consistency” problem: often it’s better to be inconsistent in a smart way than consistent in a dumb way. It might feel good for all the tabs and the pills and the toggles to look the same visually, but that feels like dumb consistency if they behave differently. It might seem good for Safari to reuse Camera’s toggle, but the Camera is generally a one-of-a-kind, bespoke app, so it has some leeway here. Safari doesn’t really get to play by those rules.
• I am curious why the Camera team didn’t invert the direction and the ordering of things. In this case, two wrongs would make a right, and this would keep the motor memory intact. (I imagine the reason is that this would trip up people who remembered things cerebrally, rather than “in their fingers.”)
• I feel the team wasn’t given or didn’t give itself enough time, which jibes with how unpolished the entire liquid glass effort was in its first year. In a perfect world, the camera control would probably have been redesigned again before launch to avoid tricking the motor memory – or perhaps the whole original iOS 26 change reverted.

That’s Camera. Where’s Safari in all that? Just where it started: Safari’s control today again seems just like a cheaper, more hurried, less thoughtful version of what Camera does. The Camera toggle doesn’t have the jarring “swipe to the left to create a new space” flow, doesn’t need to support tap to top, shows you the background affordance more readily, uses haptics, feels less buggy, and even only allows you to swipe one notch at a time, so the control feels precise and never runs away from you.

In the just-released iOS 27, the Camera is even slightly improved – it again shows more of its surroundings even before any swipes.

I haven’t noticed any updates to the Safari control.

The story of this entire system now appears to be this:

• The Camera team made mistakes that could have been avoided; changes to deep motor memory do take years and have to be planned and approached with patience.
• The Safari tabs have been drafting behind the Camera tabs, but still introducing smaller mistakes of their own: continuing to prioritize strange interactions in lieu of intuitive ones, and forgoing some of the nuance.
• Both look like pills and, when dragged, go in the opposite direction as other pills in the system.

In all these screengrabs, I’m dragging my finger to the right:

I don’t, of course, know all the details, and I realize I am harsh in my assessment. I sympathize with the depth of the challenge not just for the team – motor memory can be brutal, and established interaction systems are really hard to evolve – but also in coordinating with other teams in a closed-off culture like Apple’s.

Then again, these are iPhone’s top-tier surfaces so I think it’s fair to expect excellence, and this is also not the first time Safari team has made some puzzling design choices. Perhaps most importantly, Apple is also the platform owner and they set the tone for other apps, which we’ve seen recently in their indirect influence over CleanShot’s settings.

I hope you found some interesting things in this long post. As a reminder why it all matters, and why protecting systems of interactions like tap to top (part 1), or slide on an object to move it in a predictable way (part 2) is important, this is a quote from one of the readers:

It’s actually worse [in Camera], because often you are in a bit of a hurry to take a picture and it behaving unexpectedly is the last thing you need. I had this once or twice: suddenly it was in video mode and by the time I had it back in regular photo mode, the train I was trying to photograph was long gone.

I’ll be curious if we see more evolution of these spaces, and hopeful Apple resolves the problems. But now, I’m ready to stop talking about Safari’s tabs for a while.

Thank you to Nikita Prokopov, Daniel Dickison, Jeremy Kanter, and Martin Hoffman.

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.

In 2021 and 2022, product manager Steven Sinofsky wrote a…

…first-person account of what I saw at the PC revolution from the perspective of joining Microsoft as a newly hired software design engineer fresh from graduate school working on developer tools, through my time as a program manager and ultimately leading Office, and then moving to Windows, and everything in between.

Sinofsky called the series Hardcore Software: Inside the Rise and Fall of the PC Revolution. It covers 1989–2012 and somewhere inside over 100 chapters, there is a fascinating six parter about the “ribbon” redesign of Office 2007.

• What is Software Bloat, Really?
• A Tour of “Ye Olde Museum Of Office Past”
• Competing Designs, Better Design
• Progress From Vision to Beta
• First Feedback and a Surprise
• Defying Conventional Wisdom to Finish Office

The first part covers the challenge of the team in 2007, taking stock of Office after almost 25 years of its evolution. (Number of toolbars in 1983: one. Number of toolbars in 2003: 31.) The second part shows great screenshots of all the Office versions from 1.0 until then, and the remaining four cover the Ribbon redesign process.

Regardless of how you feel about Microsoft Office today, and whether you consider the Ribbon interface a success, it’s a perfect weekend read as it covers universal challenges of software complexity and change management.

It’s such a potent series I’m sure we’ll come back to it. It covers a lot, including – in the first part – wrestling with a definition of bloat or complexity, which in the context of Office was less about the number of functions available, and more about mastery:

[…] In practice, bloat comes from the fact […] that Office does so many things that customers just assume the product can do whatever they need it to do. Despite that fact, customers have no idea how to make the product do what they need. This feeling of helplessness that leads to frustration. […]

Bloat is owning a product that you cannot master.

This below is a great observation about the perils of an idea of a “simple mode,” which Sinofsky argues is always a leaky abstraction:

We tried reducing bloat by hiding features […], but that only added to the mystery of the product. Mac, Windows, and Office all went through periods of “simple means fewer” and tried mechanisms such as short menus, simple mode, or adaptive toolbars. But that frustrated or confused people. No one really wanted to use a simple mode and there was always one command missing that was needed, so simple mode became a complicated way to do that one thing that made someone’s work unique.

It was great to see this argument for a broad definition of a bug, as it slides exactly into my post from a while back:

Ages ago in ancient Microsoft history there was a debate on the original apps team about what it means for something to be a bug. Is it a crash? Is it data loss? Is it a typo in an error message and so on? Out of that was created a notion of bug severity, a measure for how serious a bug might be from losing all data all the way to simple cosmetic issues. However, when it came to talking about bugs with product support or ultimately customers the definition of a bug was very simple “a bug is any time the software does not do what a customer expects”. This definition created a discipline of documenting everything reported about the product and always making sure every issue was looked at, even if a code change did not result. The key lesson was how helpful an expansive definition was.

There are also observations and research about how users “debug” the product to make it achieve something they know is possible, but they don’t know how:

We called the futzing document debugging, and it created a frustration that the product was powerful yet overwhelming. People believed a specific result was achievable but getting from point A to B seemed impossible or unlearnable.

And some about the challenges of figuring out what features people use:

[…] Most people didn’t know or care what buttons they clicked on or menus they chose so long as it was working for them—and that meant when asked, “Did you use X?” most people couldn’t recall. To a skeptical press or IT manager (and they all were) that meant unused features.

I should stop quoting and let you read in peace. But, check this out. Lisa wasn’t the only one having linguistic fun:

Early keyboard shortcuts were simple, like using Ins(ert) key to copy text from the scrap (clipboard).

Scrap!?

I added a table of contents UI to the most elaborate essays on my site, and then wrote about some of the design details and choices I made there. Let me know if this is an interesting case study! I tried to do something new here with tons of mini videos.

At the bottom, I will also be collecting other implementations I see that are interesting alternatives to my approach.