497973 - tab bar overflow animation should use the scroll arrow instead of the all tabs button

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Dão Gottwald [:dao]]

Attachment: patch

The scroll arrow seems like a more direct way to access the background tab, especially since the tab will be scrolled into view as far as possible before the overflow animation is invoked (bug 412666).

There's Mac-specific code for animating the scroll arrow, but it's unused.

Tryserver builds:
https://build.mozilla.org/tryserver-builds/[e-mail]-try-86b09f18496/

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 383008 [details] [diff] [review]
patch

Personally I think I'm in favor of always opening to the right of the tab that spawned the new tab, so we wouldn't actually need the animation.  Beltzner writes in his blog post 

>When the user explicitly asks for a new tab, it’s impossible to tell if it’s for >a task that’s related to the current activity or for a new task; as such, we >place it at the end of the tabstrip.

If the link was placed on the page the user is looking at, doesn't that implicitly make it related to the current activity?  I'm trying to think of an reasonable example where one page could spawn a number of alternate and unrelated activities, but can't think of anything yet.

>The scroll arrow seems like a more direct way to access the background tab

I'm not sure the scroll button is necessarily a faster way to access the tab that loaded off screen.  For instance if you have >30 tabs open, the scroll animation to get to the far right will end up taking a lot longer than clicking on the all tabs button and then selecting the bottom entry.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

Forgot to link to the post in my last comment http://beltzner.ca/mike/2009/01/11/a-small-change-to-tab-ordering-coming-soon-to-trunk/

Comment 3

[Dão Gottwald [:dao]]

(In reply to comment #1)
> Personally I think I'm in favor of always opening to the right of the tab that
> spawned the new tab, so we wouldn't actually need the animation.  Beltzner
> writes in his blog post

That doesn't necessarily block this bug. This change can happen now, and the other change can happen whenever it's ready.

As someone who has always 30 to 50 tabs in one window, I find the scroll buttons much easier to use than the all-tabs button (regardless of browser.allTabs.previews) when I know the position of the tab (which I do in this case; and a triple click will bring directly to the last tab).

Another reason for this change is that if we want to make the tab strip, the new-tab button and all-tabs button customizable toolbar items, the all-tabs button needs to be decoupled from the tab strip.

Comment 4

[Dão Gottwald [:dao]]

(In reply to comment #3)
> As someone who has always 30 to 50 tabs in one window, I find the scroll
> buttons much easier to use than the all-tabs button (regardless of
> browser.allTabs.previews) when I know the position of the tab

Btw, the old all-tabs menu (browser.allTabs.previews = false) actually has its own overflow facility, so if you have many tabs and want to get to the last one, there's a good chance that you'll have to scroll within the popup. -> Fail.

Comment 5

[Dão Gottwald [:dao]]

Comment on attachment 383008 [details] [diff] [review]
patch

requesting a second review based on my previous two comments

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

>Btw, the old all-tabs menu (browser.allTabs.previews = false) actually has its
>own overflow facility, so if you have many tabs and want to get to the last
>one, there's a good chance that you'll have to scroll within the popup. ->
>Fail.

Yeah, what makes this decision complex is that is a range of tabs where the tab strip is overflowing, but the all tabs drop down is not (because tabs are wider than they the menu items are tall).

Is there a way for us to control the overflow on the all tabs drop down menu so that it would be scrolled to the bottom when accessed right after a notification? (ideally also with a styling similar to a Windows task bar item trying to get the user's attention).

I think overall this would be the fastest way for the user to get to the tab (outside of not placing it at the very end of the tab strip to begin with).

Comment 7

[Dão Gottwald [:dao]]

(In reply to comment #6)
> Is there a way for us to control the overflow on the all tabs drop down menu so
> that it would be scrolled to the bottom when accessed right after a
> notification? (ideally also with a styling similar to a Windows task bar item
> trying to get the user's attention).

"Right after" could be time based or action based, but it seems that we could miss cases and get false positives either way.

I think the legacy popup has issues in a way that makes it not worth messing around with. Rather than trying to guess and auto-scroll, the premise should be that there is no extra level of overflowing in the all-tabs UI.

> (outside of not placing it at the very end of the tab strip to begin with).

... another reason not to overengineer this.

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

>... another reason not to overengineer this.

sorry, really just trying to figure out which button is optimal since we are going to be giving the user a clear suggestion of how they should get to their tab (and it seems like logically one of them should actually be better than the other).

Since the fastest way to access the new tab will eventually be through the new all tab interface that you are working on, I guess I would rather not switch the notification now and then just have to switch it back again.  I would imagine that users wouldn't be overly confused even if we did do this, but we might as well keep it all consistent and not have the UI bounce back and forth if we can avoid it.

Comment 9

[Dão Gottwald [:dao]]

The all tabs interface I worked on is designed to help you find any random tab. It is not optimized for going to the last tab. The fastest way to do that will still be middle-clicking the scroll button or Accel+9.

We would not want to switch back to the old animation, for that reason and for the reason that the all tabs button and the new tab button should eventually be customizable. A user could user could remove it, or he could place it on the toolbar.

Comment 10

[Dão Gottwald [:dao]]

(In reply to comment #9)
> still be middle-clicking the scroll button

sorry, triple-clicking

Comment 11

[Dão Gottwald [:dao]]

(In reply to comment #9)
> The all tabs interface I worked on is designed to help you find any random tab.
> It is not optimized for going to the last tab.

In fact, it's pretty much the worst use case for that UI. You haven't selected that tab before, so you may not recognize the preview, nor the title.

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

I was thinking in terms of mouse distance and time for scrolling.  If the thumbnail for a new tab always appeared last (it is after all the least most recently used), and it had a sort of notification glow to it (like how windows on the task bar turn orange when they want your attention), then wouldn't that path be more efficient:

1) move mouse to all tabs button
2) visual gaze to locate last item
3) move mouse to last item

since it doesn't have the animated scrolling step #2:

1) move mouse to tab scroll arrow
2) depress tab scroll arrow and wait for tabs strip to scroll all the way (costly if there are a very large number of tabs)
3) move mouse off of tab scroll arrow and a little to the left to select the last tab

Unless of course the plan is for the the all tabs display to have its own overflow capability, in which case I agree that suggesting the user use the tab scroll arrow is the most efficient path.

Comment 13

[Dão Gottwald [:dao]]

Since you mention mouse distance, the last item in the popup isn't necessarily on the lower right, but can just as easily appear on the left. The all tabs button is on the upper right, so the mouse distance randomly varies between moderately long and exceedingly long.

It's also worth mentioning that the window's last tab won't necessarily be the last item in the popup. There was thinking that the all tabs popup should show tabs from all windows, which is still up in the air.

And again, pressing the scroll arrow and waiting isn't the only way to scroll to the end, nor the most efficient one. You could click it repeatedly, use mouse wheel scrolling or hit accel+9. Users with plenty of tabs are more likely to know such shortcuts, fwiw.

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #13)
> And again, pressing the scroll arrow and waiting isn't the only way to scroll
> to the end, nor the most efficient one. You could click it repeatedly, use
> mouse wheel scrolling or hit accel+9.

Also Ctrl+Tab, assuming it's enabled.
Hinting on the scroll arrow leaves all these options open, as it points to where the tab is, whereas the all-tabs button doesn't point anywhere and focuses on one particular option (an inefficient one, imho).

Comment 15

[Dão Gottwald [:dao]]

Comment on attachment 383008 [details] [diff] [review]
patch

Now that we open background tabs relative, pretty much the only way to get the overflow animation is to open x+2 tabs in the background if x tabs fit on the tab bar. So the scroll button will make the hidden tabs visible one by one, while they aren't easily identifiable in the popup, because they aren't at the end but followed by other tabs.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 383008 [details] [diff] [review]
patch

This looks good.

I kind of wonder if we would want to scroll the tab strip to show overflow tabs now that the are relative.  Although I'm not sure if that would be useful or annoying.  Anyway, that would be a follow up bug if we want to consider it.

Comment 17

[Dão Gottwald [:dao]]

Attachment: updated to trunk

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 402541 [details] [diff] [review]
updated to trunk

Looks ok to me, but boy do I wish we had a better way to do that animation... having to do string replacement on CSS there is painful!

Comment 19

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/c81b1a445426

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed on trunk with builds on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091109 Minefield/3.7a1pre ID:20091109034249

I would have to update a litmus test once we start to cover the 1.9.3 branch.