Sunday, May 3, 2009

The Safari 4 Tabs

I tried to give the Safari 4 beta's tab implementation - tabs in the window titlebar - a fair evaluation. I really did. But in the end, I used the hidden preference setting to switch back to the old tab style, and I was much happier. In the end, I had problems with them both from a conceptual standpoint and from a practical one.

Conceptual Problems

Tabs-in-titlebar supporters make the valid point that tabs are, conceptually, docked independent windows. Therefore, all the content that's normally subordinate to a window should be subordinate to the tab instead, and the tab should be placed above the content - in Safari's case, above the address bar. In this situation, putting the tabs into the titlebar saves screen space. Also, the argument goes, since tabs are supposed to be dockable windows, it makes sense to put them into the title bar - the one area of the window that unequivocally belongs to the window.

Unfortunately, doing so interferes with the primary function of the titlebar. Titlebars are the conceptual foundation of a windowing system - the one fixed, stable, manipulatable part of every window on the screen. Windows in OS X do not have a border, may or may not have scroll bars or a grow box, but they always have a titlebar. Titlebars help the eye to pick out a window from all the rest of the clutter on the screen, they give the user a way to position the window, and they provide a host for the close/minimize/zoom widgets.

If you put tabs in the titlebar, that changes. The fixed, stable foundation is no longer fixed. Windows with tabs now behave differently - not just from every other kind of window on the system, but from each other. "Safe" click areas change from window to window as the number of tabs changes. Dragging a window becomes a more finicky operation, as you now have to hit the precise area of the frontmost tab - without accidentally hitting the close or drag widgets for the tab - to move the window without switching tabs. Additional clutter in the titlebar makes it harder to pick out from the background clutter on your desktop. This is just a bad idea.

Practical Problems

Aside from the conceptual issues, there are some practical usability points. As implemented in Safari 4 beta, the start of the tab area on the titlebar is practically butting up against the close/minimize/zoom widgets; it's very easy to overshoot and click one when you meant to click the other. Putting the tabs up in the titlebar puts them significantly further from the content area; it may just be psychological, but I feel like I have to work harder to reach them. Also, even if the titlebar is the same height as the tab area in older Safari versions, it feels like a smaller target because there's no margin above them. The additional visual clutter not only makes it harder to pick out the window from the rest of the desktop, it makes individual tabs harder to pick out from each other. Finally, there's no longer a way to see a full page title at a glance - in old Safari, the titlebar always showed the full page title of the frontmost tab, even if it was too long to fit in the tab, but putting tabs in the titlebar removes this display area.

A Noble Failure

I give Apple credit for trying something new, and for the possibility of a uniform way to handle tabs across applications in OS X. But the execution just doesn't work. They need to take the Safari 4 tabs back to the development labs and try again.

No comments:

Post a Comment