126559 - Give users a way to ``fast forward'' tabs when the sidebar tabs in view ``overflow''

Status: NEW

(SeaMonkey :: Sidebar, defect)

Description

[Samir Gehani]

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.

Comment 1

[yatsu]

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).

Comment 2

[Samir Gehani]

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.

Comment 3

[Daniel Bachran]

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 :)

Comment 4

[Damian Yerrick]

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?

Comment 5

[yatsu]

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.

Comment 6

[Jesse Ruderman]

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

Comment 7

[Robert Kaiser]

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

Comment 8

[Robert Kaiser]

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

Comment 9

[Karsten Düsterloh]

Still valid.