Why can’t Safari get tabs right?
June 9, 2009
I thought Safari 4 beta was headed in the right direction with it’s tab location. The Safari design team had moved the tabs to the the top of the window and thus made them up-right like this:
Now I realize there was a bit of a usability problem, as the tabs were now doubling as the mechanism to move the window, but I liked the direction the UI was moving in. I greatly disliked the upside down tabs of Safari 3, because they make no visual sense — the tabs are completely disconnected from the content they are tabbing.
As you can imagine, I was dismayed when I installed the final version of Safari 4 only to see the tabs revert to their version 3 visuals:
I’m not sure why the Safari visual design team chose this broken tab metaphor to begin with as it’s never made any sense, and it’s clear that they realize this. So why keep around this broken metaphor and make us suffer for another full version?
This is not a hard visual design problem to solve. Google Chrome has a great solution that meets the visual demands of the Mac platform:
Come on Apple — lets get this fixed.
Exploding Pixels 
June 10, 2009 at 12:48 am
One thing I occasionally trip on is how Safari shares the address bar between tabs. Type “FOO” in a Safari address bar, switch to another tab, and then switch back. Your “FOO” is lost forever. Similarly, Safari doesn’t remember search terms per-tab.
June 10, 2009 at 12:44 pm
I totally agree — it’s not at all clear visually how the address bar and search box relate to the content area. Google Chrome doesn’t have this problem.
June 10, 2009 at 4:35 am
Tab bar location doesn’t bother me at all. I think every people has their own opinion with this stuff. Believe it or not, by moving tab bar to the top window will make their users to create new learning curve, and it could give bad impact, because good user interface should give less learning curve for their user.
June 10, 2009 at 12:47 pm
But don’t you think that Google Chrome’s learning curve is less steep because the tab metaphor is the one we’re accustomed to in other applications (i.e. tabs on top of and connected to the content area)? Safari broke the tab metaphor without an obvious benefit for doing so.
June 10, 2009 at 8:57 am
For me, Chrome gets it absolutely right. I really love the unified URL bar (both addresses and search) as well as the tabs at the top. It makes sense that the URL bar is inside the tab and not outside as long as it keeps the current address right ;).
For me the Chrome way is defenitely the way to go.
June 10, 2009 at 12:50 pm
I love the “omnibox” too! I may be switching to Chrome on the Mac once it’s a little more stable.
June 10, 2009 at 1:12 pm
Chrome tabs are intrusive.
Title bar tabs break the model and mix functionality.
Leave the tabs alone – they work.
There are bigger fish to fry…
:-)
June 10, 2009 at 1:45 pm
I don’t find the Chrome tabs too intrusive, though your right that they enter the title bar area. This is better than Safari 4 betas solution, though, of completely overtaking the title bar.
Sure the tabs work, but they could be better. It’s the subtle details that count.
June 11, 2009 at 1:23 pm
Hmmm. Mostly agree with your subtle details comment. However, moving the tabs to a new location and orientation is not subtle.
June 10, 2009 at 2:46 pm
Interesting.. Haven’t tried the Safari 4 beta myself (using Firefox 3), but I must say it *looks* great. As far as I can understand, mixing tabs/window title bar will only be a problem when moving the window vs re-arranging tabs… But I kind of think this approach makes sense for a tabs-as-MDI implementation. Chrome also makes sense, but looks less nice (less Apple maybe ;-) IMO.
I’m working on implementing a “tabs-as-MDI” or “browser tabs” component for Swing, and have currently implemented a hybrid between Safari 3 and Terminal. Implementing the look of Safari 4 should be doable, just more fancy effects.
But maybe I should implement something more like Chrome instead? The Safari 4 beta seems close to impossible in Swing, unless making the window undecorated and do everything by hand…
June 11, 2009 at 7:46 am
I totally agree. Very hard to mimic the Safari 4 interface in Swing because of the window title bar. This one is anyway tough: reproduce the “continuous” title bar in Swing as it is more and more used in Leopard is a real challenge. Especially if your app should be multiplatform.
June 11, 2009 at 12:01 pm
It would be possible to visually reproduce the look of Safari 4 beta. There is one show stopper, however, for Java apps on the Mac: when you implement your own resizing mechanism (i.e. you call myFrame.setSize(…) in response to some event) there is a terrible flicker. This is why my HUD component in Mac Widgets for Java is currently not resizable. Hopefully this will get fixed soon.
-Ken
June 10, 2009 at 3:00 pm
PS: Another important aspect of tabs-as-MDI, is overflow handling. I think the Safari 4 implementation makes sense (no scrolling, but keeping the selected tab visible on screen). Better than Safari 3 and Terminal at least (no scrolling + menu for overflow, making only the first tabs re-arrangeable).
Firefox uses scrolling + a menu, showing all tabs.
I’ve seen apps that re-arrange tabs to keep the selected tab on screen was well. The bad thing re-arranging is that the tab might not be where the user left it, when he wants to go back..
If someone has the perfect solution to this, please let me know. ;-)
.k
June 10, 2009 at 5:07 pm
The tab overflow problem is a messy one. I hadn’t really thought about all the great points you make about selecting an “offscreen” tab via a menu. I’m not sure what the right solution is.
June 10, 2009 at 7:52 pm
I couldn’t agree more. The Chrome unified title bar approach is much preferred.
June 12, 2009 at 12:51 am
Google chrome is a nice project, that is why I contribute to it since day one (and now a committer) MAC is still in alpha! Only the community can make it the best browser out there! http://blog.chromium.org/2009/06/plausible-promise.html
If all of us help it out :) The mac version will beat any browser out there !
June 12, 2009 at 2:58 pm
Safari’s UI would actually look like Chrome if they had the same approach on the tabs…
June 18, 2009 at 4:52 pm
Keywurl turns the Safari address bar into a omnibar, it’s what I used for Safari 4 Beta and before that.