Closed Bug 589010 Opened 9 years ago Closed 9 years ago

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

Categories

(Firefox Graveyard :: Panorama, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 4.0b7

People

(Reporter: aza, Assigned: aza)

References

Details

(Whiteboard: [in-litmus-bug-week])

Attachments

(10 files, 7 obsolete files)

57.70 KB, image/png
Details
13.75 KB, image/gif
Details
6.44 KB, image/png
Details
673.69 KB, application/x-photoshop
Details
750.69 KB, application/x-photoshop
Details
919 bytes, image/png
Details
1.17 KB, image/png
Details
715 bytes, image/png
Details
12.70 KB, patch
Details | Diff | Splinter Review
5.56 KB, image/jpeg
Details
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
Assigning but to Shorlander for mockup of different visual styles.
Assignee: nobody → shorlander
Blocks: 588980
Last note: Should have styling for all operating systems.
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?
Duplicate of this bug: 589050
(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.
Why not put tab candy groups in tabs themselves?
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.)
(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.
Sorry, that bug is actually 587538

https://bugzilla.mozilla.org/show_bug.cgi?id=587538
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
Attached image Pulsing Indicator
I don't necessarily think this is a good idea, but a slow pulsing icon is also an option.
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.)
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!"
(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.
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.
(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
(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?
(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 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)
(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
> 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.
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.
bug#590483 looks like a duplicate of this one
_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.
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.
Assignee: shorlander → aza
Priority: -- → P1
Do we need Linux icons, or do we just use Windows icons for that?
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?
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 :)
Attached patch Patch v1 (obsolete) — Splinter Review
Tested on Mac (but should work on Windows and Linux).
Attachment #473394 - Flags: feedback?(ian)
Attachment #473394 - Attachment is patch: true
Attachment #473394 - Attachment mime type: application/octet-stream → text/plain
Attached patch Patch v1.1 (obsolete) — Splinter Review
Forgot to remove two Util.log() calls.
Attachment #473394 - Attachment is obsolete: true
Attachment #473441 - Flags: feedback?(ian)
Attachment #473394 - Flags: feedback?(ian)
Attachment #473441 - Flags: feedback?(ian) → feedback?(mitcho)
Attachment #473441 - Attachment mime type: application/octet-stream → text/plain
Attachment #473441 - Attachment is patch: true
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.
Attachment #473441 - Flags: feedback?(mitcho) → feedback+
Attached patch Patch v2 (obsolete) — Splinter Review
Fixed the comments from Mitcho's feedback.
Attachment #473837 - Flags: review?(dolske)
Attachment #473441 - Attachment is obsolete: true
Attachment #473837 - Attachment is patch: true
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. :)
Attachment #473837 - Flags: review?(dolske) → review+
Meant to say "r+ with these changes", as well as starting with |groups="0"|. :-)
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.
Attachment #473837 - Flags: review-
You could probably pretty easily set the attribute on a <broadcaster> (which would always exist) and let tabview-button observe it.
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).
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.
(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?
(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.
> 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.
Attached patch Patch v3 (obsolete) — Splinter Review
Attachment #473837 - Attachment is obsolete: true
Attachment #474144 - Flags: review?(dao)
Blocks: 595286
Filled the follow up bug for fixing the CSS on Windows and Linux: https://bugzilla.mozilla.org/show_bug.cgi?id=595286
(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.
(gnomestripe's tabview.png is 14px, so we're talking about a 6px height increase.)
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
Attachment #474153 - Flags: review?(dao) → review+
Duplicate of this bug: 595286
blocking2.0: --- → ?
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 ?
Attachment #474218 - Flags: approval2.0? → approval2.0+
blocking2.0: ? → ---
Flags: in-litmus?
Attachment #474218 - Attachment is obsolete: true
Depends on: 593690
http://hg.mozilla.org/mozilla-central/rev/353a96262597
Status: NEW → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b6
(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.
Depends on: 595591
(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
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
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.
As part of Bug Week, thanks to kbrosnan for the new test case in Litmus.

Litmus ID 12849
Flags: in-litmus? → in-litmus+
Whiteboard: [in-litmus-bug-week]
Duplicate of this bug: 588382
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
(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.
verified on recent nightly builds of minefield
Status: RESOLVED → VERIFIED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.