716279 - [UX] style unloaded background tabs differently from loaded background tabs

Status: NEW

(Firefox :: Theme, defect)

Description

[Asa Dotzler [:asa]]

Attachment: animation showing styling of unloaded tabs

We are probably going to enable "don't load tabs until selected" (tabs on demand) for users who opt to have tabs from previous sessions automatically loaded on Firefox launch. (bug 711193) I think it would be a good time, as we increase the usage of that feature, to style unloaded tabs differently from loaded tabs. 

There's an extension that does this today called Tab Utilities and I've been playing with it for a few days and believe it will help users understand why a tab doesn't load until the click on it. The styling choice in Tab Utilities is transparency and that seems like a reasonable starting point. 

I've attached an animation of the Tab Utilities styling so you can see how it looks.

Comment 1

[Dão Gottwald [:dao]]

I think this is the wrong direction. Users shouldn't understand this, because they shouldn't think about it in the first place. This should just work transparently.

This is also a duplicate...

Comment 2

[Asa Dotzler [:asa]]

(In reply to Dão Gottwald [:dao] from comment #1)
>  This should just work transparently.

I have no idea what that means. What should work? 

With tabs on demand, you have three tab states. You have the focused tab which is necessarily loaded and you have unfocused tabs which may or may not be loaded. That's tree states but we currently tell the user it is two states which is misleading. Sometimes a user will switch to a background tab and it will be "ready" and other times it'll be blank aka "not ready".

Comment 3

[Dão Gottwald [:dao]]

The additional state is an implementation detail. Why should users care about this, let alone users who didn't opt for this behavior? It sounds like there's a responsiveness problem when selecting tabs that are restored (!= loaded) on demand. We should make it so that this problem doesn't exist.

What you're proposing is also problematic from an accessibility point of view. Those faded tabs have less contrast (unsurprisingly) and are harder to read. Please don't underestimate the effect this can have on visually impaired people. I would care less if there was some nifty, unobtrusive and accessible styling, though even then I stand by what I said above.

Comment 4

[Asa Dotzler [:asa]]

(In reply to Dão Gottwald [:dao] from comment #3)
> It sounds like
> there's a responsiveness problem when selecting tabs that are restored (!=
> loaded) on demand. We should make it so that this problem doesn't exist.

How do you make sure it doesn't exist? The feature is "Don't load the contents of the tab until I click on it."  That's not a responsiveness problem, that's the expected behavior.

Comment 5

[Dão Gottwald [:dao]]

(In reply to Asa Dotzler [:asa] from comment #4)
> (In reply to Dão Gottwald [:dao] from comment #3)
> > It sounds like
> > there's a responsiveness problem when selecting tabs that are restored (!=
> > loaded) on demand. We should make it so that this problem doesn't exist.
> 
> How do you make sure it doesn't exist?

By improving the restoration process or by restoring earlier.

> The feature is "Don't load the
> contents of the tab until I click on it."  That's not a responsiveness
> problem, that's the expected behavior.

It's only expected behavior for someone explicitly enabling it. Generally, the expected behavior is "user clicks on a tab and gets the content." The feature you're referring to is for saving resources and as I said an implementation detail from the user's point of view.

Comment 6

[Asa Dotzler [:asa]]

(In reply to Dão Gottwald [:dao] from comment #5)

> It's only expected behavior for someone explicitly enabling it.

It's the behavior we have. We might want a different behavior (and we have other behaviors) but this behavior is "load the tabs when I click on them" and until that changes to "save some resources in a completely transparent and different way" this isn't just an implementation detail, it's the state of the feature. We can't pretend we have the better feature when we don't and there aren't even plans for it. This is the feature, as designed and as implemented. It's likely to stay this way for some time.

Comment 7

[Dão Gottwald [:dao]]

Ok, let's discuss what we have rather than how this would ideally work. The nuisance of a tab not being ready when you select it doesn't go away when styling it differently. Personally, I buy it that this nuisance is minor and not a deal breaker if the wins are real (which seems questionable for users with only a few tabs). If this is however considered annoying enough that we need to train users to expect something different from what they used to and ideally should expect when selecting tabs, then we shouldn't make this the default behavior in the first place.

Comment 8

[u428464]

This new approach could be confusing. It exactly looks like Chrome handle the tab multi-selection feature (as seen in chrome beta 17). As Firefox is going to provide the same feature in a near future it shouldn't be oonfusing for the user to have loaded/unloaded tabs and selected tabs look the same.

Comment 9

[Alex Limi (:limi) — Firefox UX Team]

I'd like there to be an indicator, but it can be even more subtle than this. In BarTab, it was gray text instead of black text on tabs that aren't loaded yet, and I think this worked reasonably well.

Ultimately, it's shorlander's call styling-wise. :)

Comment 11

[Sean Newman]

This bug is a duplicate of 675541, not vice-versa.

Comment 13

[Nicolas Barbulesco]

(In reply to Dão Gottwald [:dao] from comment #3)

> The additional state is an implementation detail. Why should users care
> about this, let alone users who didn't opt for this behavior? It sounds like
> there's a responsiveness problem when selecting tabs that are restored (!=
> loaded) on demand. We should make it so that this problem doesn't exist.

Well, isn't this special state functionally different ? Doesn't the activation of the tab trigger the loading of its content from the network ? I suppose yes. So, there is a difference, and letting the user know it can help the user. When I click on a tab which is already loaded, I don't expect its content to be fresh. So, say I know this tab has been there for days. Later I want to get fresh info — the page is in a news site, or is a discussion in a forum. I load again this page. Now, let's imagine I click on a not-yet-loaded tab. It loads. So I know the page I'm reading is the page *as of today*. This is different. This can matter.

Comment 14

[Dão Gottwald [:dao]]

(In reply to Nicolas Barbulesco from comment #13)
> Well, isn't this special state functionally different ? Doesn't the
> activation of the tab trigger the loading of its content from the network ?

It won't necessarily load from the network, no.

Comment 16

[Potch [:potch]]

Adding a use-case for this UX:

A user remarked that they couldn't tell whether a tab was loaded, and that after restart they wouldn't get email notifications from that tab (via changed tab title) because they forgot to click to restore it.

Comment 17

[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 18

[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.