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.