Tabbed Browser: Gracefully handling tab overflow
Tim
Read the commentary (and responses from Mozilla/Netscape UI people) in those bugs and continue the discussion here, if you wish. Once some agreement has been reached and a reasonable design has been written (and preferably has been reviewed by a Moz/NS UI guru), post it to bug 155325.
Soeren Nils Kuklau
The chevron solution is the right one. All overflowing tabs are put in a
submenu.
--
Sören Nils Kuklau ('Chucker')
mailto:chu...@web.de
Sailfish
I'd opt for adding another tab-row on overflow. I mean, really! How many
tabbed pages is someone likely to create where adding extra rows will
present a problem?
I might add, the Personal Toolbar suffers from the same problem, fwiw...
--
Best Regards,
Pat
"Surfin' the Net...grappling with the 3rd Wave"
Got a message? Project It!? http://www.projectit.com/
Soeren Nils Kuklau
> I'd opt for adding another tab-row on overflow. I mean, really! How many
> tabbed pages is someone likely to create where adding extra rows will
> present a problem?
Yeah, that's why I find the discussion in that bug about "Problems with
over 80 open tabs" kinda stupid. Honestly, if you have so many tabs open
in one window, I really wonder what UI anyone could invent to sort them
(except that "sorted-by-site-tabs" idea, which is a no-no).
> I might add, the Personal Toolbar suffers from the same problem, fwiw...
Yes, and in that case, IE's solution is chevrons...
Sailfish
>> I might add, the Personal Toolbar suffers from the same problem, fwiw...
>
>
> Yes, and in that case, IE's solution is chevrons...
>
Yeah, its one of the minor reasons I don't use IE. The Chevron approach
requires too much work. Every time I want to view an "overflowed" item,
I have to click the chevron and then scroll the list. Plus, depending on
where the "Close" button would be positioned, this could be a cause for
irritation, i.e., clicking "close" when they really wanted "chevron"?
Lastly, something to consider is how Windows handles overflow with the
taskbar, i.e., it presents a vertical scroll that scrolls one row of
tasks at a time and also allows one to expand the row (drag) to include
multi-row tasks?
Chris Goldie
Soeren Nils Kuklau
> Soeren Nils Kuklau wrote:
>>> I might add, the Personal Toolbar suffers from the same problem, fwiw...
>> Yes, and in that case, IE's solution is chevrons...
> Yeah, its one of the minor reasons I don't use IE. The Chevron approach
> requires too much work. Every time I want to view an "overflowed" item,
> I have to click the chevron and then scroll the list. Plus, depending on
> where the "Close" button would be positioned, this could be a cause for
> irritation, i.e., clicking "close" when they really wanted "chevron"?
The Close button should be right of the chevron menu.
There are four solutions to toolbar / menubar / tabbar overflow:
1. multiple lines
Very messy cause it takes up a lot of space and confuses the user
(especially with 3+ lines).
2. scrollers on the left and right
Even worse cause it takes ages to get where you want to get to
3. chevrons
Not the most beautiful approach, but you get where you want to a lot faster
4. hide the overflow
No comment. It's what we're doing at the moment.
> Lastly, something to consider is how Windows handles overflow with the
> taskbar, i.e.,
It makes all items way too small. And when there's no other way out, it
creates... you guessed right, a chevron.
> it presents a vertical scroll that scrolls one row of
> tasks at a time and also allows one to expand the row (drag) to include
> multi-row tasks?
The scrollers might have been in Windows 95, but they are no longer
there in my version.
Jason Bassford
> tabbed pages is someone likely to create where adding extra rows will
> present a problem?
I know of at least one real world example where the person frequently
has over 100 tabs open. They browse to a bookmark group, then also
open other tabs, each one on a bug they follow that has changed. In
such a case, tab rows would not be beneficial given the quantity of
tabs here.
Jason Bassford
> over 80 open tabs" kinda stupid. Honestly, if you have so many tabs open
> in one window, I really wonder what UI anyone could invent to sort them
I agree - as I've said in that bug. Once you're dealing with that
number of tabs (and there are people who actually do, so this is not
theoretical), it's more a matter of just getting to them in general
than actually trying to find a specific one. (Nobody could possibly
remember the titles of 100+ tabs, but they MIGHT remember where in
general (towards the end of the list, etc.) a particular one might be
located.
Pratik
>Tim wrote:
>
>
>>This is a continuation of
>>http://bugzilla.mozilla.org/show_bug.cgi?id=155325 (which was a
>>continuation of http://bugzilla.mozilla.org/show_bug.cgi?id=106927).
>>Both bugs discuss ways to handle what to do when too many tabs are
>>opened to fit on the screen.
>>
>>Read the commentary (and responses from Mozilla/Netscape UI people) in
>>those bugs and continue the discussion here, if you wish. Once some
>>agreement has been reached and a reasonable design has been written (and
>>preferably has been reviewed by a Moz/NS UI guru), post it to bug 155325.
>>
>>
>>
>
>I'd opt for adding another tab-row on overflow. I mean, really! How many
>tabbed pages is someone likely to create where adding extra rows will
>present a problem?
>
>
If you add another tab row what should happen when you run out of
horizontal space? It's possible for that to happen. Chevrons are much
metter because they can handle an infinite number of tabs. Just have
them scroll like the bookmarks do.
Pratik.
Soeren Nils Kuklau
I usually sort tabs using several windows, so I have one window with the
bookmarks group "mozilla blogs" containing 10+ tabs, one window with
other stuff, one window with news, ... I prefer that method by far over
having one window with lots of tabs. I also think it's more performant.
Sailfish
> There are four solutions to toolbar / menubar / tabbar overflow:
>
> 1. multiple lines
> Very messy cause it takes up a lot of space and confuses the user
> (especially with 3+ lines).
As I suggested before, any user that ends up having more than two line
of tabs is already in a high state of confusion, imo.
> 2. scrollers on the left and right
> Even worse cause it takes ages to get where you want to get to
Agreed.
> 3. chevrons
> Not the most beautiful approach, but you get where you want to a lot faster
Not as fast as approach 1.
> 4. hide the overflow
> No comment. It's what we're doing at the moment.
Agreed.
>> Lastly, something to consider is how Windows handles overflow with the
>> taskbar, i.e.,
>
>
> It makes all items way too small. And when there's no other way out, it
> creates... you guessed right, a chevron.
Not on my sys, Win98SE, unless you're referring to the Quick Launch feature?
>> it presents a vertical scroll that scrolls one row of tasks at a time
>> and also allows one to expand the row (drag) to include multi-row tasks?
>
>
> The scrollers might have been in Windows 95, but they are no longer
> there in my version.
As I mentioned, I'm using Win98SE and the scrollbar is there.
Garoo
news:ah634v$pq...@ripley.netscape.com:
>> it presents a vertical scroll that scrolls one row of
>> tasks at a time and also allows one to expand the row (drag) to
>> include multi-row tasks?
>
> The scrollers might have been in Windows 95, but they are no longer
> there in my version.
I have Win2K and I'm pretty sure I saw a scrollbar there recently.
I think it's the best idea: by default, there's a vertical scrollbar, that
allows you to access to another row of tabs. It's not exceptionally usable,
but it's more elegant than the tabs just disappearing.
Then there's the option to resize the tabs area, to allow for a user-chosen
maximum number of rows (that should be remembered between sessions) and
users who regularly need two or three rows can use them.
I guess users who have a hundred tabs don't expect to have a simple way to
switch from one to the other: they just read one and close it and get to
the next. So they will be ok with the scrollbar, which would allow them to
hunt for a specific tab if they needed it.
And users who commonly use 15 or 20 tabs or whatever the current max number
of tabs, will be able to set the tab bar to 2 or 3 rows and have it
completely usable.
(The resizable tab bar is not incompatible with the chevron menu, but I do
feel it's more logical this way: you see a scrollbar on the side, then
expect the area to be resizable, and, voilà, it is.)
--
[ www.garoo.net ]
Soeren Nils Kuklau
> Soeren Nils Kuklau wrote:
>> It makes all items way too small. And when there's no other way out,
>> it creates... you guessed right, a chevron.
> Not on my sys, Win98SE, unless you're referring to the Quick Launch
> feature?
I was confusing the way it works with Quick Launch with the way it works
on the rest of the Taskbar - and just by the way: It's very, very bad UI
design to have them behave differently. It's for historical reasons
though: the "normal" taskbar is still the one from Windows 95 with few
changes, whereas the quick launch bar (and the option for additional
adjacent bars) was added. Those newer bars use chevrons.
>>> it presents a vertical scroll that scrolls one row of tasks at a time
>>> and also allows one to expand the row (drag) to include multi-row tasks?
>> The scrollers might have been in Windows 95, but they are no longer
>> there in my version.
> As I mentioned, I'm using Win98SE and the scrollbar is there.
I misread your post; I thought I had read "horizontal scroll" instead of
a vertical one. Yes, I've seen vertical scrollers as well in the task bar.
Soeren Nils Kuklau
> I have Win2K and I'm pretty sure I saw a scrollbar there recently.
A vertical one, yes. Sorry (see other post).
> I think it's the best idea: by default, there's a vertical scrollbar, that
> allows you to access to another row of tabs. It's not exceptionally usable,
> but it's more elegant than the tabs just disappearing.
I don't consider it elegant at all, sorry. Good luck at finding tab xy
in such a mess.
> Then there's the option to resize the tabs area, to allow for a user-chosen
> maximum number of rows (that should be remembered between sessions) and
> users who regularly need two or three rows can use them.
Oh nonono. Not another *option*. Nobody will approve that.
> I guess users who have a hundred tabs don't expect to have a simple way to
> switch from one to the other: they just read one and close it and get to
> the next. So they will be ok with the scrollbar, which would allow them to
> hunt for a specific tab if they needed it.
Why wouldn't they be just as ok with chevrons?
> And users who commonly use 15 or 20 tabs or whatever the current max number
> of tabs, will be able to set the tab bar to 2 or 3 rows and have it
> completely usable.
Why would they want to have additional rows?
> (The resizable tab bar is not incompatible with the chevron menu, but I do
> feel it's more logical this way: you see a scrollbar on the side, then
> expect the area to be resizable, and, voilą, it is.)
The problem is that mpt will point you to a site explaining why the
multiple row idea and the scroller idea both suck, and why the chevron
idea rules. Whether it's right or not, it's the way it works at the moment.
Sailfish
> On 7/18/2002 7:48 PM, Sailfish apparently wrote exactly the following:
>
>> Soeren Nils Kuklau wrote:
>
>
>>> It makes all items way too small. And when there's no other way out,
>>> it creates... you guessed right, a chevron.
>>
>
>> Not on my sys, Win98SE, unless you're referring to the Quick Launch
>> feature?
>
>
> I was confusing the way it works with Quick Launch with the way it works
> on the rest of the Taskbar - and just by the way: It's very, very bad UI
> design to have them behave differently. It's for historical reasons
> though: the "normal" taskbar is still the one from Windows 95 with few
> changes, whereas the quick launch bar (and the option for additional
> adjacent bars) was added. Those newer bars use chevrons.
I don't disagree. I believe their decision to add Quick Launch to the
taskbar was a wrong one, too much stuff cluttering the taskbar what with
Start, tasks and the tray there already (As an aside, KDE suffers from
this taskbar bloat even more, imo.) As such, I've limited my quick
launch items to just four (no chevron) and use a freeware Quick Launch
toolbar (positioned as auto-hide at top of display) for my quick launch
activity.
Be that as it may, assuming tabs are left for tabs only, then my opinion
is that multi-line tabs is still a better/quicker way to go.
Sailfish
> The problem is that mpt will point you to a site explaining why the
> multiple row idea and the scroller idea both suck, and why the chevron
> idea rules. Whether it's right or not, it's the way it works at the moment.
>
Hmmm, that sounds oddly like the decision has already been made to use
the funky chevrons, one is left to wonder why this thread was even
started, no?
Lastly, what "sucks" to one is "simple elegance" to others, what can I say?
Soeren Nils Kuklau
> Hmmm, that sounds oddly like the decision has already been made to use
> the funky chevrons,
Not quite. It's what the UI team has decided, and now all those against
it need is good (very good) arguments against it.
> one is left to wonder why this thread was even started, no?
I didn't start it.
> Lastly, what "sucks" to one is "simple elegance" to others, what can I say?
Definitly. I was just citing mpt.
Soeren Nils Kuklau
> I don't disagree. I believe their decision to add Quick Launch to the
> taskbar was a wrong one, too much stuff cluttering the taskbar what with
> Start, tasks and the tray there already (As an aside, KDE suffers from
> this taskbar bloat even more, imo.) As such, I've limited my quick
> launch items to just four (no chevron) and use a freeware Quick Launch
> toolbar (positioned as auto-hide at top of display) for my quick launch
> activity.
I'm using geOShell instead at the moment. Uses a lot less resources and
is quite convenient.
> Be that as it may, assuming tabs are left for tabs only, then my opinion
> is that multi-line tabs is still a better/quicker way to go.
Ask mpt to join this discussion.
Sailfish
>> Lastly, what "sucks" to one is "simple elegance" to others, what can I
>> say?
>
>
> Definitly. I was just citing mpt.
mpt monitors the newsgroup so I suspect he'll enter the frey if he gets
interested enough.
It is a little ironic, though. mpt was a co-author of a futuristic
toolbar design which (you guessed it) proposed to add a bunch of
toolbars to Mozilla. No cheverons in that design, that I noted? :-)
Sailfish
> I'm using geOShell instead at the moment. Uses a lot less resources and
> is quite convenient.
fwiw (and admittedly, off-topic) I'm using PowerPro, available here:
http://www.windowspowerpro.com/
Its about as full-featured launcher/Windows UI configurator that you'll
likely find. Word of caution, its a flexible/complex program, not
recommended for the technically-challenged....
Soeren Nils Kuklau
> It is a little ironic, though. mpt was a co-author of a futuristic
> toolbar design which (you guessed it) proposed to add a bunch of
> toolbars to Mozilla.
Are you talking about his infamous "Navigator chrome overview" spec from
January?
> No cheverons in that design, that I noted? :-)
In *that* spec, there are.
Soeren Nils Kuklau
> fwiw (and admittedly, off-topic) I'm using PowerPro, available here:
>
> http://www.windowspowerpro.com/
>
> Its about as full-featured launcher/Windows UI configurator that you'll
> likely find. Word of caution, its a flexible/complex program, not
> recommended for the technically-challenged....
From the screenshots in the tour, it was last updated in 1996.
Sailfish
> On 7/18/2002 9:55 PM, Sailfish apparently wrote exactly the following:
>
>> fwiw (and admittedly, off-topic) I'm using PowerPro, available here:
>>
>> http://www.windowspowerpro.com/
>>
>> Its about as full-featured launcher/Windows UI configurator that
>> you'll likely find. Word of caution, its a flexible/complex program,
>> not recommended for the technically-challenged....
>
>
> From the screenshots in the tour, it was last updated in 1996.
>
Screenshots are misleading. It was last updated Apr. 2002.
Sailfish
>> No cheverons in that design, that I noted? :-)
>
>
> In *that* spec, there are.
>
Yes. I was a bit sloppy in my reference. I was suggesting that the
proposal specified adding more toolbars for new items rather than
expanding existing toolbars using the chevron.
Garoo
>> I think it's the best idea: by default, there's a vertical scrollbar,
> I don't consider it elegant at all, sorry. Good luck at finding tab xy
> in such a mess.
Well, if there are so many tabs that they wouldn't fit on a couple of
rows, they won't be easy to find either in a long menu. Besides, a
vertical scroll can be as long as you like, but a chevron's menu can only
be as high as the screen.
Considering someone mentioned a user who bookmarks a hundred bugzilla
tabs, how usable will his chevron menu be? Will it be a screen-high menu,
with a "more" option at the end, and a "more" option at the end of the
next, etc? Or will be a (yuck) scrollable menu? Either way, it's not much
better than the scrollbar.
And, though it makes sense to have a scrollbar appear when there's too
much contents, it looks weird to add a button. Didn't mpt write about the
fact that having a Close button appear on the tab-bar when there are
several tabs looks awkward? Then how having a chevron appear, right next
to the close button, a good idea?
>> Then there's the option to resize the tabs area
> Oh nonono. Not another *option*. Nobody will approve that.
I didn't say "option" as in "configuration option".
I mean, it's not an "option", unless you consider the possibility to
resize your browser window as an option.
The idea is just that there's a big border between the tabs and the
contents, and this border looks pretty much like a resizable border, so
it might as well be resizable.
>> I guess users who have a hundred tabs don't expect to have a simple
>> way to switch from one to the other: they just read one and close it
>> and get to the next. So they will be ok with the scrollbar, which
>> would allow them to hunt for a specific tab if they needed it.
>
> Why wouldn't they be just as ok with chevrons?
I feel that an chevron is more distracting, more cluttering, than a
scrollbar.
We see scrollbars everywhere - so much that we don't even see them.
However, a chevron is completely different. It's the addition of a new
button, and the need to memorize a new behavior (it might be logical for
Windows users, but not necessarily for other system users, unlike
scrollbars).
>> And users who commonly use 15 or 20 tabs or whatever the current max
>> number of tabs, will be able to set the tab bar to 2 or 3 rows and
>> have it completely usable.
>
> Why would they want to have additional rows?
Because if I found that I routinely used 10 tabs, and my Mozilla tab bar
could only display 8, I would be likely to want to resize the tab bar.
Just like I resized the Windows taskbar to two lines because there wasn't
enough room for my daily use.
--
[ www.garoo.net ]
Soeren Nils Kuklau
> Soeren Nils Kuklau <chu...@web.de> wrote in
> news:ah726k$u...@ripley.netscape.com:
>>>I think it's the best idea: by default, there's a vertical scrollbar,
>>I don't consider it elegant at all, sorry. Good luck at finding tab xy
>>in such a mess.
> Well, if there are so many tabs that they wouldn't fit on a couple of
> rows, they won't be easy to find either in a long menu. Besides, a
> vertical scroll can be as long as you like, but a chevron's menu can only
> be as high as the screen.
But a menu always has scrollers (except few menus on Windows that are
multi-row, which is only confusing). So a chevron's menu is still infinite.
> Considering someone mentioned a user who bookmarks a hundred bugzilla
> tabs, how usable will his chevron menu be? Will it be a screen-high menu,
> with a "more" option at the end, and a "more" option at the end of the
> next, etc? Or will be a (yuck) scrollable menu?
It will be a scrollable menu, because that's the typical way.
> Either way, it's not much
> better than the scrollbar.
Please distinguish between scrollbars (which will never happen for the
tabbar) and scrollers (which might be considered).
The scrollbar would take way too much place and just look ugly and
non-suiting. The scrollers don't have these flaws, but another one: They
always only scroll one item per click.
Scrollers in a menu don't have this flaw because you can hold down the
mouse button - or in some implementations just hover over them, and
they'll still scroll.
> And, though it makes sense to have a scrollbar appear when there's too
> much contents,
That's your claim, and not the general consensus. I believe it's very,
very ugly.
> it looks weird to add a button.
A lot less weird than a scrollbar.
> Didn't mpt write about the
> fact that having a Close button appear on the tab-bar when there are
> several tabs looks awkward? Then how having a chevron appear, right next
> to the close button, a good idea?
The close button issue is about the difference between "close window"
and "close tab", which is very confusing both for the newbie and for the
"geek". Apparently, many people from both groups accidentally click
"Close Window" when they actually only want the current page (which
often is only the current tab) closed.
That's why this is awkward; that's also why the whole tabbrowser is
awkward (and yet, despite mpt's claims, very convenient for many people,
including myself).
>>>Then there's the option to resize the tabs area
>>Oh nonono. Not another *option*. Nobody will approve that.
> I didn't say "option" as in "configuration option".
> I mean, it's not an "option", unless you consider the possibility to
> resize your browser window as an option.
Okay.
> The idea is just that there's a big border between the tabs and the
> contents, and this border looks pretty much like a resizable border, so
> it might as well be resizable.
*I* consider that a messy idea. Looking at this message compose window,
it does something quite similar though. So others might have other
opinions at this - like you.
>>Why wouldn't they be just as ok with chevrons?
> I feel that an chevron is more distracting, more cluttering, than a
> scrollbar.
I don't :-)
> We see scrollbars everywhere - so much that we don't even see them.
They're usually scrolling window contents. Most users expect them to do
that; just that.
> However, a chevron is completely different. It's the addition of a new
> button, and the need to memorize a new behavior (it might be logical for
> Windows users, but not necessarily for other system users, unlike
> scrollbars).
Can you draw an ASCII graphic or even better a real image of how this is
supposed to look like?
> Because if I found that I routinely used 10 tabs, and my Mozilla tab bar
> could only display 8, I would be likely to want to resize the tab bar.
> Just like I resized the Windows taskbar to two lines because there wasn't
> enough room for my daily use.
Point taken. This might be a solution for a lot of users. I doubt this
will be implemented though.
Chris Lee
A button that allows you to toggle through all populated tab bars.
That is if you have filled 5 tool bars with tabs you click the button a few times and move to the tab you want to work with.
The button has the tab bar number on it so that you know which bar you are on and which bar to go to to work with a specific tab.
Chris Lee
Then under 'window' you could have 'tabs' arranged under 'tab bars'so that a window with overflowed tab bars could have multiple 'tab bars' accesible through the tree:
+--Mozilla.org
---Google Search: Rocket Science
|
+--Tab bar 1
|--Tab bar 2
|
|--Rocket Science Group: Tech...
|--Rocket Science
|--the Rocket Science tm Bundle
+--Netscape.com
Jason Bassford
> bookmarks group "mozilla blogs" containing 10+ tabs, one window with
That's how I do it too. Although, I have to admit that there have
been times when I've had a ton of tabs open. I've also done the thing
where I look at the daily Mozilla bugs and open a new tab for each of
them. By the end of the day this number can be quite large - large
enough to cause overflow. In such a case there's little point in
opening another window for sorting purposes since there's no
distinuguishing one set of tabs from another, expect for an arbitrary
"number" which I don't go by.
Jason Bassford
> non-suiting. The scrollers don't have these flaws, but another one:
> They always only scroll one item per click.
Scrollers? I never once thought we'd be implementing scrollers. I'd
never be able to stand the one item per click thing. If we're talking
about 80+ tabs there'd be no point to a scoller at all - it would be
next to useless. (There's no way anybody could easily navigate
towards the end of the list.)
No, between the two a proper scollbar would be the only way to do it.
I don't believe it's the case that it would take up too much space.
You can make a scrollbar as big or as small as you like, and you can
also implement the UI for it in a lot of different ways.
Jason Bassford
> horizontal space?
A possible answer to this (note, I'm not necessarily recommending it)
would be to put the tab bar into a vertically scrollable, and perhaps
resizable, view menu. However many rows it showed by default, you
could scroll up and down to bring next / previous tab rows into view.
If it were resizable also, the individual could adjust its vertical
height to suit their browsing preference.
Neil
> This is a continuation of
> http://bugzilla.mozilla.org/show_bug.cgi?id=155325 (which was a
> continuation of http://bugzilla.mozilla.org/show_bug.cgi?id=106927).
> Both bugs discuss ways to handle what to do when too many tabs are
> opened to fit on the screen.
>
> Read the commentary (and responses from Mozilla/Netscape UI people) in
> those bugs and continue the discussion here, if you wish. Once some
> agreement has been reached and a reasonable design has been written
> (and preferably has been reviewed by a Moz/NS UI guru), post it to bug
> 155325.
In case it merits consideration, the easiest implementations (in order)
appear to be as follows:
1) Scrap tabs, use a menulist instead
2) Add a menubutton (or add a menu to an existing button, e.g. the + button)
3) Add scrollers (à la menus but horizontal)
4) Multiple lines
--
Warning: May contain traces of nuts.
Garoo
> But a menu always has scrollers (except few menus on Windows that are
> multi-row, which is only confusing). So a chevron's menu is still
> infinite.
Ok. I don't like scrolling menus at all, but maybe it's just me, I haven't
got precise arguments for that :)
> Please distinguish between scrollbars (which will never happen for the
> tabbar) and scrollers (which might be considered).
I'm not sure what you call a scroller exactly.
But I'm not talking about a horizontal scrollbar, in any case. But a
vertical one, to cycle through tab rows.
In a one-line tab bar, there would be no scrollbar per se but only scroll
buttons, so if that's what you're calling scroller, ok. But, in a multiline
tab bar setting, there would be room for the scrollbar between the up/down
buttons.
>> it looks weird to add a button.
> A lot less weird than a scrollbar.
:)))
I guess we're getting at personal preferences there :o))
Anyway, the part I'm arguing for more strongly is not scroll/chevron, but
the multiline tab bar :)
> Can you draw an ASCII graphic or even better a real image of how this
> is supposed to look like?
Um, what? The multiline tab bar? If you're on Windows, you probably have
one on the display properties box, for instance. Only that it's not
resizable, because you're unlikely to need 100 tabs there.
The idea would be that a single-row tab bar:
/==\/==\/==\/==\/==\/==\/==\/==\/==\/==\/==\/==\ x
Could be resized, by dragging the bottom border, and translate to:
/====\/====\/====\/====\/====\ x
/====\/====\/====\/====\/====\/====\/====\
Actually, the Windows display properties does this, but I find it awkward:
/=======\/======\/=======\/======\/======\
/====\/====\/====\/====\/====\/====\/====\
And, with the scrollbar, that would be something like :
/====\/====\/====\/====\/====\/====\/====\ x A
/====\/====\/====\/====\/====\/====\/====\ V
(A/V for up/down, in case it's unclear :))
> Point taken. This might be a solution for a lot of users. I doubt this
> will be implemented though.
I guess so :) But, who knows, maybe it'll resurface later :)
--
[ www.garoo.net ]
Garoo
news:Xns9250114582A07g...@213.228.0.33:
>>> Then there's the option to resize the tabs area
>> Oh nonono. Not another *option*. Nobody will approve that.
>
> I didn't say "option" as in "configuration option".
By the way, I just don't understand that, at all:
Mozilla has the opportunity to be the most customizable browser around, not
by cluttering the Preferences window, but simply by adding options to the
user.js file for "power users". I can't understand why it's not used more.
For instance, having simple user.js options to hide whole parts of the
Mozilla suite hidden; or to select which options are needed or not in the
right-click menu (instead of hunting through xml files in a .jar); adding
or removing a home button to the nav toolbar; or whatever little design
decisions one user might like or not.
There is this great opportunity to have a browser completely and very
simply customizable, and it's not nearly used as much as it could: why?
(Sorry if it's been debated over and over, haven't been around for years.)
--
[ www.garoo.net ]
Soeren Nils Kuklau
> Soeren Nils Kuklau <chu...@web.de> wrote in
> news:ah7o6q$2m...@ripley.netscape.com:
>>But a menu always has scrollers (except few menus on Windows that are
>>multi-row, which is only confusing). So a chevron's menu is still
>>infinite.
> Ok. I don't like scrolling menus at all, but maybe it's just me, I haven't
> got precise arguments for that :)
I also prefer menus that just fit on screen, but that's impossible with
a dynamic / infinite menu.
>>Please distinguish between scrollbars (which will never happen for the
>>tabbar) and scrollers (which might be considered).
> I'm not sure what you call a scroller exactly.
Got Windows? Open Date/Time prefs in Control Panel. The 'ickle buttons
beneath the time and the year are scrollers.
> But I'm not talking about a horizontal scrollbar, in any case. But a
> vertical one, to cycle through tab rows.
Okay...
> In a one-line tab bar, there would be no scrollbar per se but only scroll
> buttons, so if that's what you're calling scroller, ok.
Exactly.
> But, in a multiline
> tab bar setting, there would be room for the scrollbar between the up/down
> buttons.
I don't think there would be *enough* room for them to make much sense
(unless you have 4+ rows).
>>>it looks weird to add a button.
>>A lot less weird than a scrollbar.
> :)))
> I guess we're getting at personal preferences there :o))
Definitly.
> Anyway, the part I'm arguing for more strongly is not scroll/chevron, but
> the multiline tab bar :)
I understand that, and we're individuums, and thus, we all have slightly
different opinions, tastes, preferences, properties. And we have the
right for them. So, your solution is a multiline tab bar, and mine is a
chevron at the end of the bar, showing the other tabs listed vertically
in a menu.
>>Can you draw an ASCII graphic or even better a real image of how this
>>is supposed to look like?
> Um, what? The multiline tab bar? If you're on Windows, you probably have
> one on the display properties box, for instance. Only that it's not
> resizable, because you're unlikely to need 100 tabs there.
>
> The idea would be that a single-row tab bar:
>
> /==\/==\/==\/==\/==\/==\/==\/==\/==\/==\/==\/==\ x
>
> Could be resized, by dragging the bottom border, and translate to:
>
> /====\/====\/====\/====\/====\ x
> /====\/====\/====\/====\/====\/====\/====\
Got that.
> Actually, the Windows display properties does this, but I find it awkward:
>
> /=======\/======\/=======\/======\/======\
> /====\/====\/====\/====\/====\/====\/====\
Plus, I've seen situations with *three* rows at the display properties
(many graphics card drivers add lots of additional tabs). Now, click on
a tab in row three. That row is suddenly row one. Now, try to find the
tab were you were before. Good luck (especially with even *more* rows,
as seen in several Office application's preferences dialogs).
This is one of the situations I'd like to avoid.
> And, with the scrollbar, that would be something like :
>
> /====\/====\/====\/====\/====\/====\/====\ x A
> /====\/====\/====\/====\/====\/====\/====\ V
>
> (A/V for up/down, in case it's unclear :))
It indeed was ("A" could have been the "Add Tab" button, for instance) :-)
Now, looking at those ascii graphics, the approach doesn't seem /that/
awkward, but read my display properties / office preferences notes and
you'll see my issues with this.
>>Point taken. This might be a solution for a lot of users. I doubt this
>>will be implemented though.
> I guess so :) But, who knows, maybe it'll resurface later :)
Maybe someone could come up with an XPI for it, so you could install it
as alternative behaviour.
Soeren Nils Kuklau
> Mozilla has the opportunity to be the most customizable browser around, not
> by cluttering the Preferences window, but simply by adding options to the
> user.js file for "power users". I can't understand why it's not used more.
One of the reasons, AFAIK, is performance. For example, Site Navigation
Bar was backed out for performance reasons. The option to just
deactivate it wouldn't have helped.
Garoo
>> I'm not sure what you call a scroller exactly.
>
> Got Windows? Open Date/Time prefs in Control Panel. The 'ickle buttons
> beneath the time and the year are scrollers.
Ok, but I've always seen them called "spin controls", that's why I wasn't
sure what you were referring to :)
> So, your solution is a multiline tab bar, and
> mine is a chevron at the end of the bar, showing the other tabs listed
> vertically in a menu.
Only that those two solutions aren't mutually exclusive :)
> Plus, I've seen situations with *three* rows at the display properties
> (many graphics card drivers add lots of additional tabs). Now, click
> on a tab in row three. That row is suddenly row one. Now, try to find
> the tab were you were before. Good luck (especially with even *more*
> rows, as seen in several Office application's preferences dialogs).
You're right, I had forgotten that it became unusable in that case.
Well...
I'd say you could decide that the active tab doesn't necessarily need to be
in the bottom row, that there could be three rows of tabs, and the active
tab highlighted in the middle row.
But it does pretty much break the idea of the "tab" itself, and instead
replicates the Windows taskbar, and then mpt's objections to the nature of
the tab bar come to mind, and my head hurts :)
So maybe it wasn't such a good idea after all :)
--
[ www.garoo.net ]
Soeren Nils Kuklau
> Soeren Nils Kuklau <chu...@web.de> wrote in
> news:ah9d2m$9l...@ripley.netscape.com:
>>>I'm not sure what you call a scroller exactly.
>>Got Windows? Open Date/Time prefs in Control Panel. The 'ickle buttons
>>beneath the time and the year are scrollers.
> Ok, but I've always seen them called "spin controls", that's why I wasn't
> sure what you were referring to :)
I've never heard of "spin controls". I believe they're called *yet*
differently on Mac OS (where they were first introduced).
>>So, your solution is a multiline tab bar, and
>>mine is a chevron at the end of the bar, showing the other tabs listed
>>vertically in a menu.
> Only that those two solutions aren't mutually exclusive :)
Wouldn't a combination of both - if that is what you are suggesting - be
even more confusing for Joe User?
>>Plus, I've seen situations with *three* rows at the display properties
>>(many graphics card drivers add lots of additional tabs). Now, click
>>on a tab in row three. That row is suddenly row one. Now, try to find
>>the tab were you were before. Good luck (especially with even *more*
>>rows, as seen in several Office application's preferences dialogs).
> You're right, I had forgotten that it became unusable in that case.
>
> Well...
>
> I'd say you could decide that the active tab doesn't necessarily need to be
> in the bottom row, that there could be three rows of tabs, and the active
> tab highlighted in the middle row.
>
> But it does pretty much break the idea of the "tab" itself,
Yes, because the actual thing *on* the tab is in that case no longer
right below it, as has always been the case for real-world tabs.
> and instead
> replicates the Windows taskbar, and then mpt's objections to the nature of
> the tab bar come to mind, and my head hurts :)
>
> So maybe it wasn't such a good idea after all :)
See ;-)
Jason Bassford
> in the bottom row, that there could be three rows of tabs, and the active
> tab highlighted in the middle row.
Ah. Why would the active tab be anything but where you saw it before
you clicked on it? When you have only one tab row, as now, when you
click on the tab, the tab row doesn't suddently reposition itself so
that the one you clicked on is now on the left or in the middle. Nor
should this sort of thing happen in a multi tab row situation. If the
tab you click on is in the 3rd row on the right - the interface should
keep it there.
Jason Bassford
> right below it, as has always been the case for real-world tabs.
I don't think that that's a problem at all. Why does the content have
to be immediately below the tab? It's only immediately below the tab
now, because there's only one row. If we have multi rows, then the
"rows" become a form of control panel. Look at it as a reverse
computer keyboad, monitor. You don't see the data on the monitor
immediately above the key you press, but above the entire keyboard.
You select from a row of available tabs the content you want, and the
data appears in the "viewscreen" below the "control panel". It makes
sense to me.
Jason Bassford
it seems to make the most sense to me.
Overflow tabs into more tab rows, but handle the issue of "too many
tab rows" in the following manner:
When one tab row is overflowed, another one is created below it but is
not actually shown. A little vertical scrollbar would appear on the
right, indicating that there is a row below the current one which you
can scroll down to. The "tab window" itself would also be resizable
so that each user could individually size it according to their
tastes. If they want to see 2 or 3 tab rows they could do that. If
they want only the one, taking up no more space than it currently
does, they could do that too.
Soeren Nils Kuklau
The problem with that is that it's illogical to have a tab be somewhere
in the 5th row and yet see its contents on the very front.
Soeren Nils Kuklau
>>Yes, because the actual thing *on* the tab is in that case no longer
>>right below it, as has always been the case for real-world tabs.
> I don't think that that's a problem at all. Why does the content have
> to be immediately below the tab? It's only immediately below the tab
> now, because there's only one row.
And there's only one row because mpt has pointed the people several
times at a page explaining the flaws of having several rows of tabs ;-)
> If we have multi rows, then the
> "rows" become a form of control panel. Look at it as a reverse
> computer keyboad, monitor. You don't see the data on the monitor
> immediately above the key you press, but above the entire keyboard.
> You select from a row of available tabs the content you want, and the
> data appears in the "viewscreen" below the "control panel". It makes
> sense to me.
Okay, that does make sense. But then it would be a "tabboard" rather
than an organizer full of tabs (metaphorically). I don't know if this is
really a problem.
Sailfish
Soren, it seems from this newsgroup's rading, you've taken on the
Atlasean task of holding-up the chrevron UI for overflow tabs? You often
cite some ethereal (study?) provided by mpt as to why multi-row tabs are
bad; yet, never quite come off explaining why yourself? The weight of
your argument must seem unbearable by now since you don't seem to have
many defenders?
Surely, if we were debating the merits of adding ONE extra row of tabs
under overflow conditions, I find it difficult to accept that anyone
would suggest that the clumsy chrevon UI would be more user-friendly
(especially considering the added irritant of users missing it an
clicking the "close-tab" button accidentally?)
What I understand is that you (mpt?), rather, defend the chevron
approach because of the possibility of users having 3+ rows of tabs. I
submit to you, as before, that such a situation would be an exception,
not the norm, for the vast majority of browser users and, as such,
doesn't justify the need for a, imo, bad design of a chevron.
Basically, a UI should be decided based on the most-likely conditions,
not some vaguely defined remote possibility. I would also submit that
those who are promoting the chevron UI have it as their task to convince
others as to why they believe 3+ rows would be a normal situation AND,
if they cannot, why using multi-row tabs for an overflow situation is
worse (mind you, neither approach offers ultimate eloquence since we are
discussing an overflow situation to begin with.)
morbit _at_ cdn.gs
> This is a continuation of
> http://bugzilla.mozilla.org/show_bug.cgi?id=155325 (which was a
> continuation of http://bugzilla.mozilla.org/show_bug.cgi?id=106927).
> Both bugs discuss ways to handle what to do when too many tabs are
> opened to fit on the screen.
>
> Read the commentary (and responses from Mozilla/Netscape UI people) in
> those bugs and continue the discussion here, if you wish. Once some
> agreement has been reached and a reasonable design has been written (and
> preferably has been reviewed by a Moz/NS UI guru), post it to bug 155325.
>
suppose for a given screen / window width there is a set maximum number
of tabs, why not as another idea, to be dimissed disembowelled and
generally sneered at, open another Mozilla window to put the maximum+1th
tab into
--
cdn
--
Orbit3 lives
Get Orbit3+1 from : http://themes.mozdev.org - mostly Stable
Orbit Retro from : http://themes.mozdev.org - mostly Stable
Soeren Nils Kuklau
> Soren, it seems from this newsgroup's rading, you've taken on the
> Atlasean
^^^^ the... *what*?
> task of holding-up the chrevron UI for overflow tabs? You often
> cite some ethereal (study?) provided by mpt as to why multi-row tabs are
> bad; yet, never quite come off explaining why yourself? The weight of
> your argument must seem unbearable by now since you don't seem to have
> many defenders?
Sorry? I think I've pointed out often enough why in my very humble
opinion chevrons are the best - yet a far from perfect - solution.
The other three solutions I know of are
- scrollers at the side. Takes too long to find the correct row that way.
- several rows, all shown. Messes up the UI and appears to confuse users.
- a combination of both. Doesn't sound too bad, but I still think that
chevrons are slightly more efficient.
> Surely, if we were debating the merits of adding ONE extra row of tabs
> under overflow conditions, I find it difficult to accept that anyone
> would suggest that the clumsy chrevon UI would be more user-friendly
I don't think anyone was talking about *one* row. I think most believe
that the third non-chevron solution is preferred now, which is basically
*one* row, with scrollers, but with the option to add rows (with
scrollers if needed).
> (especially considering the added irritant of users missing it an
> clicking the "close-tab" button accidentally?)
Umm, so you're suggesting that 99% of all window managers are flawed
because someone might accidentally push the close window button instead
of grow / zoom / minimise / maximise / pin or whatever they actually
wanted to push?
> What I understand is that you (mpt?),
Umm, wait. Last I heard, mpt lived in New Zealand. I'm from Germany.
My job is not to defend mpt, but he appears to be one of the few people
from mozilla who know at least a *bit* from usability / UI design. I
disagree with mpt on a lot of respects and was able to laugh at a
certain Netscape engineer's "mpt book cover".
I have never heard of "mpt" until a few months ago.
> rather, defend the chevron
> approach because of the possibility of users having 3+ rows of tabs. I
> submit to you, as before, that such a situation would be an exception,
> not the norm, for the vast majority of browser users and, as such,
> doesn't justify the need for a, imo, bad design of a chevron.
You've repeatedly stated in this message that you consider chevrons bad
design. Why?
> Basically, a UI should be decided based on the most-likely conditions,
> not some vaguely defined remote possibility.
I've given real-world examples such as "Display Properties", which were
quite messy. I haven't heard of examples where chevrons can get *real*
messy. I've already said that they aren't the one-and-only solution;
there isn't any (known one).
> I would also submit that
> those who are promoting the chevron UI have it as their task to convince
> others as to why they believe 3+ rows
Where have I said that 3+ rows would be a normal situation?
> would be a normal situation AND,
> if they cannot, why using multi-row tabs for an overflow situation is
> worse (mind you, neither approach offers ultimate eloquence since we are
> discussing an overflow situation to begin with.)
True. And? Your post is confusing me.
Hogarth
> suppose for a given screen / window width there is a set maximum number
> of tabs, why not as another idea, to be dimissed disembowelled and
> generally sneered at, open another Mozilla window to put the maximum+1th
> tab into
From my perspective, if I wanted to have another mozilla window opened,
I'd open it myself. One of my top-5 pet peeves atm are websites that
force mozilla to open a window without me explicitly initiating the
process (ie clicking on a link and getting a new window for it). This
shits me, personally, to tears and to have moz open up a new window when
I requested a tab would shit me just as much.
YMMV but that's how it'd be for me. :)
--
Hogarth http://mozilla.weebeastie.net/
RAAAAAAAAAAAAAAAAAAAAAR!
morbit _at_ cdn.gs
I don't like other web sites telling me how to arrange my browsing
either : ), it was merely another suggestion, to be di_s_missed ... etc
Sailfish
> On 7/20/2002 5:52 PM, Sailfish apparently wrote exactly the following:
>
>> Soren, it seems from this newsgroup's rading, you've taken on the
>> Atlasean
>
>
> ^^^^ the... *what*?
http://edweb.sdsu.edu/people/bdodge/scaffold/GG/titan.html#Atlas
>
>> task of holding-up the chrevron UI for overflow tabs? You often cite
>> some ethereal (study?) provided by mpt as to why multi-row tabs are
>> bad; yet, never quite come off explaining why yourself? The weight of
>> your argument must seem unbearable by now since you don't seem to have
>> many defenders?
>
>
> Sorry? I think I've pointed out often enough why in my very humble
> opinion chevrons are the best - yet a far from perfect - solution.
>
> The other three solutions I know of are
>
> - scrollers at the side. Takes too long to find the correct row that way.
Not if the vast majority of the time there is only ONE extra row, which
is my contention.
> - several rows, all shown. Messes up the UI and appears to confuse users.
First, I don't understand what "messes up the UI" means? It would be
like me saying that a "chevron messes up the UI", imo. Secondly, how
would it confuse the user more than the chevron? At least with two tab
rows, all of the tabs are in plain view and don't require the user to
constantly circumnavigate the browser window fiddling with the chevron
and its pop-up list.
> - a combination of both. Doesn't sound too bad, but I still think that
> chevrons are slightly more efficient.
You've never justified that position, imo. Again, with a two row tab
design, all of the tabs are in plain view; whereas, the chevron design
requires the user to make extra effort which, incidentally, lends itself
to accidently prematurely closing tabs windows.
>> Surely, if we were debating the merits of adding ONE extra row of tabs
>> under overflow conditions, I find it difficult to accept that anyone
>> would suggest that the clumsy chrevon UI would be more user-friendly
>
>
> I don't think anyone was talking about *one* row. I think most believe
> that the third non-chevron solution is preferred now, which is basically
> *one* row, with scrollers, but with the option to add rows (with
> scrollers if needed).
Again, the point I am attempting to convey is that in the vast majority
of situations, one extra row would be all that would be needed. As such,
it makes more sense to allow this extra row to be shown, rather than
forcing them to use scrollers.
I don't have a problem with allowing both, btw.
>> (especially considering the added irritant of users missing it an
>> clicking the "close-tab" button accidentally?)
>
>
> Umm, so you're suggesting that 99% of all window managers are flawed
> because someone might accidentally push the close window button instead
> of grow / zoom / minimise / maximise / pin or whatever they actually
> wanted to push?
No, what I'm proposing is to avoid the problem whenever its possible,
not adding to it.
>> What I understand is that you (mpt?),
>
>
> Umm, wait. Last I heard, mpt lived in New Zealand. I'm from Germany.
You misunderstood. I was merely questioning whether you supported the
chevron over an extra row on its own merits or whether you are merely
parroting mpt's position?
> My job is not to defend mpt, but he appears to be one of the few people
> from mozilla who know at least a *bit* from usability / UI design. I
> disagree with mpt on a lot of respects and was able to laugh at a
> certain Netscape engineer's "mpt book cover".
>
> I have never heard of "mpt" until a few months ago.
So, you seem to suggest that you're not parroting mpt, now all we need
is to see you defending the chevron over an extra tab row by providing
some concrete examples (not generalizations) of why this is the case.
>> rather, defend the chevron approach because of the possibility of
>> users having 3+ rows of tabs. I submit to you, as before, that such a
>> situation would be an exception, not the norm, for the vast majority
>> of browser users and, as such, doesn't justify the need for a, imo,
>> bad design of a chevron.
>
>
> You've repeatedly stated in this message that you consider chevrons bad
> design. Why?
I've also repeatedly stated why? The chevron obscures the extra tabs,
requiring the user to make a basketball equivalent of a three-point shot
everytime they wish to interrogate a hidden tab. And what happens if
they miss the shot? Why, it closes the tab, "thank you very much."
>> Basically, a UI should be decided based on the most-likely conditions,
>> not some vaguely defined remote possibility.
>
>
> I've given real-world examples such as "Display Properties", which were
> quite messy. I haven't heard of examples where chevrons can get *real*
> messy. I've already said that they aren't the one-and-only solution;
> there isn't any (known one).
"Display Properties" isn't tabbed pages. Again, while it "can" get
messy, the likelihood is that it won't. For example, I suppose if I
flood a UI with a bunch of nanosecond-spaced mouse clicks, my bet is
that the opsys might react on this in a quite messy fashion; however,
the likelihood of that happening seems remote so why design something
messy to guard against it?
>> I would also submit that those who are promoting the chevron UI have
>> it as their task to convince others as to why they believe 3+ rows
>
>
> Where have I said that 3+ rows would be a normal situation?
What you haven't adequately defended is why having an extra tab row is
worse than creating a stealthy/deadly chevron.
>> would be a normal situation AND, if they cannot, why using multi-row
>> tabs for an overflow situation is worse (mind you, neither approach
>> offers ultimate eloquence since we are discussing an overflow
>> situation to begin with.)
>
>
> True. And? Your post is confusing me.
Okay.
Soeren Nils Kuklau
I'm tired of arguing about it. I've said it before; if you want multiple
rows, go for it. If you want the next best thing since sliced bread
(whatever that might be), go for it. Just stop this insane thread.
> Soeren Nils Kuklau wrote:
>> On 7/20/2002 5:52 PM, Sailfish apparently wrote exactly the following:
>>> Soren, it seems from this newsgroup's rading, you've taken on the
>>> Atlasean
>> ^^^^ the... *what*?
> http://edweb.sdsu.edu/people/bdodge/scaffold/GG/titan.html#Atlas
Hmm... "heroic"?
>>> task of holding-up the chrevron UI for overflow tabs? You often cite
>>> some ethereal (study?) provided by mpt as to why multi-row tabs are
>>> bad; yet, never quite come off explaining why yourself? The weight of
>>> your argument must seem unbearable by now since you don't seem to
>>> have many defenders?
>> Sorry? I think I've pointed out often enough why in my very humble
>> opinion chevrons are the best - yet a far from perfect - solution.
>>
>> The other three solutions I know of are
>>
>> - scrollers at the side. Takes too long to find the correct row that way.
> Not if the vast majority of the time there is only ONE extra row, which
> is my contention.
What you are saying is that the problem does not exist as long as only
one row is there. That also means that the problem *does* exist as long
as there are several rows. By that logic, several rows shouldn't be
allowed - which I'm not necessarily thinking.
>> - several rows, all shown. Messes up the UI and appears to confuse users.
> First, I don't understand what "messes up the UI" means?
It puts more controls on the UI.
> It would be
> like me saying that a "chevron messes up the UI", imo. Secondly, how
> would it confuse the user more than the chevron?
The chevron says "hello, click here for further tabs". While several
rows say that even more obviously, they - imo - make the progress of
finding the right tab harder.
> At least with two tab
> rows, all of the tabs are in plain view and don't require the user to
> constantly circumnavigate the browser window fiddling with the chevron
> and its pop-up list.
Indeed. But they add another line. They take up a lot more space. They
are in the way - even in full-screen mode, at least as of now, where
turning off the tab bar in full-screen mode does not work..
>> - a combination of both. Doesn't sound too bad, but I still think that
>> chevrons are slightly more efficient.
> You've never justified that position, imo.
Because they hardly take up any space unless you want their contents.
Because they aren't always in your way and say "hey, you! you've got way
too many tabs open!!!".
> Again, with a two row tab
> design, all of the tabs are in plain view; whereas, the chevron design
> requires the user to make extra effort
Indeed; definitly a disadvantage of chevrons.
> which, incidentally, lends itself
> to accidently prematurely closing tabs windows.
Umm, I don't think so. How?
>> I don't think anyone was talking about *one* row. I think most believe
>> that the third non-chevron solution is preferred now, which is
>> basically *one* row, with scrollers, but with the option to add rows
>> (with scrollers if needed).
> Again, the point I am attempting to convey is that in the vast majority
> of situations, one extra row would be all that would be needed. As such,
> it makes more sense to allow this extra row to be shown, rather than
> forcing them to use scrollers.
A second row is for sure more convenient than scrollers. But what if
that second row gets stuffed as well? Who are we to decide the default
value of maximum rows?
> No, what I'm proposing is to avoid the problem whenever its possible,
> not adding to it.
Then add the chevron to the left; although I would find that quite
strange (the chevron enumerates the rest; the rest is at the end, not at
the beginning).
>>> What I understand is that you (mpt?),
>> Umm, wait. Last I heard, mpt lived in New Zealand. I'm from Germany.
> You misunderstood. I was merely questioning whether you supported the
> chevron over an extra row on its own merits or whether you are merely
> parroting mpt's position?
Why would I want to parrot mpt's position? All I do is try and find a
better solution for overflow than just hiding it.
> So, you seem to suggest that you're not parroting mpt, now all we need
> is to see you defending the chevron over an extra tab row by providing
> some concrete examples (not generalizations) of why this is the case.
See above ;-)
> I've also repeatedly stated why? The chevron obscures the extra tabs,
> requiring the user to make a basketball equivalent of a three-point shot
> everytime they wish to interrogate a hidden tab. And what happens if
> they miss the shot? Why, it closes the tab, "thank you very much."
While it appears that some people accidentally click "close window"
instead of "close tab", I still don't believe anyone would accidentally
click "close tab" instead of "remaining open tabs". By the same logic,
you could also say that "Forward" should have a higher distance from
"Back" because people could accidentally click the wrong one. This has
never happened to me; maybe I'm just lucky.
> "Display Properties" isn't tabbed pages.
It's still tabs. It's very similar: the looks, the behaviour, the
overflow problem... only the content below is different. And the fact
that Microsoft has yet to decide which is the best behaviour for them.
Several TweakUI versions had something comparable to scrollers, but they
were horizontal and yet both at the right. It was so inconvenient I
nearly gave up and uninstalled it for that reason.
Other dialogs use multiple rows; I've already explained the problems
with that. I must admit that I have hardly seen chevrons used for tabs.
> Again, while it "can" get
> messy, the likelihood is that it won't. For example, I suppose if I
> flood a UI with a bunch of nanosecond-spaced mouse clicks, my bet is
> that the opsys might react on this in a quite messy fashion; however,
> the likelihood of that happening seems remote so why design something
> messy to guard against it?
That's a strange example, but I got it.
> What you haven't adequately defended is why having an extra tab row is
> worse than creating a stealthy/deadly chevron.
I have, several times. The user clicks on a tab in row 2. How should
Mozilla react? Only open that tab, making a tab open that isn't actually
in front? Or bring the tab - and its row - to front, so that the user
forgets how to return to the former tab?
Sailfish
> On 7/20/2002 6:55 PM, Sailfish apparently wrote exactly the following:
>
> I'm tired of arguing about it. I've said it before; if you want multiple
> rows, go for it. If you want the next best thing since sliced bread
> (whatever that might be), go for it. Just stop this insane thread.
The majority of posts on this thread are from you, methinks, so who's
causing the insanity? Also, my coding days are behind me. However, my
opinionating days have barely begun :-)
>> Soeren Nils Kuklau wrote:
>
>
>>> On 7/20/2002 5:52 PM, Sailfish apparently wrote exactly the following:
>>
>
>>>> Soren, it seems from this newsgroup's rading, you've taken on the
>>>> Atlasean
>>>
>
>>> ^^^^ the... *what*?
>>
>
>> http://edweb.sdsu.edu/people/bdodge/scaffold/GG/titan.html#Atlas
>
>
> Hmm... "heroic"?
I guess one would need to ask Atlas if he thought he was being rewarded
for his "heroism?"
>>>> task of holding-up the chrevron UI for overflow tabs? You often cite
>>>> some ethereal (study?) provided by mpt as to why multi-row tabs are
>>>> bad; yet, never quite come off explaining why yourself? The weight
>>>> of your argument must seem unbearable by now since you don't seem to
>>>> have many defenders?
>>>
>
>>> Sorry? I think I've pointed out often enough why in my very humble
>>> opinion chevrons are the best - yet a far from perfect - solution.
>>>
>>> The other three solutions I know of are
>>>
>>> - scrollers at the side. Takes too long to find the correct row that
>>> way.
>>
>
>> Not if the vast majority of the time there is only ONE extra row,
>> which is my contention.
>
>
> What you are saying is that the problem does not exist as long as only
> one row is there. That also means that the problem *does* exist as long
> as there are several rows. By that logic, several rows shouldn't be
> allowed - which I'm not necessarily thinking.
No, please read my post carefully. I said one EXTRA row, meaning
precisely ... TWO. I don't disagree that more than two becomes more
problematic but, unless someone can point out where this will happen
very often in the normal user-community browser experience, then its a
problem that doesn't need a solution, imo.
>>> - several rows, all shown. Messes up the UI and appears to confuse
>>> users.
>>
>
>> First, I don't understand what "messes up the UI" means?
>
>
> It puts more controls on the UI.
More controls is precisely what the UI doesn't need, imo.
>> It would be like me saying that a "chevron messes up the UI", imo.
>> Secondly, how would it confuse the user more than the chevron?
>
>
> The chevron says "hello, click here for further tabs". While several
> rows say that even more obviously, they - imo - make the progress of
> finding the right tab harder.
How? One merely hovers over the tab and the hint balloon quickly
displays the full title. What's more easy than that?
>> At least with two tab rows, all of the tabs are in plain view and
>> don't require the user to constantly circumnavigate the browser window
>> fiddling with the chevron and its pop-up list.
>
>
> Indeed. But they add another line. They take up a lot more space. They
> are in the way - even in full-screen mode, at least as of now, where
> turning off the tab bar in full-screen mode does not work..
A lot more space? Puhleaase! It adds maybe 0.5 inch and considering that
the person is in an exception situation to begin with, that hardly seems
like much of a penalty.
>>> - a combination of both. Doesn't sound too bad, but I still think
>>> that chevrons are slightly more efficient.
>>
>
>> You've never justified that position, imo.
>
>
> Because they hardly take up any space unless you want their contents.
> Because they aren't always in your way and say "hey, you! you've got way
> too many tabs open!!!".
Well, one, if he had "too many open tabs" maybe its a good thing for the
UI to remind him/her of that. But, my guess is that most people wouldn't
be thinking on those terms. Rather, they know darn well that they've got
more tabs than space allows and willing added others. Now, if I right,
the question then becomes, what the easiest/safest way for them to
navigate them. Having two rows of stacked tabs seems a lot easier than
having to constant hunt and aim for a chevron.
>> Again, with a two row tab design, all of the tabs are in plain view;
>> whereas, the chevron design requires the user to make extra effort
>
>
> Indeed; definitly a disadvantage of chevrons.
>
>> which, incidentally, lends itself to accidently prematurely closing
>> tabs windows.
>
>
> Umm, I don't think so. How?
Unless the chevron is on the left side of the tab panel (my assumption
is that the intent is to have it grouped with the "close tab" button.
Also, I assume that the grouping would need to be fairly close so as not
to steal valuable space away from the tabs. Thus, being grouped AND
close in proximity increases the chances of clicking the wrong button.
Having a second tab row makes this possibility a non-issue.
>>> I don't think anyone was talking about *one* row. I think most
>>> believe that the third non-chevron solution is preferred now, which
>>> is basically *one* row, with scrollers, but with the option to add
>>> rows (with scrollers if needed).
>>
>
>> Again, the point I am attempting to convey is that in the vast
>> majority of situations, one extra row would be all that would be
>> needed. As such, it makes more sense to allow this extra row to be
>> shown, rather than forcing them to use scrollers.
>
>
> A second row is for sure more convenient than scrollers. But what if
> that second row gets stuffed as well? Who are we to decide the default
> value of maximum rows?
As I stated, you're runinng into the "nanosecond mouse click" territory
here. However, and again, I'm not adverse to having both, i.e., expanded
tab panel AND scrollbuttons.
>> No, what I'm proposing is to avoid the problem whenever its possible,
>> not adding to it.
>
>
> Then add the chevron to the left; although I would find that quite
> strange (the chevron enumerates the rest; the rest is at the end, not at
> the beginning).
We agree on this, having either of the two buttons (chevron or close) on
the left would be way too-contrarian.
>> I've also repeatedly stated why? The chevron obscures the extra tabs,
>> requiring the user to make a basketball equivalent of a three-point
>> shot everytime they wish to interrogate a hidden tab. And what happens
>> if they miss the shot? Why, it closes the tab, "thank you very much."
>
>
> While it appears that some people accidentally click "close window"
> instead of "close tab", I still don't believe anyone would accidentally
> click "close tab" instead of "remaining open tabs". By the same logic,
> you could also say that "Forward" should have a higher distance from
> "Back" because people could accidentally click the wrong one. This has
> never happened to me; maybe I'm just lucky.
Well, first, the FOWARD/BACK buttons are spaced a significant distance
apart which is the biggest reason people seldon click the wrong one.
Also, they are graphically a lot bigger which makes their recognition a
lot easier. The close and chevron buttons won't have either of these
luxuries and my guess is that most people don't browse by riviting their
attention to the UI but, rather, in a more relaxed manner. As such, the
likelihood of a wrong click is much, much higher, imo.
>> "Display Properties" isn't tabbed pages.
>
>
> It's still tabs. It's very similar: the looks, the behaviour, the
> overflow problem... only the content below is different. And the fact
> that Microsoft has yet to decide which is the best behaviour for them.
> Several TweakUI versions had something comparable to scrollers, but they
> were horizontal and yet both at the right. It was so inconvenient I
> nearly gave up and uninstalled it for that reason.
I disagree. The best analogy is what we discussed in the beginning, that
being, the Taskbar (which, if I'm not mistaken affords both scroll
buttons AND extra rows?)
> Other dialogs use multiple rows; I've already explained the problems
> with that. I must admit that I have hardly seen chevrons used for tabs.
Well, just because it hasn't been used isn't reason enough not to
support it, surely. However, I do believe that the extra row would make
a lot more sense and be easier to use to the majority of users, imo.
Helge Hielscher
> I have, several times. The user clicks on a tab in row 2. How should
> Mozilla react? Only open that tab, making a tab open that isn't actually
> in front? Or bring the tab - and its row - to front, so that the user
> forgets how to return to the former tab?
This point is only valid as long as mozilla doesnt support undo for
(tab)navigation.
Regards,
Helge
Soeren Nils Kuklau
following:
> Soeren Nils Kuklau wrote:
True, but that will hopefully never change. As soon as such a feature
got implemented, people would request a "open tabs history", causing
even more bloat. One of the last things we need.
Sailfish
>> What you haven't adequately defended is why having an extra tab row is
>> worse than creating a stealthy/deadly chevron.
>
>
> I have, several times. The user clicks on a tab in row 2. How should
> Mozilla react? Only open that tab, making a tab open that isn't actually
> in front? Or bring the tab - and its row - to front, so that the user
> forgets how to return to the former tab?
That's a non-sequitur since one already is faced with this with 3+ tabs
on a single row. For example, if I jump to a middle tab of 5, then close
that tab, the UI merely opens the next leftmost tab. The UI should
respond exactly the same way with that situation irrespective of whether
they are skewed vertically or horizontally.
(btw, somehow I neglected to see this last paragraph in my first
response and that's the reason I'm responding now.)
Jason Bassford
> in the 5th row and yet see its contents on the very front.
Sorry, I don't agree here. I think it makes a lot of sense. What
doesn't make sense to me is reorienting the tab bar display to put the
active tab into context. It doesn't do this horizontally with a
single row, so it should vertically with mutliple rows.
Gervase Markham
> Atlasean task of holding-up the chrevron UI for overflow tabs? You often
> cite some ethereal (study?) provided by mpt as to why multi-row tabs are
> bad; yet, never quite come off explaining why yourself?
Have you ever tried using a multi-row tab box in e.g. a Windows configuration dialog? It's horribly painful, because they keep jumping about - click on something, and it moves. Ick.
Gerv
Sailfish
I have but I content that for the vast majority of people this would not
be a problem with tabbed windows for a couple of reasons. One, most
folks will not ever have more than two rows of tabs and two, they will
not have even those two rows for very long since as they finish reading
a tab window, they will close it. Thus, the ability to have easy access
to all of the tabs will out-weigh the difficulty of having to make
multiple mouse movements, clicks, scroll, clicks.
Jason Bassford
> Windows configuration > dialog? It's horribly painful,
> because they keep jumping about - click on something, and
> it moves. Ick.
I still don't understand two things:
1. Why a Mozilla multi-row tab box would have to behave as some others
have.
2. Why anybody proposing a multi-row tab box would WANT tabs to jump
around. I wouldn't. As I've said before, tabs in our current,
existing, single row tab bar do not jump around. If I have 40 tabs
open, my leftmost tab is tab 1, and I click on tab 20 - the tab bar
does *not* reposition itself so that the leftmost tab is now tab 20.
What happens is simply that the highlighted tab changes and the
content window changes to match that of the content associated with
tab 20. Why would a multi-row tab box be any different than this?
Just highlight the tab you click on, DO NOT reposition anything, and
display that tab's contents underneath the tab box...
Gervase Markham
> be a problem with tabbed windows for a couple of reasons. One, most
> folks will not ever have more than two rows of tabs
It's still a problem with two rows of tabs.
> and two, they will
> not have even those two rows for very long since as they finish reading
> a tab window, they will close it.
So, "This solution does suck, but people won't use it very much, so it doesn't matter that it sucks"?
Gerv
Smaug
Patching the Classic skin might not properly, but it is easy
to do it by hand.
Smaug
PS. This is working fine even with 50 tabs.
Smaug wrote:
> Tim wrote:
>
>> This is a continuation of
>> http://bugzilla.mozilla.org/show_bug.cgi?id=155325 (which was a
>> continuation of http://bugzilla.mozilla.org/show_bug.cgi?id=106927).
>> Both bugs discuss ways to handle what to do when too many tabs are
>> opened to fit on the screen.
>>
>> Read the commentary (and responses from Mozilla/Netscape UI people) in
>> those bugs and continue the discussion here, if you wish. Once some
>> agreement has been reached and a reasonable design has been written
>> (and preferably has been reviewed by a Moz/NS UI guru), post it to bug
>> 155325.
>>
> Here is a screenshot of a simple solution.
> The code is working fine, it just
> needs some polishing.
> (Maybe the favicons could be used in the
> tabmenu too?)
>
> Smaug
>
> ------------------------------------------------------------------------
>
Sailfish
>> I have but I content that for the vast majority of people this would
>> not be a problem with tabbed windows for a couple of reasons. One,
>> most folks will not ever have more than two rows of tabs
>
>
> It's still a problem with two rows of tabs.
Any solution presents a problem. Its just that no solution presents a
bigger one.
>> and two, they will not have even those two rows for very long since as
>> they finish reading a tab window, they will close it.
>
>
> So, "This solution does suck, but people won't use it very much, so it
> doesn't matter that it sucks"?
Honestly, have you taken a look at Smaug's attachment in this thread?!
Can you tell me that you'd want to have to constantly have to navigate
through that mess rather than having those in a second row of tabs? I
sure wouldn't. Here's my classifications:
Multi-row tabs - Suck
Chevrons - Suckier
No Solution - Suckiest
The Chevron solution is a carpel tunnel syndrom one in that it requires
the user to more focused on the UI than is neccessary, along with
requiring more mouse interaction and lastly, causes internal angst in
hopes of not inadvertantly clicking the "Close" button.
Gervase Markham
> Can you tell me that you'd want to have to constantly have to navigate
> through that mess rather than having those in a second row of tabs? I
> sure wouldn't. Here's my classifications:
>
> Multi-row tabs - Suck
> Chevrons - Suckier
> No Solution - Suckiest
>
> The Chevron solution is a carpel tunnel syndrom one
Did I say I supported the chevron solution?
I like the current solution - that tabs just get smaller and smaller - because it's transparent to the user what's going on. Also, as the user adds more tabs, it becomes increasingly obvious to them that it's time to open a new window :-)
"We support this feature under sensible usage, but if you do silly things with it, expect the obvious to happen" is a reasonable thing to say about a bit of software or feature.
The only reason to change from the current system would be if you could make a case for it being common for users to have 30 tabs open and still want to pick particular ones by title. IMO, if you _are_ opening 30 tabs, you probably don't want to pick out particular ones, but are just going to read them all in some order, closing most of them as you go and maybe keeping a few to the end to bookmark or study further.
Gerv
Sailfish
Hmmm, actually, after further reflection, I agree with you to a large
extent. Unfortuneately, it seems that the development folks are intent
on solving this, seemingly, low-impact problem. More unfortuneately, it
seems they're intent on solving it by adding another control (chevron)
to the already control-laden UI. So, here's my re-order:
Tab hidden overflow - Suck
Multi-row tab - Suckier
Chevron - Suckiest
michael lefevre
>> Honestly, have you taken a look at Smaug's attachment in this thread?!
>> Can you tell me that you'd want to have to constantly have to navigate
>> through that mess rather than having those in a second row of tabs? I
>> sure wouldn't. Here's my classifications:
>>
>> Multi-row tabs - Suck
>> Chevrons - Suckier
>> No Solution - Suckiest
>>
>> The Chevron solution is a carpel tunnel syndrom one
> <snip>
>
> Did I say I supported the chevron solution?
>
> I like the current solution - that tabs just get smaller and smaller - because it's transparent to the user what's going on. Also, as the user adds more tabs, it becomes increasingly obvious to them that it's time to open a new window :-)
>
> "We support this feature under sensible usage, but if you do silly things with it, expect the obvious to happen" is a reasonable thing to say about a bit of software or feature.
that's not a solution, that's telling users not to open more tabs than
they can see...
> The only reason to change from the current system would be if you could make a case for it being common for users to have 30 tabs open and still want to pick particular ones by title. IMO, if you _are_ opening 30 tabs, you probably don't want to pick out particular ones, but are just going to read them all in some order, closing most of them as you go and maybe keeping a few to the end to bookmark or study further.
but if you have 27 tabs you don't want to pick out, and 3 that you do,
you can't see any of them.
I don't see any harm in using the other solutions - if you don't want to
use the chevron button, you can limit the number of tabs. you could have
the tab bar somewhat resizable, so you could stretch it to two rows if
you wanted (like the windows task bar), and/or have the chevrons appearing
if you made it smaller (like a windows toolbar)
--
michael
Soeren Nils Kuklau
following:
> Did I say I supported the chevron solution?
> I like the current solution - that tabs just get smaller and smaller -
> because it's transparent to the user what's going on. Also, as the user
> adds more tabs, it becomes increasingly obvious to them that it's time
> to open a new window :-)
That's not really an overflow solution then though. And once tab width
is below 50 pixels, you can hardly work with them any more... with
"true" overflow solutions such as multiple rows or chevrons, this would
be fixed.
> "We support this feature under sensible usage, but if you do silly
> things with it, expect the obvious to happen" is a reasonable thing to
> say about a bit of software or feature.
>
> The only reason to change from the current system would be if you could
> make a case for it being common for users to have 30 tabs open and still
> want to pick particular ones by title. IMO, if you _are_ opening 30
> tabs, you probably don't want to pick out particular ones, but are just
> going to read them all in some order, closing most of them as you go and
> maybe keeping a few to the end to bookmark or study further.
That's true.
Gervase Markham
>> I like the current solution - that tabs just get smaller and smaller -
>> because it's transparent to the user what's going on. Also, as the
>> user adds more tabs, it becomes increasingly obvious to them that it's
>> time to open a new window :-)
>
> That's not really an overflow solution then though. And once tab width
> is below 50 pixels, you can hardly work with them any more... with
> "true" overflow solutions such as multiple rows or chevrons, this would
> be fixed.
When you say "It's not an overflow solution", what you mean is "It's not a solution which allows me to read the titles of all my tabs when I have more than a certain number."
My response is that I suggest that it is not a requirement for this to be possible - or rather, those schemes which do make it possible complicate the UI too much for not enough gain.
I don't know where the bug relating to this issue is, but if some sanity could be restored and we could get on with fixing Mozilla's serious UI issues, that would be lovely :-)
Gerv
Matthew Thomas
>
> Soeren Nils Kuklau wrote:
> >
> > > No cheverons in that design, that I noted? :-)
>...
> > In *that* spec, there are.
| Each of those bars containing controls which may not fit in the bar
| completely -- the Toolbar, the Bookmarks Bar, and the Preferences Bar
| -- should, when and only when it is overflowing, have a menu at its
| right end providing access to the overflowed items. This menu should
| have chevrons (>>) as its title, and look and feel exactly the same as
| any other pulldown menu in that theme.
>...
> Yes. I was a bit sloppy in my reference. I was suggesting that the
> proposal specified adding more toolbars for new items rather than
> expanding existing toolbars using the chevron.
No, it doesn't. How many bars there are is irrelevant to what you do
when the window is too narrow for any one of those bars to show all its contents.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mpt.phrasewise.com/>
Matthew Thomas
>...
> Mozilla has the opportunity to be the most customizable browser
> around, not by cluttering the Preferences window, but simply by adding
> options to the user.js file for "power users". I can't understand why
> it's not used more.
Because it would make Mozilla slower, crashier, fatter, buggier,
and harder to use.
>...
> There is this great opportunity to have a browser completely and very
> simply customizable, and it's not nearly used as much as it could:
> why?
>...
Because it would be a massive waste of time. Both for developers and for users.
Sailfish
> Sailfish wrote:
>
>>Soeren Nils Kuklau wrote:
>>
>>>>No cheverons in that design, that I noted? :-)
>>>
>>...
>>
>>>In *that* spec, there are.
>>
>
> | Each of those bars containing controls which may not fit in the bar
> | completely -- the Toolbar, the Bookmarks Bar, and the Preferences Bar
> | -- should, when and only when it is overflowing, have a menu at its
> | right end providing access to the overflowed items. This menu should
> | have chevrons (>>) as its title, and look and feel exactly the same as
> | any other pulldown menu in that theme.
Unsure why you posted this?
>>...
>>Yes. I was a bit sloppy in my reference. I was suggesting that the
>>proposal specified adding more toolbars for new items rather than
>>expanding existing toolbars using the chevron.
>
>
> No, it doesn't. How many bars there are is irrelevant to what you do
> when the window is too narrow for any one of those bars to show all its contents.
The point I was trying to make is that I found it odd that you preferred
to add toolbars for added features rather than group them on a single
toolbar along with, say, chevrons for overflow expansions. otoh, you
prefer to add chevrons for tab overflow expansions but not tab height.
It seems inconsistent.
Matthew Thomas
>...
> > > Yes. I was a bit sloppy in my reference. I was suggesting that the
> > > proposal specified adding more toolbars for new items rather than
> > > expanding existing toolbars using the chevron.
> > No, it doesn't. How many bars there are is irrelevant to what you do
> > when the window is too narrow for any one of those bars to show all
> > its contents.
>
> The point I was trying to make is that I found it odd that you
> preferred to add toolbars for added features
No, I didn't. There are no new features in the toolbars I specced,
beyond what are already implemented as menu items or prefs.
Mozilla has too many features.
> rather than group them on
> a single toolbar along with, say, chevrons for overflow expansions.
Because in general, overflowing toolbars should be a last resort, not a
first resort.
> otoh, you prefer to add chevrons for tab overflow expansions but not
> tab height. It seems inconsistent.
>...
Using chevrons in that case would suck horribly, because it would mean
that the active tab sometimes wasn't visible on-screen. But it wouldn't
suck nearly as badly as using multiple rows of tabs, where every tab
would jump into a different position whenever you chose a tab that
wasn't on the bottom row.
Tabs were a great advance in graphical interfaces because they made it
much more obvious, in a multi-panelled window, how a label for a panel
maps to the panel itself. It is very obvious which panel of a tabbed
window is currently selected, because the bottom of the active tab is
the same color as the panel itself, and there is no border between them.
(Mozilla, like other tabbed browsers, manages to suck here in two
different ways: the tab isn't the same color as the page, and there's an
extra border along the bottom of all the tabs making the distinction
between active and inactive tabs much harder to see.)
However, tabs work only if you have a few panels to switch between, up
to about five or six. Once you get more than that, the increased
difficulty in scanning all their labels (like reading a shopping list
where the whole list is one long line of text, rather than one item per
line) outweighs the increased obviousness of how the labels map to the
panels. Where you have more than about five or six panels, you should
use an option menu inside a group box (like Mozilla's Fonts preferences
panel) or a listbox (like Mozilla's Preferences dialog as a whole) instead.
The corollary of this is that tabs can't be used when the programmer
doesn't know, ahead of time, how many panels there are going to be. For
example, in the Get Info/Show Info windows in Mac OS, there are usually
between one and three panels available (e.g. `General Information',
`Sharing', and `Memory'), but in theory there could be any number of
panels depending on add-ins installed in the system. This means the
window can't use tabs; it uses the option-menu-in-a-groupbox technique
instead. (Mozilla, like other tabbed browsers, sucks here again because
it doesn't limit the number of tabs opened per window.)
Tabs also work only if the width of the window is fixed, or a minimum
width is set on the window so that all the tabs will always fit in a
single row. If that's not the case, the row of tabs will inevitably take
up more than the width of the window in some cases, and all ways of
handling that overflow suck horribly. (Hence the Mozilla suckiness which
is being discussed in this thread.)
Sailfish
> Sailfish wrote:
>>preferred to add toolbars for added features
>
>
> No, I didn't. There are no new features in the toolbars I specced,
> beyond what are already implemented as menu items or prefs.
>
> Mozilla has too many features.
Another poorly-worded statement on my part. I meant, "...preferred to
add toolbars for toolbar-accessible preferences."
>> rather than group them on
>>a single toolbar along with, say, chevrons for overflow expansions.
>
>
> Because in general, overflowing toolbars should be a last resort, not a
> first resort.
We agree on this part of it, at least.
>>otoh, you prefer to add chevrons for tab overflow expansions but not
>>tab height. It seems inconsistent.
>>...
>
>
> Using chevrons in that case would suck horribly, because it would mean
> that the active tab sometimes wasn't visible on-screen. But it wouldn't
> suck nearly as badly as using multiple rows of tabs, where every tab
> would jump into a different position whenever you chose a tab that
> wasn't on the bottom row.
I fail to understand how the multi-row tabs would do as you've stated?
It would seem to me that the selected tab would become the focus and the
others would remain where they are and (except for the tab that had been
the focus) as they are.
> Tabs were a great advance in graphical interfaces because they made it
> much more obvious, in a multi-panelled window, how a label for a panel
> maps to the panel itself. It is very obvious which panel of a tabbed
> window is currently selected, because the bottom of the active tab is
> the same color as the panel itself, and there is no border between them.
> (Mozilla, like other tabbed browsers, manages to suck here in two
> different ways: the tab isn't the same color as the page, and there's an
> extra border along the bottom of all the tabs making the distinction
> between active and inactive tabs much harder to see.)
This is a theme layout issue not a UI one. For example, some themes
choose to display tabs in a way where these distinctions are more apparent.
> However, tabs work only if you have a few panels to switch between, up
> to about five or six. Once you get more than that, the increased
> difficulty in scanning all their labels (like reading a shopping list
> where the whole list is one long line of text, rather than one item per
> line) outweighs the increased obviousness of how the labels map to the
> panels. Where you have more than about five or six panels, you should
> use an option menu inside a group box (like Mozilla's Fonts preferences
> panel) or a listbox (like Mozilla's Preferences dialog as a whole) instead.
While I agree that once tabs become scrunched then the user can no
longer tell which one is which within plain view, the "hint" popup
ameliorates this problem to a large degree, imo. Also, while its not the
best, its tons better than the previous means with new windows since
there one had to constantly guess which window to bring into focus;
especially if there were browser windows opened that had information
unrelated to what is now within a tabbed window.
> The corollary of this is that tabs can't be used when the programmer
> doesn't know, ahead of time, how many panels there are going to be. For
> example, in the Get Info/Show Info windows in Mac OS, there are usually
> between one and three panels available (e.g. `General Information',
> `Sharing', and `Memory'), but in theory there could be any number of
> panels depending on add-ins installed in the system. This means the
> window can't use tabs; it uses the option-menu-in-a-groupbox technique
> instead. (Mozilla, like other tabbed browsers, sucks here again because
> it doesn't limit the number of tabs opened per window.)
While I agree that this COULD become unwieldy, I continue to believe
that in the majority of cases (95+%) wouldn't exceed one row of tabs and
(99+%) would never exceed the need for one extra row. As such, why
develop a clumsy chevron interface to hand the 0.002% of users who are
determined to vacuum the entire infobahn into one browser window?
> Tabs also work only if the width of the window is fixed, or a minimum
> width is set on the window so that all the tabs will always fit in a
> single row. If that's not the case, the row of tabs will inevitably take
> up more than the width of the window in some cases, and all ways of
> handling that overflow suck horribly. (Hence the Mozilla suckiness which
> is being discussed in this thread.)
In reality, the plain-view obviousness of which tab refers to which
article is lost well before the tabs overflow; especially where web
pages use long title descriptions. This could begin to happen in as
little as three tabs, no?
However, if some method of handling overflow tabs conditions is deemed
neccessary then I still believe multi-row offers the most intuitive and
easier to maneuver method over the chevron.
Of course, another option could be to just not allow an overflow to
occur, i.e., once an overflow tab request is made, the UI could popup a
"limit exceeds" message and either not allow the new tab or give the
user the option of opening it in a new window, I suppose?