Safari’s new tabs: Good or bad?
As you’ve no doubt heard, Apple released a beta version of Safari 4 earlier this week. Among the new features in this pre-release is a major overhaul of the program’s interface. While Windows users seem to be quite pleased with many of these interface changes, as the Windows version now looks much more like a native Windows application, Mac users are voicing mixed reactions. Perhaps the most controversial change in Safari 4 for the Mac is a new approach to tabbed browsing that places tabs at the top of the window—replacing the traditional title bar—rather than in a dedicated tab bar.
I’ve been using Safari 4 since early Tuesday, and while that’s admittedly a short time, it’s long enough to get a feel for how these tab changes affect both browsing and window management. Here’s a quick look at the good, the bad, and the in between.
While Safari 4’s tab interface is generating some criticism, it does provide benefits compared to Safari 3:
The address bar, toolbar buttons, search field, and bookmarks bar now appear within each tab, rather than at the top of the Safari window. This makes logical sense, since the functions these items perform are specific to the currently-visible tab, rather than to all tabs.
By essentially combining the tab bar and the title bar, Safari 4 gives you a bit more vertical space for Web-page content. It’s a small bit—two or three lines of text on a typical Web page—but it’s there.
The new “handle” that appears in the upper-right corner of each tab makes it more obvious that you can drag tabs to rearrange them. (On the other hand, these handles look like Mac OS X resize handles, rather than items used to move objects. And hiding the handle, as well as each tab’s close button, for non-active tabs lessens the effectiveness of the change).
Assuming you have the bookmarks bar hidden, moving the tab bar to the top of the window—along with other changes, such as moving the reload button into the address field—makes the “browsing” area of Safari’s window look more like Mobile Safari, increasing interface consistency between the two.
Given that the title bar has been replaced by the tab bar, Apple got Safari's behavior mostly right when it comes to moving a window when you can see only the top of it. Despite what you might expect, you can click (almost) anywhere on the tab bar and drag the window around without selecting the tab on which you clicked. This is the right approach, as it means that when a Safari window isn't frontmost, the tab bar acts like a traditional title bar.
Unfortunately, I had to write "mostly" and "almost" in the previous paragraph. It turns out the behavior of a background Safari window differs depending on where on a tab you click-drag. If you click-drag on the center of any tab, the window moves as expected. But if you click-drag a tab's move handle—which is invisible until your cursor is directly over it, so it's easy to accidentally hit—you switch windows, the clicked-on tab is selected, and that tab moves instead of the entire window. Alternately, if you click-drag on the tab's close circle—also invisible until just before you hit it—nothing happens at all. There's a logic here once you figure it out, but it's so obscure that I think the typical user will simply wonder why Safari doesn't seem to behave consistently.
The benefits of this new approach to tabs don’t come without costs. After a couple days using Safari 4, it’s clear there are drawbacks, as well:
The loss of a window-wide title bar is a departure from two decades of Mac OS interface standards. You no longer have a distinct title bar for grabbing and moving a window. Instead, to move a Safari 4 window, you grab a tab. This works, but it’s a little sad to see such inconsistency from a company that, with a few exceptions, has embraced interface consistency as a key to ease of use.
By replacing the traditional title bar with tabs and a New Tab button, Safari 4 is the new poster child for “click-through” problems—the phenomenon where clicking on a background window not only brings that window to the front but also passes your click through to the window, potentially performing another action. Specifically, if you click on the “title bar” of a Safari 4 window that’s currently behind other windows, that click also activates the particular tab or button on which you clicked, bringing a particular tab to the front or, more disruptively, creating a new tab. The result is that you must now be cognizant of where in the title bar of a Safari window you click. The corollary is that if you don't want to accidentally select another tab, the size of the target for your bring-forward click is inversely proportional to how many tabs you have open.
The only way to move a tab in Safari 4 is to grab the tiny handle in the tab’s top-right corner. The reason for this is obvious: because top-mounted tabs replace the traditional window title bar, grabbing any tab’s title replaces the “grab the title bar to move the window” action. So Apple had to come up with a new way of moving tabs. Unfortunately, the small size of this handle makes it more difficult—and more RSI-inducing—to perform this action.
If you’ve got a window without tabs in front of a window with tabs, the resulting appearance can be confusing, as you can see in the image to the right.
In Safari 3, you could control/right-click on the title of the current window to browse higher levels of the current Web page’s site; this feature is gone in Safari 4, since the tab and title bar are one and the same and tabs already have their own contextual menu.
As Daring Fireball's John Gruber pointed out, it’s no longer as easy to drag a URL to a Safari window to create a new tab for that URL. With Safari 3, you could just drag a URL to any open area of the tab bar. Now you must drag the URL to a tiny, tiny sliver along the left-hand edge of the New Tab button. And since there’s no distinct indicator that you’re dragging a URL onto that button, rather than onto the right-most tab, it’s far too easy to accidentally drag the URL onto that tab instead—which, of course, replaces the tab’s contents.
If you tend to click on tabs more often than you use the bookmarks bar, the new interface requires more mousing. (Since the tab bar isn’t at the very edge of the screen—you’ve still got the menu bar above it—there’s little Fittsian advantage to placing the tab bar at the top of the window.)
Finally, there are areas where Safari 4’s melding of the title bar and the tab bar just doesn’t look right. For example, as shown to the right, there’s no separator between the left-most tab and the area of the title bar containing the close, minimize and zoom buttons. This makes it appear as if those buttons affect only the left-most tab, when they’re actually window-wide controls.
Work in progress
Keep in mind that we're talking about a beta version of Safari 4, and the first publicly available beta at that. So it’s possible many of these behaviors could change as Apple tweaks the program for its official release. In fact, there’s evidence Apple used feedback on beta versions of Safari 3, first released back in 2007, to refine the final product, released several months later. (You can submit suggestions and bug reports for Safari 4 by clicking on the Bug button in the toolbar.) So no one should make final judgements about Safari 4 based on a couple days’ use of the beta. But at the same time, I think there are valid interface complaints that go beyond “it’s different.”
Of course, an interesting question is, “Why did Apple make these changes to tabs?” Jason Snell thinks the Safari team was spurred by Google’s Chrome. Frequent Macworld contributor Andy Ihnatko speculates that it’s a step towards making Safari more suitable for a possible tablet Mac. I think both theories have some merit, although I also think the Safari team was trying to make tabs and their features more obvious to people who may not use them frequently. I’m hoping that between now and the final release of version 4, Apple can accomplish that goal while addressing some of the beta’s shortcomings.