Tabbed Browsing/User Interface Design/Tab Overflow

From MozillaWiki
Jump to: navigation, search

Tracked by http://bugzilla.mozilla.org/show_bug.cgi?id=221684

Introduction

We need to find a better way of handling the "too many tabs to fit nicely on the tab bar" case. When users get beyond 15/20 tabs, depending on screen resolution, the tabs become almost unusable.

Suggestion from user Ge.diego on opening too many tabs

Goals

  • Support faster access to a larger number of tabs
  • Preserve tab ordering
  • Preserve keyboard navigation
  • Preserve drag and drop reordering

Analysis

Ben Goodger

I have covered this in some detail mentally before and here are my notes:

Given that the tabbed browser has these features: - drag and drop reordering - keyboard accessible navigation

... and that we want to try retain those even for overflowed tabs (dragging a tab back to the start of the set when it's at the end is occasionally useful):

Chevron Menu Only (Safari)

  • When you select an item from the overflow menu, the indication of selected tab vanishes from the strip, which looks weird and gives no indication as to what is actually selected.
  • D&D and keynav break, unless you want to implement various horrid hacks to show the popup menu and allow dragging/navigating into it, which almost certainly don't work on Mac.

Chevron Menu with Scrolling Strip

  • When you select a tab from the menu, the strip is zoom-scrolled so that the tab is visible. This solves the "no visible selected tab in tab strip" issue that affects the plain Chevron Menu solution. However when the strip is scrolled the set of non-visible tabs changes. There may be more non-visible tabs to the right and now left of the strip, meaning two menus need be shown, perhaps at alternate ends of the tab strip. This sounds cumbersome.
  • D&D and keynav probably work in this case though.

Chevron Menu with Tab Reordering (Visual Studio 2005)

  • LIFO ordering on the strip, sense of insertion is inverted. New tabs appear at the start of the strip and older ones move to the right until they are eventually evicted into a menu. Selecting an item from the menu re-inserts the item at the start of the strip. I have been using VS2005 for over a month now and this is a disaster. The delicate order of tabs that some users have is not only not preserved, it is actively destroyed. They should have left it the way it was.
  • Doesn't easily support D&D or keynav to non-visible items.

Scrolling Strip (buttons) (Visual Studio 2003 and earlier)

  • Supports D&D and keynav while maintaining a single static piece of UI (scroll buttons)
  • Setting the scroll speed correctly is likely to be a challenge.
  • No instant way of getting to a hidden tab - speed of access relies on scrolling and dexterity


Mike Connor

The first four were described by Ben's comments, so I won't repeat them.

General conclusions

Regardless of the method selected, fixed width tabs are a big win.

Chevron Menu only

Implemented for tabs by: Safari

Conclusion: This basically seems like a bad idea (see Ben's thoughts) so I won't do a lot of analysis.

Chevron Menu with Scrolling Strip

Implemented for tabs by: Gedit (GNOME) and some other linux apps.

Pros:

  • Quick and direct access to many tabs.
  • Keyboard nav and Tab DnD is preserved and understandable.

Cons:

  • Chevrons on both ends seem a little cumbersome if needed
  • Only scales so far before you hit scrollbuttons.

Chevron Menu with Tab Reordering

Implemented for tabs by: Visual Studio 2005

Pros:

  • LIFO order is useful in most-recent-matters-most worlds.

Cons:

  • Breaks relationships and grouping.

Scrolling Strip with Scrollbuttons

Implement for tabs by: Visual Studio 2003 and earlier

Pros:

  • Single static piece of UI, supports DnD and keyboard nav.

Cons:

  • Getting scroll speed right is difficult
  • Tab DnD and keyboard nav become reaction-time dependent

Scrolling Strip + Tab Menu button

Implemented for tabs by: IE7 beta2

Description:

  • Full list of tabs is available via a menubutton, with visible tabs highlighted.

Pros:

  • Allows a single unified list of tabs to scan.

Cons:

  • Doesn't work so well with keyboard nav.
  • Breaks away from the visual connectedness of the tab bar.

Multiple Rows of Tabs

Implemented for tabs by: Textpad, other text editors

Pros:

  • Keeps all tabs on screen, fastest access minus multiline-scan time.

Cons:

  • Shifting rows OR disconnect between tab and tab contents.
  • Consumes content area space.

See Aravindet's proposal for a multi-row layout without the shifting/disconnect disadvantage.

Final Thinking

Of the options present, the Chevron Menu with Scrolling Strip seems to feel the most natural, both in UI consistency with bookmarks overflow, and the concept of extending the tab strip. It also avoids a lot of timing/speed issues associated with other solutions.

[pkasting] So is there a reason we implemented the scrolling strip w/scrollbuttons in Firefox 2 instead? Was that just quicker to implement and will change some day, or was there more discussion not recorded here?

Other threads about tabs, tab overflow, and tab design

Over the years there have been many disjointed threads about tabs, tab overflow, and tab design on how to handle the issues of the close button, drag-and-drop, screen real estate, tab width, etc. This list is meant to bring together previous discussions that may have good, but overlooked ideas. The dates (yyyy-mm-dd) listed are of the first post in each thread.

Tab modifiers for other versions of Firefox (1.0x/1.5x)

Looking at addons and their screenshots can give ideas as to what features and capabilities users are looking for in their tabs.

Retrieved from "https://wiki.mozilla.org/index.php?title=Tabbed_Browsing/User_Interface_Design/Tab_Overflow&oldid=193929"