I just landed the "tab scrolling" patch to the trunk, see bug #318168. In tomorrow's builds, you'll see a change to how we handle browser windows with "too many" tabs.
Specifically, the tabs are now contained in a horizontal arrowscrollbox, so when you have too many (which depends on the width of the window and the min-width of a tab[1]), you will see arrow buttons on either side of the tab strip.
You must click on the arrow buttons to scroll the tabs, and it will scroll one tab at a time. [2]
When dragging a tab, if you hover the arrow button, we scroll 20 pixels at a time [3].
Additionally, there are new events for when we add, remove, and move tabs [4].
Thanks to Mark Mentovi for fixing some bugs which help improve tab drag and drop on the Mac. [5]
-Seth
[1] The default is 140px. The existing, hidden browser.tabs.tabClipWidth integer pref is now broken, and I'm working on fixing it. See https://bugzilla.mozilla.org/show_bug.cgi?id=342385 [2] This is not the default behavior of scrollboxes. I added a "clicktoscroll" attribute, which if true, will not scroll on hover and will only scroll on click. [3] The hidden "toolkit.scrollbox.scrollIncrement" integer pref (which defaults to 20px) can be used to change the speed. [4] See https://bugzilla.mozilla.org/show_bug.cgi?id=322898 for some details about the new events. [5] See bug #342229 and bug #342361
Seth Spitzer wrote: > You must click on the arrow buttons to scroll the tabs, and it will > scroll one tab at a time. [2]
> When dragging a tab, if you hover the arrow button, we scroll 20 pixels > at a time [3].
Did you consider incremental scrolling for the first case as well? It feels a lot snappier and more graceful that way. It would be even better if the jump was smaller than 20px.
Seth Spitzer wrote: > Specifically, the tabs are now contained in a horizontal arrowscrollbox, > so when you have too many (which depends on the width of the window and > the min-width of a tab[1]), you will see arrow buttons on either side of > the tab strip. > [1] The default is 140px.
I think it should be much smaller.
Rationale: Let us imagine a typical use case when I have many tabs open: planning vacation. I googled for some travel agencies, hotels, airlines etc and opened them all in tabs.
1) I am currently at a "Goat" travel agency website and I'm done reading it. I can't see most of my tabs, though. How many other agencies did I open? What tabs do I have left to deal with?
The major drawback of the tab overflow compared to the old "tab squeezing" is that a user has a poor overview of his tabs. With the old behavior it would take just a quick glance at the tab bar. Apart from the extreme cases, the user could still easily identify the tabs, despite the relatively small size of a tab. A favicon and the first word of the title is enough most of the time. However, currently there's no way to find out how many tabs there are exactly and what's in them, other than scrolling which is very tedious. Not having an overview means that the user doesn't know "where he is" among his tabs - there may be 50 more of them to his right or there may be none. That doesn't make him feel in control and comfortable.
2) Ok, so "Goat" are too expansive for me. I'd like to switch to a "Teleporter" agency, yet I can't see its tab. I remember I have opened it - which is already lucky, because if I didn't remember I couldn't immediately check it - but where is it? To the left or to the right?
The above pretty much speaks for itself. User can't immediately locate the tab he's looking for and he doesn't know in which direction to scroll.
3) Oh, well, let's try scrolling to the right first... Bingo! But now I want to switch back. Scrolling again? I'm already hating those arrows.
end-of-rationale
Therefore I think that tab overflow should be activated only in the edge case, when tabs are becoming illegible. The rest of the time it's making things worse. I guess the default min-width should be reduced by half.
Seth Spitzer wrote: > I just landed the "tab scrolling" patch to the trunk, see bug #318168. > In tomorrow's builds, you'll see a change to how we handle browser > windows with "too many" tabs.
I've gotten a lot of good feedback and suggestions in bugzilla (and directly in email) about this change. I'll collect it all and follow up to this thread with a list of the changes I'll be working on to improvec the "tab scrolling" feature.
Seth Spitzer wrote: > I've gotten a lot of good feedback and suggestions in bugzilla (and > directly in email) about this change. I'll collect it all and follow up > to this thread with a list of the changes I'll be working on to improvec > the "tab scrolling" feature.
The first pass of changes will be to improve/fix the behavior and the second pass will be to fix the look/style.
For the behavior fixes, I'm starting with:
1) clicking and holding the arrowbox button should scroll (#342906) 2) use a hidden pref for min width (#342890) 3) indicate that a new tab was opened in the background (#342900) 4) disable arrowbox buttons when you can't scroll any further (#342841)
On 6/28/06, Seth Spitzer <sspit...@mozilla.com> wrote:
> 1) clicking and holding the arrowbox button should scroll (#342906) > 2) use a hidden pref for min width (#342890) > 3) indicate that a new tab was opened in the background (#342900) > 4) disable arrowbox buttons when you can't scroll any further (#342841)
About 4), it reminds me a bit of https://bugzilla.mozilla.org/show_bug.cgi?id=222274 Perhaps the arrowbox should disappear when you can't scroll any further (well, it's also suggested in the bug #342841)? When you hover over the autorepeatbutton, shouldn't it scroll? That seems like a more natural behavior to me.
> Perhaps the arrowbox should disappear when you can't scroll any further > (well, it's also suggested in the bug #342841)?
The plan is to disable the button instead of hide it, so that the UI wouldn't move out from under you when you hit the end. (I added this reasoning to bug #342841)
> When you hover over the autorepeatbutton, shouldn't it scroll? > That seems like a more natural behavior to me.
By default, scrollboxes do scroll on hover. For more on why we decided not to scroll on hover, see bug #342364. The tab scroll bar is more like a horizonal scrollbar (but without the scrollbar). See also bug #342906, where the plan is to make it so when you click and hold, we'll scroll at the same rate we do when you drag a tab and scroll.
Seth Spitzer <sspit...@mozilla.com> wrote: > The first pass of changes will be to improve/fix the behavior and the > second pass will be to fix the look/style.
> For the behavior fixes, I'm starting with:
> 1) clicking and holding the arrowbox button should scroll (#342906) > 2) use a hidden pref for min width (#342890) > 3) indicate that a new tab was opened in the background (#342900) > 4) disable arrowbox buttons when you can't scroll any further (#342841)
When I hover the mouse pointer over the overflow buttons, I'm not given visual confirmation of such. This is inconsistent with the toolbar buttons, wherein the buttons show an outline when hovered over, and this feels quite awkward.
> I just landed the "tab scrolling" patch to the trunk, see bug #318168. > In tomorrow's builds, you'll see a change to how we handle browser > windows with "too many" tabs.
Where was it decided that this was a good idea? What was the reasoning? Were any studies done?
>> I just landed the "tab scrolling" patch to the trunk, see bug #318168. >> In tomorrow's builds, you'll see a change to how we handle browser >> windows with "too many" tabs.
> Where was it decided that this was a good idea? What was the reasoning? > Were any studies done?
> ...Because I'm not liking it at all.
same here. i mean, i suppose *something* has to be done when you get too many tabs to handle, but i don't think this is it.
On Mon, 26 Jun 2006 16:25:21 -0700, Seth Spitzer wrote :
> All,
> I just landed the "tab scrolling" patch to the trunk, see bug #318168. In > tomorrow's builds, you'll see a change to how we handle browser windows > with "too many" tabs.
I saw this landed on 1.8 branch recently.
I'm a bit surprised that such a big change comes in just a few days before Firefox 2.0 first beta! That opens a dozen of new bugs. I don't want to be pessimistic, but if they are not solved for beta, I guess there will be lots of duplicates and complaining from testers.
Adam Kowalczyk wrote: > Seth Spitzer wrote: > > Specifically, the tabs are now contained in a horizontal arrowscrollbox, > > so when you have too many (which depends on the width of the window and > > the min-width of a tab[1]), you will see arrow buttons on either side of > > the tab strip.
> > [1] The default is 140px.
> I think it should be much smaller.
> Rationale: > ... > The major drawback of the tab overflow compared to the old "tab > squeezing" is that a user has a poor overview of his tabs. With the old > behavior it would take just a quick glance at the tab bar. Apart from > the extreme cases, the user could still easily identify the tabs, > despite the relatively small size of a tab. A favicon and the first word > of the title is enough most of the time. > - Adam
I want to second Adam's comments. I like the scrolling feature, and the case of too many tabs/tab overflow is one that has to be handled. However, I don't think I've ever wished for a wider minimum width than the one we've been living with (approximately 55px wide).
I don't necessarily need to see a lot of the title to pick the tab I want. A lot of times the site favicon is enough to identify the tab i'm looking for, and if that isn't enough the first couple letters of the title will be plenty for disambiguation. If that still isn't enough i can always hover the mouse over the tab to see the full title (in a popup tooltip).
I think that a small or configurable min-width for tabs is key to making this work.
This only addresses the use case of "locate and switch to an open tab that is not the current tab", or something like that. Some of the other cases would be along the lines of "tell me whether a tab is still open", "show me all the open tabs", or even "cycle through all the tabs to help me reestablish work context (what the heck was I doing again?) after checking World Cup scores".
> >> I just landed the "tab scrolling" patch to the trunk, see bug #318168. > >> In tomorrow's builds, you'll see a change to how we handle browser > >> windows with "too many" tabs.
> > Where was it decided that this was a good idea? What was the reasoning? > > Were any studies done?
> > ...Because I'm not liking it at all.
> same here. i mean, i suppose *something* has to be done when you get > too many tabs to handle, but i don't think this is it.
>>>> I just landed the "tab scrolling" patch to the trunk, see bug #318168. >>>> In tomorrow's builds, you'll see a change to how we handle browser >>>> windows with "too many" tabs. >>> Where was it decided that this was a good idea? What was the reasoning? >>> Were any studies done?
>>> ...Because I'm not liking it at all. >> same here. i mean, i suppose *something* has to be done when you get >> too many tabs to handle, but i don't think this is it.
For the sake of discussion, a couple other options:
1. Rather than sideways scrolling, apply a chevron on the right edge of the browser tabs box when the box overflows, the same as is done now with the personal bookmarks toolbar. Selecting the chevron would present a menu of open tabs, or of tabs not visible within the browser tabs box.
2. If scrolling sideways, then maybe put the two scroll arrows side-by-side, rather than at opposite ends of the tabs box, to minimize the amount of mouse movement required
Sorry if I'm rehashing options already considered elsewhere.
mcdavis...@netscape.net wrote: > For the sake of discussion, a couple other options:
> 1. Rather than sideways scrolling, apply a chevron on the right edge of > the browser tabs box when the box overflows, the same as is done now > with the personal bookmarks toolbar. Selecting the chevron would > present a menu of open tabs, or of tabs not visible within the browser > tabs box.
That's not a bad idea...you'd then have space to see part of the page titles. But what do you do with the tab bar after choosing a tab? Would it scroll over to the selected window? Would the tab order change?
> 2. If scrolling sideways, then maybe put the two scroll arrows > side-by-side, rather than at opposite ends of the tabs box, to minimize > the amount of mouse movement required
I remember seeing some versions of MacOS, and Windows via add-ons, doing this with vertical scrollbars. Actually they did more...they put the arrows on both ends of the scrollbar and then put an extra arrow near the lower arrow. If placed horizontally, it'd look like: <--------------------<> This way you can scroll from either end, or just from the '<>' end.
My opinions on the tab scrolling design in Gecko/20060701 BonEcho/2.0a3: 1.) the default minimum width should be much smaller...I'd be happy with the default used in FF 1.5.05, although I can see that some users may want a larger minimum width before tab scrolling comes into play. 2.) the scrolling arrows need to be better separated from the tabs (sometimes after scrolling there is no divider between the arrow and the tab) 3.) the existence of close buttons on unselected tabs are accidents waiting to happen, but at least it can be undone. I think the close button should only be active and clickable on the current tab.
mcdavis...@netscape.net wrote: > For the sake of discussion, a couple other options:
> 1. Rather than sideways scrolling, apply a chevron on the right edge of > the browser tabs box when the box overflows, the same as is done now > with the personal bookmarks toolbar. Selecting the chevron would > present a menu of open tabs, or of tabs not visible within the browser > tabs box.
I would be much happier with this. I often use tabs in a "random access" manner: the one I want to get to isn't necessarily anywhere near the one I'm in currently. Being able to see all tabs at once is essential to this.
Also, it's a lot faster, and would be able to display more of the title of each tab than scrolling.
dolphinling wrote: > mcdavis...@netscape.net wrote: >> For the sake of discussion, a couple other options:
>> 1. Rather than sideways scrolling, apply a chevron on the right edge of >> the browser tabs box when the box overflows, the same as is done now >> with the personal bookmarks toolbar. Selecting the chevron would >> present a menu of open tabs, or of tabs not visible within the browser >> tabs box.
> I would be much happier with this. I often use tabs in a "random access" > manner: the one I want to get to isn't necessarily anywhere near the > one I'm in currently. Being able to see all tabs at once is essential to > this.
> Also, it's a lot faster, and would be able to display more of the title > of each tab than scrolling.
Personally, I'd prefer something more like IE7's setup, which has both the scrolling arrows and a menu button which lists all tabs.
Either way, I simply cannot use the current trunk implementation in Firefox. It shows less than half as many tabs in a given space as IE7, the arrow buttons are a lottery to actually hit, and mouse-wheel scrolling is so jerky and unpredictable it doesn't really help. :(
Bring on the regression fixes!
-- James Ross <sil...@warwickcompsoc.co.uk> ChatZilla Developer
> > I just landed the "tab scrolling" patch to the trunk, see bug #318168. > > In tomorrow's builds, you'll see a change to how we handle browser > > windows with "too many" tabs.
> Where was it decided that this was a good idea? What was the reasoning? > Were any studies done?
> ...Because I'm not liking it at all.
Neither am I.
All I see on the linked wiki page is the assertion from Mike Connor, "Regardless of the method selected, fixed width tabs are a big win." There doesn't seem to be much discussion in bug 318168, either. I strongly disagree that fixed width tabs are a win, big or otherwise. Having tabs scroll off is a usability nightmare that has been driving me nuts all weekend, since the change went in last week.
At the very least, the default minimum width should be about half what it is now. I am thankful that it can at least be configured via a hidden pref, but I urge y'all to reconsider the effect on an unskilled user of having tabs "disappear," vs. simply becoming smaller.
Gijs Kruitbosch ("Hannibal") wrote: > I'm afraid to ask this, but... can we pref this off? Completely, I mean?
I expect not, and nor should we be able to. The solution should either be good, and work, or a different solution should be used.
At the moment, however, I'm in the "this is a big usability regression" camp. It looks like some of the obvious issues are going to be addressed but I think there is a real issue that will remain - as soon as any overflow occurs the user has to hold all the state of their tabs in their head. If I'm on a tab and I want to find another tab I have to remember whether it's to the left or right of the currently visible set of tabs. Often I don't remember this and so there is a lot of frustrating tab-hunting. This immediately negates one of the biggest advantages of tabs - the fact that all the information I need to locate a page I have opened is instantly avaliable on the screen, so considerably reducing the amount of effort needed to locate open documents.
Hmm. The stuff on that page doesn't seem very well thought out.
Ben Goodger wrote on the page linked above:
> I have covered this in some detail mentally before and here are my notes:
> Given that the tabbed browser has these features: - drag and drop reordering - keyboard accessible navigation
> ... and that we want to try retain those even for overflowed tabs (dragging a tab back to the start of the set when it's at the end is occasionally useful):
> Chevron Menu Only (Safari) > --------------------------
> * When you select an item from the overflow menu, the indication of selected tab vanishes from the strip, which looks weird and gives no indication as to what is actually selected. > * D&D and keynav break, unless you want to implement various horrid hacks to show the popup menu and allow dragging/navigating into it, which almost certainly don't work on Mac.
No they don't. At least, our current Bookmarks Toolbar has this type of chevron, and drag and drop works fine for it. I don't know about keyboard navigation, but it certainly wouldn't be impossible.
> Chevron Menu with Scrolling Strip > ---------------------------------
> * When you select a tab from the menu, the strip is zoom-scrolled so that the tab is visible. This solves the "no visible selected tab in tab strip" issue that affects the plain Chevron Menu solution. However when the strip is scrolled the set of non-visible tabs changes. There may be more non-visible tabs to the right and now left of the strip, meaning two menus need be shown, perhaps at alternate ends of the tab strip. This sounds cumbersome.
Perhaps cumbersome, perhaps not. Since the order is preserved, a person might look to the beginning of the tab list, see that their tab has been pushed left and there's an arrow there, and click it. And if the buttons are big and visible (as they should be, not these tiny, 10px things we have now) and if the tab list visibly scrolls, in a pretty, OS X-type way to let them know where their tabs went, I doubt it would be a problem.
In any case, this idea should be simply dismissed out of hand. If testing shows it's bad, fine, but it certainly doesn't "seem cumbersome" to me.
> * D&D and keynav probably work in this case though.
Why would D&D and keynav work in this case but not the previous one?
> Chevron Menu with Tab Reordering (Visual Studio 2005) > -----------------------------------------------------
> * LIFO ordering on the strip, sense of insertion is inverted. New tabs appear at the start of the strip and older ones move to the right until they are eventually evicted into a menu. Selecting an item from the menu re-inserts the item at the start of the strip. I have been using VS2005 for over a month now and this is a disaster. The delicate order of tabs that some users have is not only not preserved, it is actively destroyed. They should have left it the way it was. > * Doesn't easily support D&D or keynav to non-visible items.
This does sound bad.
> Scrolling Strip (buttons) (Visual Studio 2003 and earlier) > ----------------------------------------------------------
> * Supports D&D and keynav while maintaining a single static piece of UI (scroll buttons) > * Setting the scroll speed correctly is likely to be a challenge. > * No instant way of getting to a hidden tab - speed of access relies on scrolling and dexterity
This last bit is, IMO, a killer (and from other people's comments, I think it is in their opinions, too). The sense of waiting, even if the scroll speed is _perfect_, is one thing I hate about computers. With a drop down menu that instantly shows everything, I'm at least doing something the whole time.
As a fifth option, how about taking the first option (drop down on right, no scrolling) and reserving the rightmost tab spot for the most recently selected tab from the menu. Order is preserved in the menu, and that spot is for display *only*, when I click on the menu again, the tabs should be just as they were the first time.
This would I think be a small improvement on option 1, in that the currently selected tab would always be visible and if switched away from (to one of the other visible tabs) it could easily be switched back to. I don't know if it would be confusing, though; I don't think it would to me, but then I thought it up so I'm a bad judge of that.
In any case, I think options 1, 2, or my 5 would all be better than the current one.
>>> I just landed the "tab scrolling" patch to the trunk, see bug #318168. >>> In tomorrow's builds, you'll see a change to how we handle browser >>> windows with "too many" tabs.
>> Where was it decided that this was a good idea? What was the reasoning? >> Were any studies done?
>> ...Because I'm not liking it at all.
> Neither am I.
> All I see on the linked wiki page is the assertion from Mike Connor, > "Regardless of the method selected, fixed width tabs are a big win." > There doesn't seem to be much discussion in bug 318168, either. I > strongly disagree that fixed width tabs are a win, big or otherwise. > Having tabs scroll off is a usability nightmare that has been driving > me nuts all weekend, since the change went in last week.
Having tabs reduced to stubs that cannot be read or accessed without finer motor control is equally painful. Fixed width tabs allow rapid closing without additional movement, but as I'm sure you can discover from the implementation and further discussion in this group, we don't have fixed width tabs in all cases, just minimum width designed to avoid having to remove background closebuttons. Based on usability testing, accidental tab closing jumped at 120px wide tabs, so it seems better to stay above that limit than the all/one toggle for closebuttons. Scrolling sucks at times, but so does hovering on tabs to read the title. There needs to be an additional element to address "I have a large number of tabs and I need to find the right one" but we don't have the right solution for that yet.
> At the very least, the default minimum width should be about half what > it is now. I am thankful that it can at least be configured via a > hidden pref, but I urge y'all to reconsider the effect on an unskilled > user of having tabs "disappear," vs. simply becoming smaller.
There reaches a point where things get too small though, at which point we need to overflow, so this isn't really somethign with a point.
|
