Source: David Hyatt's Safari Blog:
I've seen a lot of comments in various Mac forums where people have claimed that "Dave Hyatt said he doesn't like tabbed browsing!" or "Dave Hyatt hates tabbed browsing!" I find these posts perplexing, because I never said any such thing, and of course the opposite is true. I love tabbed browsing. I implemented tabbrowser in the Mozilla trunk. I implemented tabbed browsing in Chimera. I implemented the version used in Phoenix. Given how many times I've implemented it, I'm amazed that people would think that I am not a tabbed browsing devotee.
That said, I wanted to express some of my thoughts about the various UI decisions one has to make when designing a tabbed browsing system.
I think the most important question you have to answer before designing a multi-page system is "Who is my target audience?" In the case of Phoenix the target audience is experts and power users. I do not believe that tabs serve any useful purpose for novice users, because novice users don't ever use multiple views of Web data. They just browse from page to page.
The classic novice user Web setup is to have Windows IE maximized with the sidebar open. That kind of user simply doesn't need tabs. Tabs are total overkill for what that person wants to do with his/her Web browser.
That is why I think ideas like this, although extremely pretty, seem to be targeting an audience that IMO doesn't exist. A power user doesn't want thumbnails, since they wouldn't be easily distinguishable anyway once you opened several tabs, the overflow mechanism for such a system would be clumsy (or would use too much space, scrollbar anyone?), and you lose too much horizontal real estate. Sure, it's got a neat initial "whizzy" factor to it, but it's simply not as usable or as scalable as the classic tab strip model.
Bookmark Groups vs. Folder Options
This is something I've implemented three different ways in Phoenix, Mozilla, and Chimera. In both Chimera and Mozilla the bookmark group is a special entity that you have to make by taking a tab snapshot. I now hate this idea. The implementation is to just have a tagged special folder that when clicked loads all the bookmarks in tabs, a sort of one-click clustered loading. This complicates bookmark management and viewing, since you now have this third kind of entity along with regular folders and bookmarks.
I much prefer the system we came up with for Phoenix, which is borrowed somewhat from Opera. In this system, folder submenus pick up an extra "Open in Tabs" menu item, and you can just load any folder's children in tabs. No special new kind of bookmark group, and no special means required for creating bookmark groups. You just work with folders and can now load a single page of a group by drilling into a folder, or load all the pages in a group.
With the Chimera way, you'd end up having a Blogs group, and then you'd also have to bookmark individual blogs for when you didn't want to load the group. You had needless replication that is avoided by just making the operation available on folders instead.
Replace vs. Append?
When doing clustered loading, we took two approaches. One can be seen in Mozilla, and I personally hate it. The other can be seen in Phoenix and is my favorite choice. Mozilla actually appends the tabs loaded by a bookmark group to the end of the tabbed list. This means that if you click first on a News group and load tabs 1-5 and then click on a Blogs group, you'll end up with new tabs 6-10.
In Phoenix, you replace instead, so the News tabs go away and are replaced by tabs 6-10. The argument for append is basically that you end up with potential data loss in that you may lose access to the previous tabs by closing up some of the ones you replaced, e.g., if the second group has fewer tabs than the first. This is of course a solvable problem, though, and doesn't justify changing the default behavior to append.
Position of Tabs inside the Tab Strip
Chimera centers tabs within the tab strip. Everyone else puts them on the left. The only reason Chimera does this is because I couldn't figure out how to use the normal tab widget to make the tabs be left-aligned. Center-alignment for a dynamic tab system is of course awful, since for every tab you open, all of the tabs move.
It's much better to avoid moving all of the tabs around when a single new tab opens, and left-aligning the tabs inside the tab strip makes for a much less jarring experience.
Where do new tabs open?
A highly debated issue with tabs is "Where should new tabs open?" NetCaptor and the old Chimera (in early versions) use the following model. If you click to open a link in a new tab, then the new page will open just to the right of the current tab. Links will continue to open to the right if you keep opening them, so you may have a setup like this:
1 2 3 4
where 2 is the active tab, and you then open three more links from 2 and end up with:
1 2 7 6 5 3 4
The advantage of this approach is that similar pages stay together. The disadvantage is that the opening of new tabs is more jarring, since you do an insertion in many cases rather than an append.
A disadvantage is that you have to read the pages from right to left in order to preserve the original order. Because of this, when you *close* tabs, this model dictates that you move to the left.
You do have the advantage that when you finish with the child links, you conveniently end up back at the original document as you close up tabs.
The second model, and the one I favor (used in Phoenix, Chimera, and Mozilla now) is to always open new tabs on the far right. Usability testing at AOL showed that this was far and away what users expected to happen, and it lends a smoothness to the tab opening process, since you never move any other tabs.
You also get to read links from left to right instead of right to left, e.g., the previous example would result in:
1 2 3 4 5 6 7
In this model, in order to be able to browse the links you open effectively, when tabs are closed you need to move to the right. Note that when you finish with child links, you don't end up back at the previous page in this case, but in the common case, you do. Note that by far the common case is to simply have:
and that you'll open a few links, end up with:
1 2 3 4
and still end up back at 1 once you close up. The ability to easily read left to right, and to not shuffle the tabs around on the tab strip when you open new links more than makes up for the edge case where you may not end up back at the parent tab.
I actually prefer Galeon's behavior here. Phoenix and Mozilla offer close boxes for the tab strip, but this UI frankly stinks, because the user expectation is that clicking on the X will actually close up the entire tab strip. In effect, the X should map to the "Close Other Tabs" command, but instead it maps to "Close Selected Tab." This is utterly confusing, and at least Chimera avoids the problem by not having a close box at all.
The right way IMO to do this is to have a close box for closing up the tab strip itself in the same place Phoenix and Mozilla have it, but to also have close boxes on the tabs themselves (the way Galeon does it). With this model, it's clear what the different close metaphors are, and you don't end up with user (even power user) confusion.
Background vs. Foreground
Despite the inconsistency with opening links in new windows, I strongly support the default in Phoenix, which is to open links in new tabs in the background by default. This option should be overridable with a modifier key (SHIFT in Phoenix) and also the default should be controllable via a pref. Phoenix, Moz and Chimera all have the same pref and modifier key, but only Phoenix defaults to background loading by default.
It's really interesting just how many different choices have been made by tabbed browsing implementers. Pick the browser that implements the system you like best I guess. :)
|All times are GMT -4. The time now is 04:25 AM.|
Powered by vBulletin
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.