Like Tabs In the Rain: How Safari 4s Tabs-On-Top Could Have Worked

It seems the general reaction to Apple pulling out their Safari 4 Beta “tabs on top” feature has been generally positive. The sentiment seems to indicate the feature to be so inferior to the workaday solution of having tabs below the address-bar, that tabs-on-top shouldn’t even be optional for those of use who understand their usability benefits.

I’m writing this post today, to inform you that the problem wasn’t tabs-on-top. The problem was Apples half-assed implementation of tabs-on-top.

In a misguided attempt at being innovative, Apple had decided to build their own take on the tabs (as can be seen in this screenshot). Tab-widths resized for every new tab you opened, trying to use the maximum available realestate (causing quite the flutter when opening tabs). The left-most tab had the close button on it, while the second-most did not (confusing the close tab with close window behavior). Probably most ridiculously, tabs had a little strip on the right side that looked like it would resize the tab window. This was, in fact, the “move only the tab” drag area. Dragging the tab, ironically, dragged the whole window.

For the analytical mind, you might — with the help of drugs — pick up on the idea that each Safari 4 tab was its own window, and that when you combined one window with another, they’d share the titlebar, dividing this new world equally between them. So a tabbed Safari 4 window could simply be thought of, as a group of Safari 4 windows. A noble goal, and no doubt why Apple tried all those oddball UI decisions. Forgivable, because this was a beta version. How much more odd it was, that the feature was pulled altogether when the final version of Safari 4 was released just a few days ago. To re-iterate, tabs-on-top is not even optional.

This really is a pity, and to explain why, please take a look at the current default Safari 4 configuration:

Safari_4

Behold, Apples flagship browser, in all its tab-less glory. Wait, no tabs? That’s right, until you open a tab, you won’t see the tab-bar (unless you change the default settings). How would your mom discover tabs in Safari 4? That’s right, she wouldn’t.

Tabs on top have the benefit of being supremely visible. They are, after all, right at the top. Windows users have the added benefit of having them be right at the top of a maximized window, requiring you to only bump your mouse towards the edge of the screen to select it. Easy peasy. Now all that will be lost. Like tabs in the rain.

It’s not that Safaris current tabs are bad, once the tab-bar is there:

Safari_4_tabs_open

… it’s just that the discoverability is somewhat lower than tabs-on-top.

As an added benefit of tabs on top, you’d get some extra vertical real estate, because the titlebar would be nuked in favor of the title only having to stick to each tab. With tabs below, you have the title shown twice. Which is redundant of course.

So Safari 4 ditched the tabs on top. So what, go back to Google Chrome where you came from? Sure, but not before I poke fun at the visionaries at Apple for chickening out on a good idea. Tabs on top could’ve worked:

Safari_4_how_tabs_could_have_worked

Okay so it could also have worked even better than the above mockup, but still, it’s not really rocket science. Invert the tab-bar  instead of inventing some high-fantasy “group of windows” metaphor. Each tab has a fixed width (until you have to deal with overflow), and dragging the tab drags the tab (for sorting purposes). Pulling the visible chrome before or after tabs, or even below the tab around the addressbar here and there would drag the entire window. The tab close button (now visible all the time) looks like a close button and not like the Apple stoplight (because it closes the tab, not the window).

There. Tabs like they’ve been done since BeOS.

15 thoughts on “Like Tabs In the Rain: How Safari 4s Tabs-On-Top Could Have Worked”

  1. Here’s hoping for Safari 4.5 (or 5)!

  2. John says:

    It was the tabs on top. THey suck.

    A bad idea is simply a bad idea.

    1. Joen says:

      Oooh, rush me to the burn unit!

      If it was simply a bad idea, how come Apple tried it in the first place?

    2. Dave Child says:

      Tabs on top make more sense than tabs under the address bar. The address is a property of the tab. The “back” history is a property of the tab. They should be enclosed within the tab.

      Opera’s done it well.

    3. Joen says:

      Dave Child: Opera’s done it well.

      I completely agree.

      On a related note, the “resize the tab bar to get thumbnail tabs” feature in Opera 10 is truly innovative and works rather well!

  3. Chris says:

    If it was simply a bad idea, how come Apple tried it in the first place?

    ‘Cause. Can’t be sure it’s a bad idea till you give it a shot. Microsoft’s problem is that they keep their bad ideas around. Apple’s strength is in dropping them.

    1. Joen says:

      Chris: Apple’s strength is in dropping them.

      Sure, but I can’t say I think Apple really tried the idea at all. They made the worst terrible tabs-on-top implementation in a beta, and 3 months later dropped it, without even trying to get it right.

      As Dave Child says, Opera can do it. I say Chrome can do it. If this is not proof that that tabs-on-top can work, I don’t know what is.

  4. Levi says:

    Nice concept Joen, I’m quite fond of the way Chrome does it with the increased titlebar height so you can grab the window above the tabs but I’m having a hard time thinking how that’d work with the OSX grey/silver.

    1. Joen says:

      Here’s what Google Chrome for the Mac looks like in its current pre-alpha state:

      http://www.flickr.com/photos/ebarrera/3597565410/sizes/o/

      Not so bad, actually!

  5. Gareth says:

    tabs at the top make so much more sense! apple should have stuck this one out.

    1. fabrice says:

      Okay, let’s get a clean, consistent interface. By definition that means not having to learn a new layout for every app. Oh, yeah… that ship sailed a long time ago.

      But as for the oft-repeated complaints about losing “valuable desktop space”, get real. In a browser window, that’s like re-arranging chairs on the deck of the Titanic, when what’s sinking it are the winking, blinking, fake-pointer, bare-midriff splash adverts floating-popping-weaving-bobbing over content.

      Gotta make room for yet another ad?

    2. Joen says:

      fabrice: Gotta make room for yet another ad?

      I feel like coining a new phrase:

      Reductio ad advertum – As a Internet discussion grows longer, the probability of a comparison involving advertisements or advertisers approaches 1.

      But seriusly.

      For me, gaining some 20 extra pixels is a completely secondary benefit, but a benefit nonetheless. Begin able to save space in a modern interface, to me, shows a remarkable wealth of design, and indicates to me that the idea has potential. Less is more, no?

      Again, forget the 20 pixels. The main reason tabs-on-top in Safari is interesting, is that it brings tabbed browsing to the masses. As opposed to the standards tab-bar-free Safari 4 first-run-window today, tabs-on-top Safari makes the tabbing feature excellently visible. The little “add new tab” plus button indicates how to get more tabs, and it’s all there permanently visible at the top.

      To me, that’s a clean interface.

      It is also, to me, more consistent, since Safari 4s tabs so far are inverted compared to tabs seen almost everywhere else. Here are a few other OSX tabs. They point upwards to the sky: http://desktop.plkr.org/tour/images/channel_dialog_osx.png

      It’s consistent even to the physical metaphor from whence tabs came. Physical folders with little paper tabs sticking up, allowing you to browse through the folder contents.

  6. Joen says:

    Found a few tab design guideslines at Jakobs site, which I find supports the idea of tabs on top:

    Tabs, Used Right:

    The current tab is connected to the content area, just as it would be if we were shuffling several physical index cards that had tabs stuck to them. This emphasizes which panel is being shown, and also helps tell users which tab is selected when there are only 2 tabs. Having the same color for the selected tab and the panel area reinforces the connection between the two and is a reason to support the use of reverse highlighting.

    The row of tabs is on top of the panel – not on the sides or the bottom where users would often overlook them.

    The scope controlled by the tabs should be obvious from the visual design. Metaphorically, using tabs is like leafing through index cards in a drawer of an old-fashioned card catalog, so users must be able to tell at a glance what constitutes an “index card” (i.e., tab panel).

  7. fabrice says:

    Here are a few other tabs. They point upwards to the sky: http://desktop.plkr.org/tour/images/channel_dialog_osx.pngIt’s consistent even to the physical metaphor from whence tabs came. Physical folders with little paper tabs sticking up, allowing you to browse through the folder contents.

    But notice how those tabs are neatly organized immediately above the controlled content? That’s much more like Safari 3 (and now 4). I had trouble adjusting to the separation between content and the tab in Safari 4. Took me a while to even find them. But you may be right, it may have more to do with the overall design quality.

    Still, … maybe it’s my age that makes me a lot less tolerant of getting acclimated to yet another interface for yet another platform for yet another rev of yet another app just because (pick one):

    a) theoretically, it’s better

    the designer liked it better

    b) had to avoid someone’s intellectual property

    c) Invented Here

    d)

  8. Is there any way I can find how to open a link in a tab, rather than a new window, on Windows XP?

    Thanks for any help. Robert Watson

Comments are closed.