589010 - Add Visual Indication that Other Groups Exist to Tab Candy Toolbar Button

Status: VERIFIED FIXED

(Firefox Graveyard :: Panorama, defect, P1)

Description

[Aza Raskin [:aza]]

The title pretty much says it all. We need a visual indication that there are other groups available just by looking at the Tab Candy toolbar button/icon. We've brainstormed a number of ways of doing this:

* A badge with a number of groups (seems ugly and makes scanning harder)
* Dots below or to the left of the icon indicating how many groups there are
* Coloring in the squares of the logo as more groups are created

Comment 1

[Aza Raskin [:aza]]

Assigning but to Shorlander for mockup of different visual styles.

Comment 2

[Aza Raskin [:aza]]

Last note: Should have styling for all operating systems.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

We're trying to remove pretty much every state change whisper indicator in Firefox, so adding a new one somewhat undermines us killing [that thing you always use].  Since the user has either never used Tab Candy (in which case the icon will be empty) or they have used tab candy (in which case they have a mental model and spatial memory of the groups existing), what overall problem is this indicator intended to address?

Comment 5

[tommyjb]

(In reply to comment #3)
> … or they have used tab candy (in which case they have a
> mental model and spatial memory of the groups existing) …

I disagree.  I've forgotten, on several occasions, that I have tabs open in Tab Candy.

Comment 6

[Mil]

Why not put tab candy groups in tabs themselves?

Comment 7

[voracity]

Not sure if this has been suggested: I would like to see 1 TabCandy group = 1 Operating System window. (Subgroups can be handled in a different way when they're implemented.) This doesn't obviate the need for an indicator, but means you can rely on simple indicators, like the colouring in groups possibility.

(Incidentally, this would also fix the problem where multiple windows combined with multiple tab groups becomes a usability nightmare.)

Comment 8

[carmudgeon]

(In reply to comment #6)
> Why not put tab candy groups in tabs themselves?

Is the suggestion is to create an additional type of tab to represent a tab group?

If so, I don't believe adding yet another type of tab to the mix is a good idea.  How does the user distinguish between a regular tab, an App tab, and a Group tab?

Clearly, there is a need to indicate the presence of tab groups, and a means to switch between them without invoking the TC view.

There is already a mechanism in place to select tabs that aren't in view, the tab menu, that I believe can be adapted to also switch between tab groups.  

https://bugzilla.mozilla.org/show_bug.cgi?id=589050

The tab menu button could perhaps be given a more prominent appearance, and/or change state to indicate the presence of tab groups, and condition users to see it as a master list of all tab contents.  Even if it isn't used as an indicator, it would still benefit users to see it as such, and fall back on in times of confusion.

Comment 9

[carmudgeon]

Sorry, that bug is actually 587538

https://bugzilla.mozilla.org/show_bug.cgi?id=587538

Comment 10

[Stephen Horlander [:shorlander]]

Attachment: Tab Candy Visual Indicator Ideas

Some ideas for how to represent that there are groups in tabcandy as listed in initial report by aza:

- Coloring in the blocks of the icon until you get four groups then it is solid
- Skip coloring it incrementally and just use a solid color. Blue seems most reasonable given our other icons but it is also our pressed state so perhaps green instead
- Using dots as an indicator up until you have five groups then color it green
- A more subtle glow behind the icon

Comment 11

[Stephen Horlander [:shorlander]]

Attachment: Pulsing Indicator

I don't necessarily think this is a good idea, but a slow pulsing icon is also an option.

Comment 12

[voracity]

I strongly prefer the first (coloring in blocks of icon). But, isn't there always at least 1 tab group? Having 1 block on the icon always coloured blue would make it much less effective as a reminder. (Unless it was a very dull blue.)

Comment 13

[Aza Raskin [:aza]]

I'm a pretty big fan of those last two. The dots have more information—how many tab groups do I have open?—but the light-from-underneath one really yields the sensation of "more here!"

Comment 14

[Dave Garrett]

(In reply to comment #11)
> I don't necessarily think this is a good idea, but a slow pulsing icon is also
> an option.

Please no pulsing constant bits. For something loading, ok, animations can be good. But for something static like an indicator it will be distracting.

(In reply to comment #12)
> I strongly prefer the first (coloring in blocks of icon). But, isn't there
> always at least 1 tab group?

I like this route too. If we're picky with how we describe it, we could mean that the block count is the number of groups offscreen, thus not needing the first. (or counting the tutorial video)

I think the dots are too subtle and not everyone would notice them.

A more advanced suggestion might be to have some form of a tiny thumbnail of the tab candy view, but then the button would need to be a bit bigger.

Comment 15

[José Jeria]

I agree that a pulsing icon would be distracting. It would make me want to click it constantly. Office 2007 has a pulsating "start" to draw the attraction to it. It will never pulsate again once you click on it.

Comment 16

[Paul McAuley]

(In reply to comment #7)
> Not sure if this has been suggested: I would like to see 1 TabCandy group = 1
> Operating System window. (Subgroups can be handled in a different way when
> they're implemented.) This doesn't obviate the need for an indicator, but means
> you can rely on simple indicators, like the colouring in groups possibility.
> 
> (Incidentally, this would also fix the problem where multiple windows combined
> with multiple tab groups becomes a usability nightmare.)

Couldn't agree more. The idea of showing another little obscure icon still does absolutely nothing to address the fact that TabCandy is hiding the user's web-pages. It does nothing to address the fact that TabCandy is more complicated than it needs to be by creating an unnecessary non-standard window management model.

Just expose it to the OS and be a well-behaving, non-arrogant, and consistent application - with a modern OS like windows 7 you could have 8+ FF windows open and still it wouldn't feel cluttered (especially if the new Win7 Taskbar APIs are exploited to their full potential).

See here: https://wiki.mozilla.org/User:Broccauley/Fixing_TabCandy
I've already given you the complete solution!! (including the "sub groups" as mentioned by voracity) :P

Comment 17

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #13)
> The dots have more information—how many
> tab groups do I have open?

Why not add a little badge with the number of other tabs or the number of other tab groups?

Comment 18

[Dave Garrett]

(In reply to comment #17)
> Why not add a little badge with the number of other tabs or the number of other
> tab groups?

A number feels blunt and clunky to me, but it would get the point across nicely.

Comment 19

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: Mockup of numeric badge indicator

Comment 20

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: Mockup of numeric badge indicator

Comment 21

[Dave Garrett]

Comment on attachment 470312 [details]
Mockup of numeric badge indicator

This actually looks interesting. Better than I thought.

One issue though. What should the number count: tabs or groups? If this were to be the way we went, then I think the Tab Candy icon should count groups and then we should add a similar number on the drop down arrow to count shown tabs.

(by the way, for future reference, you can just edit an attachment and correct its mime type rather than having to reupload)

Comment 22

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #21)
> Comment on attachment 470312 [details]
> Mockup of numeric badge indicator
> 
> This actually looks interesting. Better than I thought.
> 
> One issue though. What should the number count: tabs or groups?

My thought was that this would count other groups. It's a question of expectation: when you click on that button you're taken to a view where the groups are the most salient unit of organization, I think giving the users a hint at the number of *groups* they will see is appropriate.

> (by the way, for future reference, you can just edit an attachment and correct
> its mime type rather than having to reupload)

Thanks for the tip. :D

Comment 23

[Dave Garrett]

> by the way, for future reference, you can just edit an attachment and correct
> its mime type rather than having to reupload

They apparently went and hid this feature with one of the recent Bugzilla updates. You have to go to details and click "(edit)" to find it now.

Comment 24

[Aza Raskin [:aza]]

Mitcho: The badge looks better than I expected although I'd like to see dots represent the # of groups (a la the numbers on dice). I still think that we only need to represent one-bit piece of information: if there are other groups/tabs hidden behind the Panorama button. Hence, the glowing icon still seems right to me.

Comment 25

[collura]

bug#590483 looks like a duplicate of this one

Comment 26

[collura]

_really_ like tabcandy/panorama idea since i often have a few hundred tabs that i need to go back and forth across.  thank you thank you :')

0) i like the comment#0 idea of dots to indicate that other groups exist. 
however since i often have 10's of windows and 100's of tabs so a direct dot to tab correlation may not help for all users.  

1) i like the numeral on the badge indicator from comment#20 telling me how many groups there are.  

*we might also put the numeral on each tab in the group to indicate what group you are in.

(combinining the ideas each tab has a subscript numeral (as shown in comment#20 attachment) indicating its group number and has the elipsis dot next to the numeral to indicate if/that other groups exist. you could also present the elipsis dots to left or right or both sides of numeral depending on in first or last group?) 

2) i also like the idea from comment#21 for a pulldown function to the badge for showing each groups tab count and allowing quick switching among groups.

Comment 27

[lexual]

https://bugzilla.mozilla.org/show_bug.cgi?id=590483
https://bugzilla.mozilla.org/show_bug.cgi?id=593752

These bugs are similar (not sure if they're duplicates).

User currently tell which "named" group they are in when using panorama.

Comment 28

[Stephen Horlander [:shorlander]]

Attachment: Panorama Group Indication (Mac)

Comment 29

[Stephen Horlander [:shorlander]]

Attachment: Panorama Group Indication (Windows)

Comment 30

[Stephen Horlander [:shorlander]]

Attachment: Group Indication Glyphs (Mac)

Comment 31

[Stephen Horlander [:shorlander]]

Attachment: Group Indication Glyphs (Windows)

Comment 32

[Aza Raskin [:aza]]

Do we need Linux icons, or do we just use Windows icons for that?

Comment 33

[Aza Raskin [:aza]]

Final idea: Can we have the full state also have a little bit of glow? Otherwise it is a priori hard to remember if it is all full or all empty. Perhaps something similar to the right-most indicator here https://bug589010.bugzilla.mozilla.org/attachment.cgi?id=468958 but with a slightly lighter touch?

Comment 34

[Alex Faaborg [:faaborg] (Firefox UX)]

I would rather we session restore into the tab view to deal with that potential usability problem.  Whisper notifications and lucky charms are the problem, not the solution :)

Comment 35

[Aza Raskin [:aza]]

Attachment: Patch v1

Tested on Mac (but should work on Windows and Linux).

Comment 36

[Aza Raskin [:aza]]

Attachment: Patch v1.1

Forgot to remove two Util.log() calls.

Comment 37

[Michael Yoshitaka Erlewine [:mitcho]]

Comment on attachment 473441 [details] [diff] [review]
Patch v1.1

>+++ b/browser/base/content/tabview/groupitems.js
>@@ -153,8 +153,8 @@
>     .appendTo($container);
> 
>   this.$titlebar.css({
>-      position: "absolute",
>-    });
>+    position: "absolute"
>+  });

Why isn't this just in the platform-independent CSS? Please move it there unless it needs to be in JS.

>@@ -271,7 +271,8 @@
>     this.setResizable(true);
> 
>   GroupItems.register(this);
>-
>+  UI.updateTabButton(GroupItems.groupItems.length);
>+  

Aza, we're calling UI.updateTabButton both times right after GroupItems.register or GroupItems.unregister. Please just move the UI.updateTabButton call to inside GroupItems.register and GroupItems.unregister.

Also, both calls to updateTabButton is updateTabButton(GroupItems.groupItems.length). Remove the numberOfGroups argument and just compute GroupItems.groupItems.length in the function. If you think we have a need for overriding it, then keep the argument but still call it as updateTabButton(), and compute GroupItems.groupItems.length in the function when the arg is missing.

>@@ -287,6 +288,7 @@
>   this.save();
>   } catch(e) {
>     Utils.log("Error in GroupItem()");
>+    Utils.log(e);
>     Utils.log(e.stack);
>   }
> };

Please remove this Utils.log.

>@@ -541,6 +541,25 @@
>+  updateTabButton: function(numberOfGroups){
>+    var tabButton = gWindow.document.getElementById("tabview-button");
>+    var classes = ["one", "two", "three", "many"];

This reminds me of crazy claims about how some languages count and that those people can't conceive of higher numbers...

>+    // Clean-slate the classes set on the Panorama tabbar icon. We can't
>+    // just clear them all out because the button has other classes
>+    // applied to it.
>+    classes.forEach(function(className) iQ(tabButton).removeClass(className) );

No need to wrap it in iQ just for this. tabButton.classList.remove(className)

>+    iQ(tabButton).addClass(className);

Similarly, tabButton.classList.add(className)

feedback+ with those changes. r? the next revision.

Comment 38

[Aza Raskin [:aza]]

Attachment: Patch v2

Fixed the comments from Mitcho's feedback.

Comment 39

[Justin Dolske [:Dolske]]

Comment on attachment 473837 [details] [diff] [review]
Patch v2

I'll r+ this, since it's straightfoward from a code point-of-view, but this should also have ui-r since it's a change to primary chrome. Perhaps limi can break the tie if faaborg really doesn't want this.

My $0.02 is that this doesn't seem too bad as a whisper notification (since it's low priority and not a big deal if missed, but maybe that's not faaborg's concern). OTOH, I don't think it's particularly useful either. So, from a UI-porridge point-of-view, it is the lukewarm "meh" in between love and hate. :)

>+++ b/browser/base/content/tabview/groupitems.js
...
>-  this.$titlebar.css({
>-      position: "absolute",
>-    });

>+++ b/browser/base/content/tabview/tabview.css
...
>+.titlebar {
>+  position: absolute;
>+}

This seems like an unrelated change?


>+++ b/browser/base/content/tabview/ui.js
...
>+  updateTabButton: function UI__updateTabButton(){

This code and the CSS would be simpler if you just set an attribute on the button to the number of groups, and use a CSS attribute selector to control the image.

EG
  var numberOfGroups = GroupItems.groupItems.length;
  if (numberOfGroups > 9)
    numberOfGroups = "many";
  tabButton.setAttribute("groups", numberOfGroups);


  #tabview-button[groups="1"] { ... }
  #tabview-button[groups="2"] { ... }
  #tabview-button[groups="9"] { ... }
  #tabview-button[groups="many"] { ... }

That would also allow theme to have up to 10 states, though I don't know how useful that would really be. But it's cheap and easy. :)

Comment 40

[Justin Dolske [:Dolske]]

Meant to say "r+ with these changes", as well as starting with |groups="0"|. :-)

Comment 41

[Dão Gottwald [:dao]]

Comment on attachment 473837 [details] [diff] [review]
Patch v2

>+  updateTabButton: function UI__updateTabButton(){
>+    var tabButton = gWindow.document.getElementById("tabview-button");
>+    var classes = ["one", "two", "three", "many"];
>+    var numberOfGroups = GroupItems.groupItems.length;
>+
>+    // Clean-slate the classes set on the Panorama tabbar icon. We can't
>+    // just clear them all out because the button has other classes
>+    // applied to it.
>+    classes.forEach(function(className) tabButton.classList.remove(className) );
>+    
>+    if      (numberOfGroups == 0) className = "";
>+    else if (numberOfGroups == 1) className = "one";
>+    else if (numberOfGroups == 2) className = "two";
>+    else if (numberOfGroups == 3) className = "three";
>+    else                          className = "many";            
>+    
>+    tabButton.classList.add(className);
>+  },

tabview-button isn't guaranteed to exist here, and it can be added dynamically to the window via toolbar customization.

Comment 42

[Dão Gottwald [:dao]]

You could probably pretty easily set the attribute on a <broadcaster> (which would always exist) and let tabview-button observe it.

Comment 43

[Dão Gottwald [:dao]]

Also, the gnomestripe icon is too large. So is the winstripe one, but that will be scaled down automatically (which you probably don't want, though).

Comment 44

[Aza Raskin [:aza]]

As a note on whisper notifications: Faaborg, Shorlander, and I worked on this together. So I already believe that Faaborg is onboard so no need for tie-breaking.

Comment 45

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #41)
> Comment on attachment 473837 [details] [diff] [review]
> Patch v2
> 
> >+  updateTabButton: function UI__updateTabButton(){
> >+    var tabButton = gWindow.document.getElementById("tabview-button");
> >+    var classes = ["one", "two", "three", "many"];
> >+    var numberOfGroups = GroupItems.groupItems.length;
> >+
> >+    // Clean-slate the classes set on the Panorama tabbar icon. We can't
> >+    // just clear them all out because the button has other classes
> >+    // applied to it.
> >+    classes.forEach(function(className) tabButton.classList.remove(className) );
> >+    
> >+    if      (numberOfGroups == 0) className = "";
> >+    else if (numberOfGroups == 1) className = "one";
> >+    else if (numberOfGroups == 2) className = "two";
> >+    else if (numberOfGroups == 3) className = "three";
> >+    else                          className = "many";            
> >+    
> >+    tabButton.classList.add(className);
> >+  },
> 
> tabview-button isn't guaranteed to exist here, and it can be added dynamically
> to the window via toolbar customization.

Dāo, do you mean that we should just check for that DOM element's existence before trying to modify it, and return otherwise?

Comment 46

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #39)
> >+++ b/browser/base/content/tabview/groupitems.js
> ...
> >-  this.$titlebar.css({
> >-      position: "absolute",
> >-    });
> 
> >+++ b/browser/base/content/tabview/tabview.css
> ...
> >+.titlebar {
> >+  position: absolute;
> >+}
> 
> This seems like an unrelated change?

Dolske: Yes, which I requested in my feedback because I just noticed it there. If you want us to create a new bug for this piece and take care of it there, I'd be happy to pull this out of this patch.

Comment 47

[Michael Yoshitaka Erlewine [:mitcho]]

> Dāo, do you mean that we should just check for that DOM element's existence
> before trying to modify it, and return otherwise?

Dāo, nevermind this question. Once we move to a <broadcaster> it won't matter.

Comment 48

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: Patch v3

Comment 49

[Aza Raskin [:aza]]

Filled the follow up bug for fixing the CSS on Windows and Linux: https://bugzilla.mozilla.org/show_bug.cgi?id=595286

Comment 50

[Dão Gottwald [:dao]]

(In reply to comment #49)
> Filled the follow up bug for fixing the CSS on Windows and Linux:
> https://bugzilla.mozilla.org/show_bug.cgi?id=595286

The effect this would have on the tab bar on Linux is not acceptable, unless bug 595286 would be a beta 6 blocker.

Comment 51

[Dão Gottwald [:dao]]

(gnomestripe's tabview.png is 14px, so we're talking about a 6px height increase.)

Comment 52

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: Patch v3.1 with shorlander's winstripe specific tabview.png and updated css, no updated gnomestripe css/png yet

Comment 53

[Dão Gottwald [:dao]]

Comment on attachment 474153 [details] [diff] [review]
Patch v3.1 with shorlander's winstripe specific tabview.png and updated css, no updated gnomestripe css/png yet

>--- a/browser/themes/winstripe/browser/browser.css
>+++ b/browser/themes/winstripe/browser/browser.css

> #tabview-button {
>   list-style-image: url(chrome://browser/skin/tabview/tabview.png);
>+  -moz-image-region: rect(0, 90px, 20px, 72px);
>+}
>+
>+#tabview-button[groups="0"] {
>+  -moz-image-region: rect(0, 18px, 20px, 0);
>+}
>+
>+#tabview-button[groups="1"]{
>+  -moz-image-region: rect(0, 36px, 20px, 18px);
>+}
>+
>+#tabview-button[groups="2"]{
>+  -moz-image-region: rect(0, 54px, 20px, 36px);
>+}
>+
>+#tabview-button[groups="3"]{
>+  -moz-image-region: rect(0, 72px, 20px, 54px);
> }

nit: add a space before {

Isn't the height supposed to be 18px here, not 20px?

Looks like you didn't really drop the gnomestripe changes. r=me with that fixed

Comment 54

[Stephen Horlander [:shorlander]]

Attachment: Group Indication Icons (Linux)

Comment 56

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: Patch v3.2, with images and css for all three platform

Comment 57

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 474218 [details] [diff] [review]
Patch v3.2, with images and css for all three platform

a=beltzner, please file a follow up for tests or change in-litmus to ?

Comment 58

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: Patch for checkin

Comment 59

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/353a96262597

Comment 60

[pal-moz]

Attachment: screenshot

build : http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1284201987/


seems to be something wrong.

Comment 61

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #60)
> Created attachment 474361 [details]
> screenshot
> 
> build :
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1284201987/
> 
> 
> seems to be something wrong.

Please open a separate bug for that.

Comment 62

[pal-moz]

(In reply to comment #61)
> (In reply to comment #60)
> > Created attachment 474361 [details] [details]
> > screenshot
> > 
> > build :
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1284201987/
> > 
> > 
> > seems to be something wrong.
> 
> Please open a separate bug for that.

filed.
bug 595591

Comment 63

[tommyjb]

This just landed in the latest nightly, and I must say that the visual effect is way too subtle to my eyes.  I can barely tell the difference between the individual graphics (i.e., the 1, 2, 3 and 4 blocks).

Also, this implementation doesn't, in my opinion, solve the problem --- the problem being that Tab Candy hides tabs.  This implementation seems to simply tell the user whether there are other tab *groups*.  But the user needs to know whether there are invisible tabs (whether or not those tabs are in groups)!

Finally, I think the icon should simply glow when there are hidden tabs, and not glow when there aren't.  It seems pointless to me to show 1, 2, 3, or 4.  What if there are 5?  The user still sees 4.

Just my honest opinion.

Regards,
Tom

Comment 64

[Tan Wei Lin Jason [:Ryuji]]

Please make the visual effect more visible. Adding a ! icon to the Panorama Button is a good way to show this. Using current method of visualization require users to see properly at the Panorama button to have a good idea if there is other groups in Panorama.

Comment 65

[Tracy Walker [:tracy]]

As part of Bug Week, thanks to kbrosnan for the new test case in Litmus.

Litmus ID 12849

Comment 67

[antistress]

i agree with tommyjb (c#63) : it's too subtle and we only need to know that there is something else to check in Panorama, we don't need to have a number count.
Just apply a different color/shape to the Panorama icon when there are other groups (beware of color-impaired users) : the buttons must also be an indicator (like the bookmark star for instance).
Eventually add in the title bar something like "25 tabs in 3 groups" but it's not essential

Comment 68

[Grey Nicholson (they/them)]

(In reply to comment #7)
> Not sure if this has been suggested: I would like to see 1 TabCandy group = 1
> Operating System window. (Subgroups can be handled in a different way when
> they're implemented.) This doesn't obviate the need for an indicator, but means
> you can rely on simple indicators, like the colouring in groups possibility.
> 
> (Incidentally, this would also fix the problem where multiple windows combined
> with multiple tab groups becomes a usability nightmare.)

I agree that group==window is the only reasonably-simple mental model for handling multiple groups vs multiple windows. Bug 578512 discusses something similar.

Comment 69

[Tracy Walker [:tracy]]

verified on recent nightly builds of minefield