570564 - Improve tab overflow navigation

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[Alex Limi (:limi) — Firefox UX Team]

Attachment: Tab overflow and "tuck" under the new Firefox 4 theme

Currently, we show two little arrows for scrolling tabs left and right when they overflow.

Some problems with the current approach:

1. It's not easy to see at a glance whether there are more tabs to the left/right side, since the only indicator is a very small arrow that gets ghosted if you are at the end of a row of tabs.

2. It introduces two more controls which adds visual noise to the tab bar, which is already quite crowded with the overflow pulldown and the new tab button.

One suggested way of fixing this would be to make sure the overflowing tabs are always shown partially, so instead of requiring discrete UI elements for scrolling to the next tab, you simply click the partially hidden tab, and it scrolls over to reveal that tab & parts of the next one (if it exists). 

This also makes it much easier to see whether there's tab overflow on either side or not, since spotting a partial tab is a more visible UI element than a ghosted/unghosted arrow.

Visual treatment of how this would look under Firefox 4 attached.

The only downside of this approach is that you can't keep the mouse button depressed to scroll several tabs after each other, but need to click instead. Of course, scrolling using the mouse wheel/trackpad still works as before, and a random sampling in the field seems to have people in two main categories: those who use the scroll wheel or those who click once for every tab they want to move over. I haven't seen anyone using the hold-to-scroll behavior yet, possibly because it's hard to know when to stop. I don't claim to have anywhere near representative data on this, though. :)

Frank Yan has a partial implementation of this already, so we can test how it works in practice. He told me he'd attach it once there was a bug on file for it.

Comment 1

[Frank Yan (:fryn)]

Attachment: WIP (see comment #1)

3 parts to the bug:
1. partially show first overflow tab in the scrolled direction
2. "tuck" overflow tabs into the tab container
3. remove the scroll buttons

remaining issues:
1. make sure first overflow tab on each side is partially visible and clickable
2. unbreak dragging beyond tab container horizontal bounds to scroll

things to consider/test before shipping in a release:
1. discoverability of clicking partially visible overflow tab to scroll
2. performance of -moz-box-shadow (for "tucking" overflow tabs)

Comment 2

[Dão Gottwald [:dao]]

(In reply to comment #0)
> The only downside of this approach is that you can't keep the mouse button
> depressed to scroll several tabs after each other, but need to click instead.

This is a showstopper, fwiw.

Also note that we support double and triple clicks on the scroll buttons, to scroll one page and to the start/end, respectively.

> I haven't seen anyone using the hold-to-scroll behavior yet,
> possibly because it's hard to know when to stop. I don't claim to have anywhere
> near representative data on this, though. :)

Well, I use it...

Comment 3

[Frank Yan (:fryn)]

(In reply to comment #2)
> (In reply to comment #0)
> > The only downside of this approach is that you can't keep the mouse button
> > depressed to scroll several tabs after each other, but need to click instead.
> 
> This is a showstopper, fwiw.

There are currently two ways to switch to an initially completely hidden tab:
1. Click-and-hold or repeatedly click the scroll buttons until you find the tab you find the tab you want.
2. Select it from the tab menu.

The only advantage of the first method is that if you remember exactly where the tab you want is and the tab is also near the currently visible ones, then it might be faster.
Otherwise, using the repeated/modified click: each click requires the user to check if the wanted tab is among the newly visible ones. Using click-and-hold: the user must spot the wanted tab while the tab container is scrolling rather quickly and release in time before it disappears again.

The second method requires a maximum of two clicks to reach any tab (even when you have so many that you have to scroll the tab menu), and it does not pose any coordination and reaction time challenges.

While we're on this subject of tab overflow, the scroll buttons also provide no indication of how many more tabs there are. We can easily provide some sense of this by highlighting the currently visible tabs in the tab menu.

My take is that we should be moving away from the use of scroll buttons in the tab bar and towards the Tab Candy's tab grouping. This is not telling the user what to do but rather providing a friendlier UI for handling many tabs. The idea is that when we do have 20+ tabs, it rarely means that we are working on 20+ tasks. Instead, the tabs are almost always oriented towards less than 5 different tasks, which means that, rather than be working with a scroll bar, modifier keys, and long/repeated clicks, we should be able easily to group them.

Comment 4

[Dão Gottwald [:dao]]

As opposed to the scroll buttons, I found the menu cumbersome and disabled it (browser.allTabs.previews=true).

The TabCandy argument is not a useful one: If the idea is that overflow will rarely happen in the future, that still does not mean we shouldn't have scroll buttons if overflow does happen.

Comment 5

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

(In reply to comment #0)
> 1. It's not easy to see at a glance whether there are more tabs to the
> left/right side, since the only indicator is a very small arrow that gets
> ghosted if you are at the end of a row of tabs.

I actually end up with partial tabs a lot of the time; maybe that's an OSX thing which doesn't carry over to Windows?

> 2. It introduces two more controls which adds visual noise to the tab bar,
> which is already quite crowded with the overflow pulldown and the new tab
> button.

Agreed - we should only show these controls when they'll do something, at which point they also double as a visual indicator.

> One suggested way of fixing this would be to make sure the overflowing tabs are
> always shown partially, so instead of requiring discrete UI elements for
> scrolling to the next tab, you simply click the partially hidden tab, and it
> scrolls over to reveal that tab & parts of the next one (if it exists). 

That there is a partial tab shows me that there's more off to the side, but I don't think it clearly tells me how to see what's off to that side. While I might think to click on the partial tab, I'll then see another partial tab. That seems very frustrating to me.

> The only downside of this approach is that you can't keep the mouse button
> depressed to scroll several tabs after each other, but need to click instead.

That's quite a downside. In selecting a tab, we'll also focus it, switching the content area. So now if I want to flip through my tabstrip, I *must* select each tab in turn. Despite your assertion below, I simply do not believe that this is maximally convenient.

> Of course, scrolling using the mouse wheel/trackpad still works as before, and
> a random sampling in the field seems to have people in two main categories:
> those who use the scroll wheel or those who click once for every tab they want
> to move over. I haven't seen anyone using the hold-to-scroll behavior yet,
> possibly because it's hard to know when to stop. I don't claim to have anywhere
> near representative data on this, though. :)

So let's get a Test Pilot study together before we make this sort of change? My random sampling shows many people who *do* use the arrows. I don't think that the scrollwheel is well known as a control for the tabstrip scrolling, especially for most Windows users where it is a vertical control affecting a horizontal strip.

> Frank Yan has a partial implementation of this already, so we can test how it
> works in practice. He told me he'd attach it once there was a bug on file for
> it.

This is one case where I don't think we need to play with it to reason how it works; simple GOMS modelling shows us that we're drastically increasing the number of clicks required, as well as increasing the amount of visual scanning needed as the content area changes.

I would much much rather a solution where:

 - when there is additional content in the tabstrip, the arrow appears
 - when there isn't, the arrow disappears
 - the arrows overlap the "partial tab" indicating "more this way, click here to scroll it into view"
 - (optionally) only show the arrows when you hover over the tabstrip

Comment 6

[Madhava Enros [:madhava]]

At the moment, when you scroll along the tab strip, we line up the outer edge of the last newly shown tab with the edge of the strip (on OSX, anyway).  This means that the (active vs. inactive) arrow button is the only cue that there are more beyond the strip edge.  Instead, perhaps we should show the first bit of the next tab as well - possibly as much as the whole favicon space.

Clicking on the partially visible tab should select that browser tab and pull the tab-bar tab into view, pulling another (if avaialable) partial tab into view as well.

Reading over this, it's basically what limi proposed originally, but without getting rid of the arrows, which I suspect _are_ used to scroll along the bar.

Comment 7

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

Yeah, as Madhava says, I think that the idea of always ensuring that we show the hint of "more tabs" is a far better indicator than asking users to discern between the "active" and "inactive" arrows.

I also think that in this case, we can hide the arrows if the user isn't hovering over the tabstrip, which solves the issue of visual noise.

As indicated in comment 5 and comment 6, though, I think we need to have some sort of scroller control that at least appears on hover to assist with moving the tabstrip along.

Comment 8

[Dão Gottwald [:dao]]

Hinting at off-screen tabs has the problem that it needs to happen on two sides simultaneously. This won't always work as intended, given variable window sizes, a configurable tab minimum width, theme-dependent widths of the other elements in the tab bar, and the customizability of the tab bar. Hiding the arrows when you're scrolled to the end seems more straightforward.

Comment 9

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #5)
> That's quite a downside. In selecting a tab, we'll also focus it, switching the
> content area. So now if I want to flip through my tabstrip, I *must* select
> each tab in turn. Despite your assertion below, I simply do not believe that
> this is maximally convenient.

I also don't think it's a big deal. But let's refine and get some data, I'm sure we can figure this one out.

> > Of course, scrolling using the mouse wheel/trackpad still works as before, and
> > a random sampling in the field seems to have people in two main categories:
> > those who use the scroll wheel or those who click once for every tab they want
> > to move over. I haven't seen anyone using the hold-to-scroll behavior yet,
> > possibly because it's hard to know when to stop. I don't claim to have anywhere
> > near representative data on this, though. :)
> 
> So let's get a Test Pilot study together before we make this sort of change? 

Already done as part of the "what is clicked in the UI" study, waiting for the data to be processed (Metrics team has it, I'll follow up).

> I would much much rather a solution where:
> 
>  - when there is additional content in the tabstrip, the arrow appears
>  - when there isn't, the arrow disappears
>  - the arrows overlap the "partial tab" indicating "more this way, click here
> to scroll it into view"
>  - (optionally) only show the arrows when you hover over the tabstrip

Thanks for the feedback, I'll see if there's a way to incorporate this thinking into our approach.

Comment 10

[mucinch]

Instead of arrows, how about showing a tab button at the end of the tab strip with a numeral indicating the number of tabs hidden on the right side? clicking the button can either scroll the tabs to the right (if all of them can be accommodated) or could open a tab list menu containing the titles of the hidden tabs. The same could be done on the left side of the tab strip. The numbers could also be made to blink softly bringing attention to it.

This way the user can select even the last tab out of 20-30 with a few clicks.

Comment 11

[[not reading bugmail]]

(In reply to comment #10)
> Instead of arrows, how about showing a tab button at the end of the tab strip
> with a numeral indicating the number of tabs hidden on the right side? clicking
> the button can either scroll the tabs to the right (if all of them can be
> accommodated)

Not a bad idea, but I also use hold and scroll myself and I personally think the current implementation is good versus many alternatives.  Not to mention you can use also the mousewheel on the tab bar to scroll left or right the way it is.

> or could open a tab list menu containing the titles of the hidden
> tabs. The same could be done on the left side of the tab strip. 

Again too noisy as stated above.

Have you checked into the alltabs button at the end of the tab bar?   We already have a tab list and alltabs panel on the end of the tabbar if you change its pref:  the pref browser.allTabs.previews = false this has been in place for a long time.

Comment 12

[mucinch]

> Not a bad idea, but I also use hold and scroll myself and I personally think
> the current implementation is good versus many alternatives.  Not to mention
> you can use also the mousewheel on the tab bar to scroll left or right the way
> it is.

The problem with the current implementation is it does not provide the user enough visible data. The mousewheel scroll denies perspective to the user. If the user scrolls too fast he might overshoot the target frustrating himself.
The advantage of the numbered approach is it acts as a compass telling the user whether he is near the start, center or end of the tab strip.

Common examples of an average user resulting in having more than 10 tabs open are when shopping, comparing products, researching (Google/Wikipedia), etc. In all cases he will want to go back to the parent tab eventually. The current implementation does not provide an easy way to achieve this because he would not know how far away he is from the first tab.

> > or could open a tab list menu containing the titles of the hidden
> > tabs. The same could be done on the left side of the tab strip. 
> 
> Again too noisy as stated above.
> 
> Have you checked into the alltabs button at the end of the tab bar?   We
> already have a tab list and alltabs panel on the end of the tabbar if you
> change its pref:  the pref browser.allTabs.previews = false this has been in
> place for a long time.

The alltabs panel (with previews) is not helpful with more than 10 tabs opened. It also obscures the UI similar to a modal dialog. A tab list will open near the edges of the UI not blocking the content. 

Thumbnail previews result in too much mouse movement as the user has to move the mouse too far from the button to click a tab preview on the left. Also it suddenly creates more dimensions (from left-right to left-right-top-bottom) confusing the user.

The currents list of tabs button is always present which is redundant with only a few tabs open. Also it is located on the right side, if I need to access a tab hidden on the left side my first impulse will be to move the mouse to the left. Looking at the mockups, I don't know how long a new user clicks on subsequent partially hidden tabs before he realizes he can scroll through them. Because scrolling on tabs is not the first reaction. 

Currently during tab overflow, there are three buttons on the tab strip (left and right arrows and list of tabs button), when the UI contain arrows the first impulse of an average user is to click on them to access the hidden tabs, not scrolling as done by a power-user. There is always a left and right arrow present, even when the user is on the first or the last tab. The aero theme in minefield does not differentiate too much between the enabled and disabled states of the arrow. I always ended clicking the arrow a few times before realizing I am already at the end.

Maybe the numbered approach is not the best answer, but neither are arrows and partially hidden tabs. Lets hope Mozilla comes up with a better solution. Sorry for the long post.

Comment 13

[imradyurrad]

This should be blocking final+

Comment 14

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

I don't think this blocks at all, actually.

Comment 15

[u428464]

Any news on this bug ?

Comment 16

[u428464]

Just a little precision. I'm asking because of the future tab strip redesign (mockup : http://people.mozilla.com/~shorlander/files/feature-pages/australis-tabs.png ) With the inactive in the background is this bug still relevant ?

Comment 17

[u428464]

Chrome recently implemented a new way to handle tab overflow with tab stacking. It's actionable in about:flags in the last builds of canary/chromium.