345884 - Place both tab scroll arrows next to "all tabs" button

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, enhancement)

Description

[Michael Clackler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060725 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060725 BonEcho/2.0b1

With the addition of the "All Tabs" menu and the choice to have it always available, we have made this area of the tab bar the "default" spot for tab manipulation.  The user will quickly become accustomed to moving to this spot.  

When we go into "overflow", we add two scroll arrows.  One of the scroll arrows is currently next to the "All Tabs" menu, the other is at the opposite end of the tab bar.  It would be better if both arrows were next to the "all tabs" menu.  Two of the three controls are in this area already when in "overflow", and all of the controls are in this area under normal conditions.  The control that is missing is as far away from the "default" spot as possible.  There was recently a change in the find bar to move the close button for exactly this reason.

This change would fix the issue with clipping tabs on the opposite side of the tab bar and the issue with the far arrow button not extending to the edge. The change could also provide a larger "window" for actual tabs since there would not need to be as much padding on the controls.

Reproducible: Always

Comment 1

[Michael Clackler]

Attachment: mock-up showing all controls centrally located

Comment 2

[Peter Kasting]

This is consistent with what visual studio does, and all other scrollable tab strips I could find in Windows (which there aren't many of).  I think it looks better and is more usable.  I think if we don't ditch scrollbuttons we should strongly consider this change; it seems relatively easy to implement and would also let us enforce never drawing a partial tab on the left.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Why are you so opposed to partial tabs? They are excellent visual cues indicating that there is more beyond the visible edge of the tabstrip. Clipping is bad, but detecting that case and making a nice visual indication of "there's more tabs over here" is *exactly* what we want to do.

Putting these arrows together will cause more problems than it will solve:

1) There will no longer be any visual indication at the left side of the tab strip  when there are more tabs off to the left.

2) If I'm over near the left side of the tab strip, and I want to select a tab that's off to the left, I'd need to move my mouse all the way to the right, click on the button to slide the tabstrip to the left, then move back to the left to select the tab.

3) If I'm dragging a tab from one location to another, when I hover over the left arrow in this new location, I'd presume that the tab strip would scroll to the right, which would be confusing. Scrolling to the left, admittedly, would be more confusing. I'd be taking it on faith that dragging to the left would scroll the tabstrip.

The only usability advantage that I see out of this is that if you scrolled the strip too far in one direction, it would be easier to move it back in the other direction. I don't think that's worth the fix.

(note: this WONTFIX doesn't reflect the fact that having the arrow just appear and clip tabs at random isn't a valid bug, it just reflects the fact that this solution to that problem is inappropriate)

Comment 4

[Peter Kasting]

(In reply to comment #3)
> 1) There will no longer be any visual indication at the left side of the tab
> strip  when there are more tabs off to the left.

Right, you'd depend on the All Tabs menu glowing + indicating the visual set in the menu, which were in my original design, but maybe are too controversial or won't make it.

> 3) If I'm dragging a tab from one location to another, when I hover over the
> left arrow in this new location, I'd presume that the tab strip would scroll to
> the right, which would be confusing.

That's part of why I specced different "drag + scroll" behavior in my original design than having to target the scrollbuttons.  It seems very difficult to do in their current locations, so I just used Fitts' Law and made dragging (and holding) off either edge of the tab strip start scrolling the strip that way.  That still seems more helpful, I should probably consider filing a bug...

> The only usability advantage that I see out of this is that if you scrolled the
> strip too far in one direction, it would be easier to move it back in the other
> direction.

And you make a single targeting area for all tab strip controls, which aids muscle memory.  If I ever want to do anything with the strip my hand knows exactly where to go.

I definitely see your concern (2).  Part of this bug is really still my lack of understanding about whether scrollbuttons are serving more of an indicative or interactive function in the world with the All Tabs menu.  If we think users need to use scrollbuttons to actually select adjacent tabs frequently, then point (2) probably sinks this (though this concern was _also_ why my original design had "Distance X > 0" in it, to ensure that selecting a tab brought the nearby set into reach).  If we think that the All Tabs menu is appropriate for this, the scrollbuttons are a "functional indicator" and could perhaps be replaced with simply a ripped tab end icon that, when clicked, always scrolls exactly one additional tab into view.  (That sounds like an attempt at your parenthetical note.)