tab scrolling patch landed on the trunk
Seth Spitzer
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
> and drop on the Mac. [5]
Oops, I meant Mark Mentovai, aka mento.
-Seth
Adam Kowalczyk
> 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.
- Adam
Adam Kowalczyk
> 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.
- Adam
Seth Spitzer
> 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
Seth Spitzer
> 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)
-Seth
Martijn
>
>
> 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.
Regards,
Martijn
-Seth
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Seth Spitzer
>> 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
Thanks for pointing me to that related bug.
> 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
tjb
> 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.
dolphinling
> 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.
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.
--
dolphinling
<http://dolphinling.net/>
scratch
> 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.
>
> 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.
-scratch
Ricky Georgy
> 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.
Ricky
mcdav...@netscape.net
> 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.
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".
Nathaniel
the ideal solution, but certainly better than this one.
Omega X
everything. Give them a chance to flesh it out before you complain.
mcdav...@netscape.net
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.
kaze...@gmail.com
mcdav...@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.
dolphinling
> 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
<http://dolphinling.net/>
James Ross
It was one of the proposed ideas (see the list of stuff on
http://wiki.mozilla.org/Tabbed_Browsing/User_Interface_Design/Tab_Overflow).
I think the lack of D&D and keynav is what killed it, although I can see
both being overcome if you really tried.
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
mcdav...@netscape.net
James Ross wrote:
> It was one of the proposed ideas (see the list of stuff on
> http://wiki.mozilla.org/Tabbed_Browsing/User_Interface_Design/Tab_Overflow).
OK, so this has long since been thought through. That's what I
expected, and confirmation is good news.
Gijs Kruitbosch ("Hannibal")
-- Gijs
Will Rogers
> 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.
>
> 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.
Regards,
- Will
jg...@cam.ac.uk
> 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.
dolphinling
> http://wiki.mozilla.org/Tabbed_Browsing/User_Interface_Design/Tab_Overflow).
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.
--
dolphinling
<http://dolphinling.net/>
Mike Connor
> dolphinling wrote:
>
>> 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.
>>>
>> 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.
>
>
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.
-- Mike
mcdav...@netscape.net
When selecting from Tabs menu:
( ) scroll tabs to selected
( ) move selected tab only
Some other words might be needed instead of Tabs menu, depending on the
chosen UI, such as "Tabs Chevron", "Tabs Dropdown", "Tabs List" or
"Tabs Context Menu".
Will Rogers
> Having tabs reduced to stubs that cannot be read or accessed without
> finer motor control is equally painful.
That's a good point from an accessibility perspective, which is not
something I had really thought about.
> 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.
This is interesting. I don't really like having the close buttons on
each tab at all for exactly this reason, but that's a little off-topic
(and decided a while ago I believe).
Are the results/details of these usability studies public?
> 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.
Yes.
> Scrolling sucks at times, but so does hovering on tabs to read the
> title.
> [...]
> There reaches a point where things get too small though, at which point
> we need to overflow
I respectfully disagree on this point. I would much rather have tabs
continue to shrink until they are 20px wide rather than *ever* go
off-screen, via scrolling, chevron, or any other method. Which is why
having a pref is good.
Regardless, thanks for clearing some of that up... I at least
understand why it has been changed a little better. If some work goes
into making the scroll buttons more usable, the feature will not be
quite as bad. I just still have bad feelings about having tabs hidden
off-screen at all.
- Will
Mike Connor
the same effect, except in the cases in the old system where you
couldn't access the tab at all with the mouse. Setting it to 0 in
theory disables it completely, but I haven't tested that.
-- Mike
Adam Guthrie
>
> -- Gijs
Yeah. Setting both browser.tabs.tabClipWidth and
browser.tabs.tabMinWidth to 0 seems to work for me.
I also am enjoying the ability to disable close buttons on
tabs altogether via the browser.tabs.closeButtons pref:
From the code:
// modes for tabstrip
// 0 - activetab = close button on active tab only
// 1 - alltabs = close buttons on all tabs
// 2 - noclose = no close buttons at all
// 3 - closeatend = close button at the end of the tabstrip
- Adam
Adam Guthrie
Setting the pref. to 0 doesn't seems to completely disable
it -- the overflow solution seems to kick in when tabs are
around 7-10 pixels wide -- but I'm satisfied with that.
- Adam
tjb
> 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.
This seems to go on the idea that not many users are able to middle-click
tabs to close them. Does anyone have any data on this, out of interest?
<snip>
Just to add my opinion: I feel this is too limiting right now. I can get
only eight tabs up on this screen, 15" CRT @ 1024x768, even when maximised,
and that's almost unusable for me.
Thomas Stache
> This seems to go on the idea that not many users are able to middle-click
> tabs to close them. Does anyone have any data on this, out of interest?
>
A middle mouse button can not be taken for granted, it is not standard
on Windows.
Most notebooks with touchpads have no middle mouse button, and since the
market share of notebooks is constantly rising, this is something you
can't ignore.
On most desktop mouses the wheel is the middle mouse button, which is
way harder to press than the left and right buttons.
Generally usage of the middle mouse button is not common on Windows and
MacOS, making me think browsers should keep it to a minimum.
Thomas
kaze...@gmail.com
I middle click to close my tabs when I have a 3-button or click-wheel
mouse. I also think the most recent builds have default minimum tab
sizes that are too wide.
As far as the scrolling goes...I'd much rather see it implemented
similar to how the Windows taskbar handles an overflow of windows (when
"grouping" is turned off). It does this by first shrinking each window
button (which function a bit like tabs...) so they fit on the taskbar.
Once they can't shrink anymore (which is about the size of the older
minimum Firefox tab size), a miniature vertical scroll indicator shows
up on the right side. The scroll indicator varies in height according
to the taskbar's height, ranging from one tab-height to several (user
selected).
I couldn't find any screenshots of this design, but if you're running
Windows XP with the Classic theme and have grouping turned off (it is a
taskbar property), just open a bunch of windows. A multitude of PuTTY
terminals works great.
I think this style patterned after the Windows taskbar (without
grouping) is the best of the taskbar overflow options, better than the
older FX 1.5 design, and significantly better than the these very wide
tabs in the current FX 2.0a3 builds.
Martijn
Thanks for the explanation.
Another thing, I see you already have taken care of dragover behavior.
There is a patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=240709 that accomplishes
the same in a more generic way (for all scrollboxes).
There is a small difference in behavior between your patch and the
patch in bug 240709, btw.
With your patch, when you keep moving (while dragging over the
autorepeatbutton) over the autorepeatbutton, the scrolling goes
faster, with the patch in bug 240709, it keeps scrolling at a constant
speed (at least that's how it was when I last checked this, iirc).
Regards,
Martijn
On 6/29/06, Seth Spitzer <sspi...@mozilla.com> wrote:
> Martijn,
> >> 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
>
> Thanks for pointing me to that related bug.
>
> > 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
>
gri...@gmail.com
english is not my primary language, but this implementation of fixed
sized tabs are annoying me, I like the old way, and when the tabs were
very small that's why I had the tab preview extension.
but since it looks like you guys are going with this implementation,
the thing that most annoys me is that you cannot know where in the tab
bar you are since you start to scroll it ( open a lot of new tabs and
you have no reference at all )
So I just modified this screen shot, to show a solution I think will
help to prevent the user to lost his position on the tab bar.
Check out
http://www.grillo.tk/images/firefox_newtab_idea.gif
The user will have something like a scrollbar underneath the tabs, well
if you want to add a scrollbar it's ok too, but I thing it's too big
for that space ( and ugly ).
I hope you like mine idea.
Grillo
Mike Shaver
>
> 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.
I am not able to drag from a dropdown (as with a bookmark folder) to
the bookmarks toolbar, nor the other way, using Bon Echo Alpha 3 on
the Mac. Is there a trick I'm missing?
Mike
dolphinling
On trunk linux, I see the following:
From elsewhere to Bookmarks Toolbar (BT): works
From BT to BT: works
From BT dropdown (DD) to BT: works
From DD to DD: works, but buggy (dropdown reopens w/ full contents of
BT, filed as bug 343582)
From BT to DD: fails, menu never opens so there's nowhere to drag to
From elsewhere to DD: fails, menu never opens
I thought these last two worked, so either it's a recent regression or
my memory's bad. In any case, it seems to me that all that's needed is
for the menu to open, and everything else is already implemented.
--
dolphinling
<http://dolphinling.net/>
dolphinling
believe that all that needs to happen is for the chevron dropdown at the
end to open when dragged over.
--
dolphinling
<http://dolphinling.net/>
Nathaniel
never said TabMix was a solution for everything, and I never once
complained. I am trying to HELP by pointing out a possible solution
that I consider better than the current one. I can see no words in my
previous statement that would suggest a tone of 'complaint.' Please
correct me if I am wrong, and I will change my language accordingly.
Nathaniel
> Having tabs reduced to stubs that cannot be read or accessed without
> finer motor control is equally painful.
this as an argument - unless you have different sensitivity settings
for vertical as opposed to horizontal movement (which to me is very
confusing). Even so, I have my mouse on ultra-high sensitivity only
brought by a 800dpi logitech mouse, and I have no trouble correctly
selecting from a full 30 or so tabs on one window. In fact, I always
select the RIGHT tab, because I either A: remember where the tab was B:
Recognize the icon or C: Remember which tab it is because of it's
location AND icon. Having to scroll, even without hold-down is beyond
painful - I cannot instantly navigate from tab to tab (defeating the
purpose of tabs), instead I have to move my mouse way over, then click,
click, click, click, oh wait, back there, click click click. By that
time, I might have forgotten what I was going to do on that tab.
Ok, so maybe having 30 tabs on one window is a little extreme, and
might be considered only usable by extreme users. In that case, why are
we concerned about non-extreme users with 30 tabs open? Have extreme
UI, for extreme users.
> 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.
that's why I picked up using the middle button for tab closing, that
completely eradicates that issue.
> 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.
tabs you don't want to if you can't navigate to those tabs reasonably
in the first place?
> 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.
helpful. If I can quickly (one click) switch to a tab, I can determine
almost instantly if it is the one I wanted - after all I just saw the
page, which is easier to recognize than a title I often skim over. In
that regard, if you really want a feature for people who don't want to
'experiment', read icons, or just remember their tab placement, yet for
some reason have 30 tabs open, you might try incorporated some kind of
'expose' feature. (Like the FF extension that won the contest, or IE's
"tab view," or even the original Mac feature.)
> There reaches a point where things get too small though, at which point
I think the level it was at before was fairly good, it kept each tab at
a size larger than the close button, and I believe it was more
disproportionate than the golden ratio (I believe getting below that
ratio would be a mistake). However, I think at that point, something
understandable should happen - nothing should 'disappear', because that
confuses users and certainly makes usability suddenly 'disappear' also.
Maybe the tabs should 'overflow' onto a new tab line - after all users
going to this extreme shouldn't mind a little more of their space taken
up. Or if you really don't like that idea, instead of making the tabs
disappear to be scrolled to, maybe they could 'shrink' instead.
SHRINK:
A few tabs would display as normal, just like they do when you have
scrolling. In this case, the tabs on the right or left of this 'normal
view' would be little columns that might, or might not have their
favicon displayed. To be able to determine if you wanted to select
them, the user could scroll their mouse over in that direction,
effectively 'blowing them up' to a normal, readable size. This would
operate similarly to the scrolling UI in that a user would have to
transition the tabs they wanted to view, but instead of hiding them and
making it impossible to know what is their, a little indication is
given. Also, the mouse over effects allows for quick determination of
content (of the tabs) but at the same time, allows advanced users with
memorized locations (and possibly dexterity) to quickly select the tabs
they want to view. In essence, everyone wins.
After coming up with this idea, it really seems like the best solution
to me. So please, if you have any concerns or want to understand more
about the SHRINK tab effect, please ask.
>
> -- Mike
Really the main problem here, is not really 'what's good for the
average user', but the fact that I can't set it to be anywhere near
usable for my needs. I tried looking in about:config for tab options,
and found nothing to the effect of saving myself.
mcdav...@netscape.net
...
>
> Really the main problem here, is not really 'what's good for the
> average user', but the fact that I can't set it to be anywhere near
> usable for my needs. I tried looking in about:config for tab options,
> and found nothing to the effect of saving myself.
You're making some really good points here. We do want to make sure
that power users don't get locked out of browsing the way they want to.
Still, I would say it *does* make sense to design for the average user
... we just need to make sure that power users can customize with
preferences and extensions.
I mean, Firefox could be designed as a niche browser for power users
only, but I don't think that's what Firefox is about. So that raises
the question: how do the architects of Firefox conceive of the average
user? Is there a user characterization statement somewhere? Who are
the people that tab scrolling is the right UI for, and are there enough
of them that it makes sense for it to be the default?
d...@design-noir.de
> You're making some really good points here. We do want to make sure
> that power users don't get locked out of browsing the way they want to.
> Still, I would say it *does* make sense to design for the average user
Sure, but don't miss the point that the average user hardly opens so
many tabs that squeezing them could harm him. Even with 20 tabs at
1024x768 titles are good for guessing. By the way, the default icon is
obstructive here (what's its use anyway?).
On the other hand, scrolling (as it is) is harmful as soon as it
appears (9+ tabs?) -- maybe more than ever for novices.
> ... we just need to make sure that power users can customize with
> preferences and extensions.
It has be usable by default.
Omega X
won't understand anyway. A possible solution shouldn't be suggested if
its not much better than the original. That's just a waste of time.
Myk Melez
> Having tabs reduced to stubs that cannot be read or accessed without
> finer motor control is equally painful.
...
> 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.
I suspect that users who navigate tabs via keyboard shortcuts will have
a different experience of the change from those who navigate via the
mouse, since keyboard shortcuts don't require fine motor control and let
you rapidly cycle through tabs, minimizing the cost of unreadably small
tab labels.
My personal usage pattern, which may or may not be representative of
keyboard shortcut users generally, is to rapidly cycle through tabs by
repeatedly pressing ctrl-PageUp/PageDown when looking for a specific tab.
More specifically, since I usually know about where the tab is, I
usually "jump" to that area with repeated keyboard shortcuts and then
search the area more carefully. But I need to see where I'm going to
jump there, so tab scrolling makes it impossible.
Nevertheless, I'm going to continue to test tab scrolling to see whether
it really does represent a decrease in usability for me or if I just
need to adjust to the new behavior.
As Mike pointed out, there are probably more things we can do to make it
easier to find one out of a sea of tabs, with or without tab scrolling.
Perhaps using tab scrolling will give me some insight into a better
solution than my current jump-and-search technique.
-myk
Pam Greene
(webmail or a search-result page, for example) and a bunch of tabs
that would be fine scrolling. What if we allowed users to drag one or
both scroll buttons into the tab bar to adjust the ends of the
scrolling section? Something like a spreadsheet's window split is
what I have in mind, only the areas outside the scroll range would be
fixed rather than having separate scroll arrows.
Probably too late for FF2, but it's a thought for FF3, anyway.
- Pam
On 6/28/06, Seth Spitzer <sspi...@mozilla.com> wrote:
> 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)
>
> -Seth
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Stebs
really like to see:
Currently with the new patch, when hovering above the tab strip, you can
scroll the tab strip with the Mouse Wheel just the same way you can do
it with the new chevrons.
How about changing this to really scroll the Tabs with the mouse wheel
and not only the tab strip -so with the wheel you can go quickly through
all the Tabs (with the tab strip following scrolling when you reach the
last visible Tab on the left or right).
That way, you can still use both ways (mouse wheel or chevrons) to get
to an Tab that is currently not visible on tab strip, and you also gain
the new functionality for easy and very quick cycling between Tabs.
Currently only (overloaded) TabMixPlus Extension is able to activate
this and once you are used to it, you don't want to miss it.
It's simply perfect for quick inspection or comparison of different Tabs
without the need to move the mouse or do some clicks, simply by turning
the mouse-wheel (but naturally only if mouse hovers over tab strip).
And if not enabled by default, perhaps this could be some new hidden
pref.?
mcdav...@netscape.net
> 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.
>
> 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.
>
> ...
The latest Bon Echo nightly has a 16by16 dropdown menu button on the
extreme right edge of the tab bar which, when clicked, shows a menu of
open tabs. I think this is a great choice (I previously voted for a
chevron having the same behavior, but this works just as well for me)
and does wonders to improve the functionality of the tab bar. Cheers
to the developement team!
My one thought is that maybe the dropdown marker should overlay the
button image, the same way the marker overlays the "Google" icon in the
search box with Fx1.5.0.4, just to save a few pixels. Or maybe not,
since it's not done that way anywhere else in the UI, and the searchbar
doesn't even work that way any more with Bon Echo. Something to
consider.
Anyway, very nice work!