Currently, the navigation buttons that become visible when sidebar tabs exceed the number of tabs in view (as set in the sidebar.num_tabs_in_view pref) only navigate forward or backward one tab at a time. We need a way for users to intuitively and conveniently navigate forward or backward multiple tabs in one click. One idea is to have fast forward and rewind buttons in addition to the current forward and back buttons: --------------------------- --------------------------- | < | > | becomes | << | < | > | >> | --------------------------- --------------------------- (except the arrows point up for back/rewind and down for forward/fast forward) Another idea is to have a menu popup originating from a >> (double arrow) at the bottom right of the sidebar when the tabs ``overflow''. This menu highlights a ``zone'' of consecutive tabs that will be shown in view. The ``zone'' will contain sidebar.num_tabs_in_view number of tabs and will move with the mouse or keyboard arrows. This idea needs design input. +--------------------+ | What's Related | <--- menu | Tinderbox | |+------------------+| ||Tinderbox-ports || ||Search |<------ ``zone'' ||Bookmarks || |+------------------+| | History | | Address Book | | dictionary.com | +--------------------+ Spun off from bug: <http://bugzilla.mozilla.org/show_bug.cgi?id=126095#c7> Once we get a definitive design for this we can implement the said design. Over to usability engineering for now.

For a user the.. --------------------------- --------------------------- | < | > | becomes | << | < | > | >> | --------------------------- --------------------------- ..way will be most natural. The menu popup has a very ugly feel to it, however it exposes more information. the best possible solution would seem.. ------------------------------- | << | < | > | >> | \\// | ------------------------------- the latter being two arrows pointing down which'll display the menu popup. Best of both worlds and very user friendly. The only problem with this however is how much space it takesup on the tabbar. Simply using bold characters as buttons should do nicely (unlikely that.. THING.. which is meant to represent a close button in the modern skin).

yatsu, That's an interesting thought. I'm all for options. But playing devil's advocate one common response to your unified solution is that we are making the UI cluttered (as you recognize) and seemingly non-trivial. But I'll leave that for a usability test.

Hello Everybody, how about getting rid of the single forward/back buttons and only have the fast forward/rewind buttons instead? Together with the menu popup (which, by the way, is a very good idea) this should give enough information and not clutter up too much space: +------+------+--------+ | << | >> | \\// | +------+------+--------+ My though was that it is not necessary to switch only one tab at a time. I think that switching all visible tabs is more convenient for the user since one does want to get to a tab which is currently not shown but perhaps one does not really know _where_ that tab is. So when we switch one tab with each click, one needs to click multiple times on ">" until the desired tab is shown. When we switch all visible tabs, you need only to click once on ">>" in order to see the desired tab (assuming scanning with the eyes for the tab is considered faster than clicking multiple times on ">" ;). Just my opinion, of course. Since we get into the area of usability, this might not be as easily solved, though. *grin* bye, daniel :)

Possible less cluttered design: How about losing the fast forward arrows, but allowing some form of auto- repeat on the slow arrows similar to the behavior of scrollbar arrows? In fact, why not just throw a horizontal scrollbar to the right of all the tabs?

because scrolling elements that are as long/wide as tabs is inefficient, confusing and a strain to the eye. I've been using Galeon for some time now and the way they solve this is simply by using one tab forward/backward buttons. I found myself often clicking these quite a few times until i reach the correct tab. This bad for several reasons. 1) performance - each tab will be displayed until you finally find the tab you were looking for. 2) the obvious usability implications. a hybrid could be chosen between Galeon's solution + a popup menu, which would prove quite effecient were it not that one would often use the menu popup to locate every single tab that is not displayed. Daniel Bachran's solution is both simple, clean and causes less usability problems than any other solution currently suggested. Not sure if i want to add anything. Three buttons seems the ideal maximum.

Alternate solution: bug 127973, scroll by several tabs at a time each time the (normal) up and down arrow buttons are clicked.

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420

Still valid.