Close buttons on tabs: TabClipWidth
Pam Greene
which this occurs is TabClipWidth in about:config. I found it
disconcerting, so I did a little playing around with it; here's what I
determined.
Having the behavior change unexpectedly (and even if I know it's going
to happen, I still never know quite when) is a bigger problem than
exactly what that width is. So I'd set it to the minimum allowed tab
width, so that tabs keep close buttons right up until the time they
start going into overflow, meaning of course that they keep close
buttons all the time.
Specifically, both those numbers are 85 pixels, for me -- but again,
having the TabClipWidth the same as the minimum tab width is the
important part.
On a related note, I wonder how it would be to put the close button on
the right sides of the tabs, instead of the left? On the one hand,
it'd look a lot nicer and less cluttered, and people aiming for the
favicon would be less likely to click on the close button. On the
other, it would associate the close button less strongly with the tab,
and people might accidentally click the close box of the next tab
over.
- Pam
Philip Withnall
button *is* on the right-hand side of the tab.
Joe Hughes
> As tabs get smaller, they lose their close buttons. The width at
> which this occurs is TabClipWidth in about:config. I found it
> disconcerting, so I did a little playing around with it; here's what I
> determined.
IIRC there's a minimum tab size/tab overflow behavior in the works for
FF2. Which is good, because I'm so bad at closing tabs that it really
gets out of hand sometimes as it stands now. Also IIRC we're changing
to close button on only the active tab.
> On a related note, I wonder how it would be to put the close button on
> the right sides of the tabs, instead of the left? On the one hand,
> it'd look a lot nicer and less cluttered, and people aiming for the
> favicon would be less likely to click on the close button. On the
> other, it would associate the close button less strongly with the tab,
> and people might accidentally click the close box of the next tab
> over.
Well, right now I think it's on the right on Mac & Linux, and on the
left on Mac OS X. This conforms to the placement of the close button on
standard OS windows, as well as the placement of the tab close button in
Safari and Camino (but not Opera).
Do you think people aim for the favicon a lot? It doesn't do anything
in particular, but it is a visual magnet. Do we have any relevant info
on that from the tab-browsing user tests that we did a while back?
.joe.
Mike Beltzner
> IIRC there's a minimum tab size/tab overflow behavior in the works for
> FF2. Which is good, because I'm so bad at closing tabs that it really
> gets out of hand sometimes as it stands now. Also IIRC we're changing
> to close button on only the active tab.
Yes on both counts. We're also looking into that somewhat wacky idea
of having the tabs stay a constant width while they're being closed
until the user moves the mouse away from the tabstrip. I've been a
little annoyed at how the close tab target keeps moving on me, but am
not convinced that the proposed alternative behaviour would be any
less jarring.
> > the right sides of the tabs, instead of the left? On the one hand,
> > it'd look a lot nicer and less cluttered, and people aiming for the
I think we can make that close button look nicer and a lot less
cluttered on OSes where the close button is normally at the left.
Right now it's quite a heavy element. If we added a bit of pixel space
between the two, and made it a grey "x" that darkens on hover (or
highlights on hover) I think it would look a lot better. But I agree
that it looks a touch awkward.
> Do you think people aim for the favicon a lot? It doesn't do anything
> in particular, but it is a visual magnet. Do we have any relevant info
> on that from the tab-browsing user tests that we did a while back?
People *looked* at the favicon a lot, but didn't try to click there to
close. Of course, those tests were done on a Windows box, not a Mac
box, so the two weren't wedged up against each other.
cheers,
mike
--
[ mike beltzner / user experience lead / mozilla corporation ]
Pam Greene
> On 4/10/06, Joe Hughes <j...@retrovirus.com> wrote:
> > FF2. Which is good, because I'm so bad at closing tabs that it really
> > gets out of hand sometimes as it stands now. Also IIRC we're changing
> > to close button on only the active tab.
>
As a default, or as the only choice? I've really appreciated having them
on every tab in recent builds. I use the feature several times a day. Oh,
well.
> I think we can make that close button look nicer and a lot less
> cluttered on OSes where the close button is normally at the left.
> Right now it's quite a heavy element. If we added a bit of pixel space
> between the two, and made it a grey "x" that darkens on hover (or
> highlights on hover) I think it would look a lot better. But I agree
> that it looks a touch awkward.
Sounds great.
If a lighter-weight close button doesn't do the trick, though, I don't
think it would be terrible to move the button to the right in OS X
too. The left edge of a tab, when the tab is way over on the right of
the screen, isn't very closely associated with the top-left corner of
a window anyway. The tab-close button always used to be way over at
the right end of the tab bar, and that didn't create a dissonance.
- Pam
Mike Beltzner
> That's a shame. I've really appreciated having them on every tab in
> recent builds. I use the feature several times a day. Oh, well.
We'll see how feedback is from A2. This is one of those really tricky
UI features where there is no "right" design answer by heuristic
analysis, and where preference seems to be split along some pretty
strong lines (novices like buttons on every tab, existing users really
don't, some people find that it makes targets harder to hit, others
find the background close ability really useful).
I know this won't help you much on mac, but you can always close a
background tab by middle-clicking on it :)
> > I think we can make that close button look nicer and a lot less
> > cluttered on OSes where the close button is normally at the left.
> > Right now it's quite a heavy element. If we added a bit of pixel space
> > between the two, and made it a grey "x" that darkens on hover (or
> > highlights on hover) I think it would look a lot better. But I agree
> > that it looks a touch awkward.
>
> Great.
>
> If a lighter-weight close button doesn't do the trick, though, I don't
> think it would be terrible to move the button to the right in OS X
> too. The left edge of a tab, when the tab is way over on the right of
> the screen, isn't very closely associated with the top-left corner of
> the window anyway. The tab-close button always used to be way over at
> the right end of the tab bar, and that didn't create a dissonance
> either.
Well, the whole reason to put the buttons on the tabs instead of all
the way at the right was that eye-tracking data showed that novice and
expert users alike actually look to the tab first for a close button.
On XP, they all looked where the close buttons on a window would be. I
would expect Mac users to look to the left, where the close button on
Mac windows is, but maybe (especially in the world of OS X) that will
have changed. We should see if we can get some data for mac users, as
I agree with you that it looks ... funny.
Eric Shepherd
the tabs can be pretty jarring.
Eric Shepherd
Technical Writer
she...@mozilla.com
Peter Lairo
> ...we're changing to close button on only the active tab.
I wouldn't forgive myself if I failed to mention that I think not having
close buttons on background tabs would be a *bad idea*.
The "fixed-width tab" concept is a bad idea (IMO). It severely limits
either the number of visible tabs (large fixed tabs) or the amount of
info you can read on each tab (small fixed tabs). A *minimum width*
would be much better.
The "I accidentally hit the close button because I can't aim at an area
that is 90% larger" problem is overrated too (IMO). BTW: Windows XP
shows the (clickable) close buttons of background windows!
Background tabs are often tabs the user is no longer interested in
(that's why they're in the background). Thus, those are the tabs that
should be easy to close.
PS. Sorry if this post seems blunt. I'm trying to be concise due to time
restrictions.
--
Regards,
Peter Lairo
Lame attempt to get rich: http://www.lairo.com/donations.html
Mike Beltzner
> PS. Sorry if this post seems blunt. I'm trying to be concise due to time
> restrictions.
You're also being repetetive. You've raised these points before, and
myself and others have explained why we think it's worth exploring
these directions for A2.
Sorry if I'm the one who's now being blunt.
Peter Lairo
> On 4/11/06, Peter Lairo <ImTire...@nospam.net> wrote:
>> PS. Sorry if this post seems blunt. I'm trying to be concise due to time
>> restrictions.
>
> You're also being repetetive. You've raised these points before,
*Most* of the points I hadn't raised before (I checked), so I'm not sure
why you're claiming otherwise. Shouldn't the decision be made on an
evaluation of all relevant factors?
> and
> myself and others have explained why we think it's worth exploring
> these directions for A2.
I could find only one (remaining valid, but IMO insufficient) reason for
removing background-tab close
buttons(news://news.mozilla.org:119/T8Cdnc8Xpfir8pHZ...@mozilla.org).
Seems like mozilla.org is past the "exploring" phase ("we're [we *are*]
changing to close button on only the active tab").
> Sorry if I'm the one who's now being blunt.
No problem.
--
Regards,
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
UnderDog
"Mike Beltzner" <mbel...@gmail.com> wrote in message
news:mailman.571.1144756401...@lists.mozilla.org...
--
Let me start by saying I apologize if I'm misunderstanding the thread. It
seems to me there are valid points for keeping the background tab close
buttons, as well as for removing them. I myself use them regularly.
Currently, with extensions, the options exist to show the buttons , not show
the buttons, show the buttons when hovering, or only show the button on the
active tab. It seems to me, that's still the way to go. Keep it as a user
preference, as no two users are the same, and everyone has different
opinions. As stated, I prefer having the choice to show the button on all
tabs. Just my humble opinion.
Peter Lairo
> Let me start by saying I apologize if I'm misunderstanding the thread. It
> seems to me there are valid points for keeping the background tab close
> buttons, as well as for removing them. I myself use them regularly.
> Currently, with extensions, the options exist to show the buttons , not show
> the buttons, show the buttons when hovering, or only show the button on the
> active tab. It seems to me, that's still the way to go. Keep it as a user
> preference, as no two users are the same, and everyone has different
> opinions. As stated, I prefer having the choice to show the button on all
> tabs. Just my humble opinion.
Even though you agree with my suggested solution (keep the background
buttons), I must disagree with making something so minor an option. This
would increase UI bloat needlessly. That is what Seamonkey does and what
extensions are for.
I would suggest making a list of pros and cons for either solution and
then making an intelligent decision based on the list. I don't think
this has been done yet. I might make such a list if I can find the time.
Unfortunately, I have the impression that the decision to remove the
buttons is a fait accompli, and my efforts would be (and have been) wasted.
UnderDog
"Peter Lairo" <Pe...@NOXXXSPAMLairo.com> wrote in message
news:wPydnaXQsYWTu9_Z...@mozilla.org...
My point was not to agree or disagree with your suggestion, or suggestions
to the contrary. It was meant to voice my own opinion. I agree this is a
minor feature, but I disagree adding user settings, minor or not, adds
useless UI bloat. In fact, the ability to make all these changes is what
makes Firefox the number one browser (IMO), as opposed to IE, which is very
limited regarding user preferences. I have yet to see any negative effects
of Firefox features, small or not.
If some users prefer the buttons not be there, and other users want the
buttons, why should there not be a setting controlled by the user to appease
everyone? If the feature is so minor, what's the point of making a list of
pros and cons? Whatever the programmers decide to do, there will always be
extensions available which will enable users to add/remove/change any of the
settings they're not happy with, provided the ability to change that
particular feature does not exist in the options. As you've stated, this is
what extensions are for, so it makes no difference to me, what the final
outcome might be.
I don't believe any setting should be based solely on what I want, as
opinions will always differ. I don't have the mindset that anythiing is
right or wrong, simply based on my own thoughts or opinions, nor do I take
any conversation so serious, that if the outcome is not what I personally
want, that the discussion is, or was, a waste of time. I also don't see
anywhere in this thread that the decision was set in stone, and/or
irreversible. To the contrary, all that was said is the decision to remove
the buttons was worth exploring, and they'll see what kind of feedback is
received on A2. Again, whatever the outcome, if it's a user based setting
or not, there will always be extensions to make Firefox do what you want.
Peter Lairo
That's perfectly fine. And I was explaining why I disagreed with adding
that as a UI option.
> I agree this is a
> minor feature, but I disagree adding user settings, minor or not, adds
> useless UI bloat.
So every possible setting, "minor or not", should have UI in the options?
I too don't think a UI option (as opposed to an about:config option)
should be discarded based solely on whether it's "minor or not". Some
options may be minor to most but very important to an important few
(e.g., bug 62429 for corporate use).
> In fact, the ability to make all these changes is what
> makes Firefox the number one browser (IMO), as opposed to IE, which is very
> limited regarding user preferences. I have yet to see any negative effects
> of Firefox features, small or not.
I am usually an advocate of features, and was (and still am) suspicious
of the (IMO overused) "then use an extension" philosophy, but in *this*
case think that a decision has been made that has not been adequately
analyzed yet.
> If some users prefer the buttons not be there, and other users want the
> buttons, why should there not be a setting controlled by the user to appease
> everyone?
Because such scenarios are abundant, and it would quickly result in a
plethora of options. That is one of the main reasons Firefox was created
as a successor to the "Suite".
Firefox's philosophy is to see what makes the most sense to most users
and to make difficult and well thought out decisions, to streamline the
UI and to minimize "minor" options. My standpoint is that the "thought
out" part is missing here.
> If the feature is so minor, what's the point of making a list of
> pros and cons?
Partially because it's a user-facing feature (something users see all
the time), partially because I am a stickler for details, and partially
because I see a process that appears to be driven by personal
preferences of those in control rather than one based on objective analysis.
> Whatever the programmers decide to do, there will always be
> extensions available which will enable users to add/remove/change any of the
> settings they're not happy with, provided the ability to change that
> particular feature does not exist in the options. As you've stated, this is
> what extensions are for, so it makes no difference to me, what the final
> outcome might be.
I have 19 extensions installed in Firefox. I'm tired of finding,
installing, and managing extensions. It was my biggest fear when Firefox
was named the successor to the Suite.
That is why it is so important to chose well thought out defaults, to
reduce the amount of likely extensions.
> I don't believe any setting should be based solely on what I want, as
> opinions will always differ. I don't have the mindset that anythiing is
> right or wrong, simply based on my own thoughts or opinions, nor do I take
> any conversation so serious, that if the outcome is not what I personally
> want, that the discussion is, or was, a waste of time.
You appear to be implying that I said I think the discussion was a waste
of time because the outcome is not to my liking. That is (aside from
being a bit insulting) not at all what I said. I clearly said that my
*creating a list of pros and cons* and further discussing it would be
waste of time because the decision to remove the close buttons appears
to have already been made.
> I also don't see
> anywhere in this thread that the decision was set in stone, and/or
> irreversible. To the contrary, all that was said is the decision to remove
> the buttons was worth exploring, and they'll see what kind of feedback is
> received on A2.
As I've stated before, I have the impression that the decision to remove
the close buttons was made based more on personal preferences rather
than on objective analysis (so far, the stated cons outweigh the stated
pros). As such, the reversal of such a decision (in Fx 3) seems
unlikely, as any user complaints can be explained away as a vocal
*minority* (see bugzilla votes). And lacking any (unlikely) major
outcry, the feature will stay due to "consistency".
Mike Beltzner
> *Most* of the points I hadn't raised before (I checked), so I'm not sure
Apologies. Others had raised them. :)
> why you're claiming otherwise. Shouldn't the decision be made on an
> evaluation of all relevant factors?
Of course. Please go back and look through the threads again, and
you'll see lots of discussion about the points you raised. What I was
saying was that the best way to get wide ranging user feedback about
these types of changes is to make them, release an alpha, and then
talk about them after use. We've gone over the hypotheticals to death,
and I'll be the first to admit that there's no clear winner. However,
if you'd like me to revisit the reasons why I think it's worth full
exploration ...
>I wouldn't forgive myself if I failed to mention that I think not having
>close buttons on background tabs would be a *bad idea*.
As the tab size decreases, active background tab close buttons
increase the dangerous side-effects of missing a tab target. If given
a choice between a minor inconvienience (the inability to close a tab
without first giving that tab focus) and a major one (accidental data
loss), I'll pick minor every time.
>The "fixed-width tab" concept is a bad idea (IMO). It severely limits
>either the number of visible tabs (large fixed tabs) or the amount of
>info you can read on each tab (small fixed tabs). A *minimum width*
>would be much better.
As discussed previously in this newsgroup, the idea would be to try
and merge fixed and flexible width tabs to support the fairly common
"tab cleanup" use-case, where a user is trying to dispose of unused
tabs. Previously this was accomplished by clicking the single Close
Tab button at the right, but under a fully flexible tab size scheme,
the close tab target moves the moment the user closes a tab. The most
recent proposal is to keep the tab sizes fixed as long as the mouse is
in the tabstrip, and then resize them to fit the available area when
the mouse exits that strip. This might be jarring, though, so if it
doesn't work another solution will need to be found.
>The "I accidentally hit the close button because I can't aim at an area
>that is 90% larger" problem is overrated too (IMO). BTW: Windows XP
>shows the (clickable) close buttons of background windows!
We should show the button, sure, but the target to bring a tab to the
foreground should be as large as possible, and reducing that target
space only to support the use-case where someone wants to dispose of a
background tab (which is a fairly advanced tab management action)
seems like optimizing for a minority of users.
As for XP, the target size that will result in the window being
brought to focus is orders of magnitudes larger (it's the entire
background window) and so reserving a relatively small space for
background close is understandable. Also, most applications warn
before closing if that action would result in dataloss, something we
don't have in our tabbed browsing paradigm.
>Background tabs are often tabs the user is no longer interested in
>(that's why they're in the background). Thus, those are the tabs that
>should be easy to close.
Beg pardon? Are you suggesting that the only reason for a tab to be in
the background is that the user is done with it? The entire rationale
behind tabbed browsing is that it allows you to switch between
multiple content areas that you're using. You kind of lost me on this
point.
Sure, there are bound to be tabs that were being used but got lost in
the shuffle, but to be able to close them without looking at them
requires that either (a) the user remember which tab those were in the
tabstrip, or (b) the tab title to be a usable cue. I think that (b) is
more common than (a), but in either case, it's a tab-savvy user who
we're supporting here, and that type of user should be comfortable
with the idea of using a shortcut like right or middle click (both of
which work for background tabs).
> Seems like mozilla.org is past the "exploring" phase ("we're [we *are*]
> changing to close button on only the active tab").
Come on, now. This is Firefox. Nothing's final until the last bit has
shipped! :)
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
Mike Beltzner
> As the tab size decreases, active background tab close buttons
> increase the dangerous side-effects of missing a tab target. If given
> a choice between a minor inconvienience (the inability to close a tab
> without first giving that tab focus) and a major one (accidental data
> loss), I'll pick minor every time.
< span style="egg-on-my-face" >
So, some early data coming back from cognitive modelling done by
Google and NASA's HCI group is showing that the liklihood of
accidental close in cases where there are 1-5 tabs is less than 1%. It
hits 2% around the time tabs hit 135px. I don't have exact numbers
yet, but should shortly.
If that's the case, it might well be within error tolerance to put the
x on all tabs. Interesting data, nonetheless!
< /span >
--
/ mike beltzner / user experience lead / mozilla corporation /
Myk Melez
> it might well be within error tolerance to put the
> x on all tabs. Interesting data, nonetheless!
Especially in conjunction with a discoverable undo close tab feature.
-myk