924888 - Issues with legibility of tab strip

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

Attachment: Australis tab bar vs old tab bar

This is for Australis/UX Nightly.

I'm finding it quite hard to browse through my open tabs and find the right ones (90% of my UX interaction with Firefox...). After loading the same session in both UX Nightly and normal Nightly, I can see why (screenshot attached):

1) Tab description text is reduced by about 30%. This is either because the tabs are smaller, or because they lose space due to the padding for the rounded tabs. Less text makes it harder to identify which tab is which.
2) The amount of tabs is severely reduced. This appears to have 2 causes:
2.1) The pinned tab is offset to the right for some unknown reason.
2.2) The tab groups/new tab control section on the right is pushed to the left due to Windows system controls (even though it visually looks like it'd fit below).

Potentially some of these have been filed separately already. I'd advise you to look at the screenshot however and consider just how bad the combination of factors turns out. It really makes Firefox a pain to use with many tabs.

Comment 1

[:Gijs (he/him)]

If you draw a straight line from the top of the tabs to the right, it's pretty easy to see that, however it might appear, they won't actually fit underneath. As the hover state of the buttons to the right of the tabstrip is just as high as the tabs, the same goes for the buttons. I agree that the empty space there looks weird if this is the first time you're seeing it, I just don't think there's much we can do about this.

The pinned tabs are offset because of the curve that shows up when you hover them.

We could investigate improving the cropping, although I'm not sure how doable that is. We'd prefer to fade out the label text (bug 658467) but there's currently no good way to do that considering the fact that the background of the tab can be transparent. Because there's less of a separation between the different tabs, I'm also not sure how much we could reduce padding there while maintaining a clearly visible distinction between different tabs.

Stephen, any ideas here?

Comment 2

[Gian-Carlo Pascutto [:gcp]]

>I agree that the empty space there looks weird if this is the first time you're seeing it, I just don't think there's much we can do about this.

I don't care so much that it looks weird - the problem is what it results in. Again, check the screenshot and imagine trying to find the right tab in both cases. It's a pretty noticeable usability loss.

Is it possible for example to reduce whatever graphical effect is given to the hover state of the 3 buttons so at least they can fit underneath?

Fitting the tabs looks like it requires shifting everything down a few pixels. I guess that would undo any vertical space gained by moving the menu away from the frame, so that's sad. Would doing this as soon as the user has, say, 8 tabs open, be worth considering? Moving the layout of things like that could be a bit weird, but this is similar to how the tabs would move next to the menu in the vertical direction when maximizing in non-Australis, and we already move tabs around when you add/remove them.

Comment 3

[:Gijs (he/him)]

I think that at least figuring out what, if anything, we can do here, is P2, because if we're changing stuff related to this late in the cycle we're going to all be sad.

Comment 4

[Gian-Carlo Pascutto [:gcp]]

The pain here becomes really obvious when having a bunch of Bugzilla bugs open. All the favicons are the same, so they provide no information. All the tabs look like:

123456 - A...
123789 - U...
123012 - T...
134567 - P...

Looks like we'll have to start learning bug numbers by hearth. Is there an easily accessible setting that controls tab width, to reduce the pain for now?

Comment 5

[Elbart]

The easily accessible setting has been removed: bug 574654
Your options are using an addon or adding rules to userChrome.css yourself.

Comment 8

[Madhava Enros [:madhava]]

I think we can address this bug with four already open issues:

Better visual grouping / shape suggestion
1. Darkening the tab separators (bug 894224)
2. Tightening the space between favicon and tab title (bug 943507)

Showing more of the title
3. Fading the end of the cropped title vs. using an ellipsis (bug 658467)
4. Removing redundancy from repeated tab titles (bug 583890)

We could _also_ investigate the following.

5. We could also consider making the minimum tabsize a little bigger.
6. Something better than tooltips when you hover over cropped tabs (e.g. http://cl.ly/image/0R3P3C2Q1Z2Y)

Comment 9

[Thomas Stache]

(In reply to Madhava Enros [:madhava] from comment #8)
> I think we can address this bug with four already open issues:
> 
> 5. We could also consider making the minimum tabsize a little bigger.

I would really like to see (5.) for OS X, with just 2-3 tabs open they look very narrow. 1cm/20% more would help readability without looking silly like Safari's full width tab bar.

Comment 10

[Mike de Boer [:mikedeboer]]

(In reply to Madhava Enros [:madhava] from comment #8)
> 6. Something better than tooltips when you hover over cropped tabs (e.g.
> http://cl.ly/image/0R3P3C2Q1Z2Y)

<3 this idea. Not that it immediately fixes the problem, but a rich tooltip (or hover infobox) like that is really interesting to augment information-rich, but space-constrained UI elements, like our tabs. We could even show a miniature screenshot of the tab contents when it's available in the cache.

Found bug 379003, which is all over this. I'll attach the screenshot there too.

Comment 11

[Matthew N. [:MattN]]

(In reply to Thomas Stache from comment #9)
> (In reply to Madhava Enros [:madhava] from comment #8)
> > I think we can address this bug with four already open issues:
> > 
> > 5. We could also consider making the minimum tabsize a little bigger.
> 
> I would really like to see (5.) for OS X, with just 2-3 tabs open they look
> very narrow. 1cm/20% more would help readability without looking silly like
> Safari's full width tab bar.

It sounds like you're talking about the *maximum* tab width if you only have 2-3 tabs open. Increasing that is being discussed in bug 941430.

Comment 13

[Justin Dolske [:Dolske]]

We can try some of the tweaks in comment 8 (especially if UX makes some concrete suggestions, hinthint!), but in general I think that this isn't basically a WONTFIX -- we can tweak this endlessly, but in general you're only going to gain a few characters unless you make the tabs _really_ big (and then you've got a bug about not being to have very many tabs visible at the same time in a window).

Comment 14

[fbrfa8.g]

Seems like, as usual, having tacticool looking round corners and etc. is more important than functionality.  Good job designers.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

>but in general you're only going to gain a few characters

Gaining a few characters back is fine, that would at least not make this a bad regression in some of the most important UX of the product.

Comment 16

[Pascal Chevrel:pascalc]

Please note that this is an even larger issue for non-English builds, most of European languages are 20 to 30% longer than English. Even with just 6 tabs open, most of them have just a few letters displayed ended with an ellipsis that don't allow me to read what they are even though I still have a lot of unused horizontal space that could be used by the tabs to show me the full title. BTW is there a bug filed for tabs no longer widening when there is horizontal space available? 

It seems a bit absurd that with just one tab open, I get half the text of the title displayed in the title only, this is actually a lot more shortened than the 30% mentionned in comment #0
example:

Close all tabs and go to http://www.ghacks.net/2014/01/15/main-reason-chrome-tab-audio-indicators-firefox/

Firefox 26: The main reason why Chrome ...
Chromium: The main reason why Chro
Australis: The main reaso...

Classic Firefox shows 28 characters, Australis shows 15. The tab itself is shorter in Australis but not in the same proportions as the text title.

Please also note that our own internal pages such as about:addons about:plugins about:support about:home... have now unmeaningful tab titles in many languages and most of our users do not use Firefox in English. Have you included in your test plans for the Australis design other languages than English?

Thanks

Comment 17

[Dão Gottwald [:dao]]

(In reply to Pascal Chevrel:pascalc from comment #16)
> BTW is there a bug filed for tabs no longer widening when
> there is horizontal space available? 
> 
> It seems a bit absurd that with just one tab open, I get half the text of
> the title displayed in the title only, this is actually a lot more shortened
> than the 30% mentionned in comment #0
> example:
> 
> Close all tabs and go to
> http://www.ghacks.net/2014/01/15/main-reason-chrome-tab-audio-indicators-
> firefox/
> 
> Firefox 26: The main reason why Chrome ...
> Chromium: The main reason why Chro
> Australis: The main reaso...
> 
> Classic Firefox shows 28 characters, Australis shows 15. The tab itself is
> shorter in Australis but not in the same proportions as the text title.

Bug 941430

Comment 18

[Madhava Enros [:madhava]]

This is an important issue, and involves a lot of interrelated bugs/optimizations. Really figuring this out is not containable in 29. I'm switching thsi to M- to preserve its priority.

I think we _can_, for the moment, increase up the maxwidth in bug 941430. I'm bumping up its priority to P3.

Comment 19

[Stephen Horlander [:shorlander]]

(In reply to Madhava Enros [:madhava] from comment #18)
> This is an important issue, and involves a lot of interrelated
> bugs/optimizations. Really figuring this out is not containable in 29. I'm
> switching thsi to M- to preserve its priority.
> 
> I think we _can_, for the moment, increase up the maxwidth in bug 941430.
> I'm bumping up its priority to P3.

Yes, there isn't an optimal solution here in the timeframe we have.

Comment 20

[Dave Garrett]

(In reply to Stephen Horlander [:shorlander] from comment #19)
> (In reply to Madhava Enros [:madhava] from comment #18)
> > This is an important issue, and involves a lot of interrelated
> > bugs/optimizations. Really figuring this out is not containable in 29.
> 
> Yes, there isn't an optimal solution here in the timeframe we have.

In other words, Australis is now on track for a release in 30 instead of 29?

Comment 21

[Stephen Horlander [:shorlander]]

(In reply to Dave Garrett from comment #20)
> (In reply to Stephen Horlander [:shorlander] from comment #19)
> > (In reply to Madhava Enros [:madhava] from comment #18)
> > > This is an important issue, and involves a lot of interrelated
> > > bugs/optimizations. Really figuring this out is not containable in 29.
> > 
> > Yes, there isn't an optimal solution here in the timeframe we have.
> 
> In other words, Australis is now on track for a release in 30 instead of 29?

No, in other words this probably won't be entirely fixed before release.

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 24

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.