Tag Archives: tabs

Safari pinned tab favicons

In a post on Daring Fireball today, John Gruber makes a convincing argument for Safari showing favicons in tabs:

With many tabs open, there’s really nothing subjective about it: Chrome’s tabs are more usable because they show favicons.

Even more surprising to me is that Safari doesn’t use favicons for pinned tabs. Instead it uses a special monochrome vector icon. Ever since adding favicon support to Micro.blog, I’ve had on my to-do list to create one of these vector icons for Safari, but so far I haven’t been able to justify the effort. (And judging by a handful of my favorite sites, no one else has bothered to create a pinned tab vector icon either.)

Why does Apple require a separate icon format here? Probably for the same reason as John Gruber’s guess about normal tabs:

I don’t know what the argument is against showing favicons in Safari’s tabs, but I can only presume that it’s because some contingent within Apple thinks it would spoil the monochromatic aesthetic of Safari’s toolbar area.

It seems clear that these pinned tab vector icons are a dead-end. There are already too many sizes of favicons. Safari should have basic favicon support in tabs and do it with as few extra icon files as possible.

Tab click-through areas

It’s often true that the further away you get from an event, like the release day for the Safari 4 beta, the closer you get to a fair analysis. Initial Twitter reaction was gut level and some not even based on anything but screen shots. “My own post”:http://www.manton.org/2009/02/defending.html was admittedly slightly half baked, but I think it stands up fine.

Now we are seeing some more thoughtful analysis, including from “Dan Frakes of Macworld”:http://www.macworld.com/article/139026/2009/02/safari4tabs.html, and “Lukas Mathis”:http://ignorethecode.net/blog/2009/02/26/on-tabs-and-docking-and-title-bars/, and of course the thorough “John Gruber of Daring Fireball”:http://daringfireball.net/2009/03/safari_4_public_beta.

I wanted to revisit one thing with click-through. If you eliminate the mouse rollovers and click-through for inactive tabs, you end up with surprisingly few places to accidentally click. Here are two screenshots illustrating the difference between Safari 4 and BBEdit.

Safari 4 tab example

It’s true that the file icon needs a hold-and-drag, so it’s harder to click, and the hide toolbar button is off to the side and less dangerous than closing a tab. Nevertheless, viewed by pixels alone there isn’t a significant difference between the safely clickable area of these two window title bars if Apple makes this small change.

Update: If I left too much to the imagination, here are examples of the real Safari 4 clickable areas, not the way I wish it would be above.

title_bars2_small.png

And the extreme example with even more tabs:

Safari 4 tab extreme

The important point is that if you disable click-through for inactive tabs, the safe area does not change even with dozens of tabs, and in my opinion it is only marginally worse than other standard Mac applications, as shown in the first two screenshots. The current Safari 4 behavior, on the other hand, continues to degrade until the window title bar is nearly useless.

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.