Defending Safari 4 tabs

The first reaction most people had to Safari 4 — especially the new tabs interface — was negative. I’m here to defend it.

But first, let’s get the mistakes out of the way, because they are substantial. Safari 4 tabs have several new usability problems:

Clicks to close or drag in inactive tabs should not be allowed. As Daniel Jalkut pointed out on Twitter, these “landmines” decrease the available space to click when dragging a window. And the problem only gets worse as you add more tabs. It requires too much thinking before being able to drag a window. (You can bet Apple has research that shows most people only have 1 or 2 tabs open at a time, but nevertheless you are going to sometimes have a bunch.)

Click-through should not be enabled. Same point as above, but don’t allow closing tabs or clicking the drag handle when Safari is not the frontmost app. John Gruber has written extensively on this issue, and this post from 2003 is a good place to start.

Title bar font is different than every other app. I understand this decision, but it’s unnecessary for small numbers of tabs. If you have 1 or 2 or even 3 tabs open, there’s no reason not to use the full font size so that Safari’s title bar is consistent with other apps. It’s distracting.

Too subtle. Because nothing in the content area of the window changes, it’s easy to miss the tabs. They are in a more prominent place but somehow fade into the background. I’m not sure whether this is a good or bad thing yet, but I’m leaning toward bad.

There are other largely aesthetic complaints about the new tabs, such as how the default wider tabs look odd compared to previous versions of Safari, but a lot of that is just unfamiliarity and doesn’t point to a specific usability problem.

So why do I like what Apple is doing here? Because I’m hopeful that this is the first experiment to bringing system-provided tabs to applications.

Here’s what I wrote about this issue in 2005:

"Instead, Apple should have built upon Exposé to offer system-wide window grouping state, so that in any document-based application the user is in control of how windows are tabbed. Actions like dragging to rearrange tabs could be implemented once and work consistently across all applications."

In the last 4 years the problem has only gotten worse. Developers are rolling their own tab solutions and there is no consistent behavior or keyboard shortcuts that I have seen. Worse, coding fully-featured tabs with the ability to drag windows in and out of a tab group is very difficult, and most apps don’t go that far.

The Safari 4 tabs are conceptually the right way to go. It’s not “tabs” at all. Instead, think of it as an efficient way to dock multiple windows together.

Getting the tabs out of the content area of the window is also the first real step to making this available to other developers. While I don’t think you should stamp this on to all applications, certain classes of document-based applications could “opt-in” to this new system and get it mostly for free, with consistent UI and behavior provided by the system. Developers who had special requirements or wanted a custom tab look-and-feel could continue to build their own tabs without worry that their UI would be interfered with.

I have no idea if this is the direction Apple is going in, but the Safari 4 design makes me think that at least someone at Apple has this in the back of their head.

Manton Reece @manton