After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 650392 - Make icon titles always visible instead of using the accordion effect
Make icon titles always visible instead of using the accordion effect
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: message-tray
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 655730 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-17 13:00 UTC by Gustavo Noronha (kov)
Modified: 2012-06-01 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Mockup of the tray without the accordion (413.58 KB, image/png)
2011-06-28 12:41 UTC, Allan Day
  Details
Accordian effect removal (9.63 KB, patch)
2011-06-28 15:19 UTC, Nguyen Thai Ngoc Duy
needs-work Details | Review
Remove accordion effect and highlight hovered item (14.64 KB, patch)
2011-06-29 10:10 UTC, Nguyen Thai Ngoc Duy
none Details | Review
Message tray screenshot with the previous patch (7.60 KB, image/png)
2011-06-29 10:13 UTC, Nguyen Thai Ngoc Duy
  Details
Updated patch with hovering effect (13.99 KB, patch)
2011-08-03 13:46 UTC, Nguyen Thai Ngoc Duy
none Details | Review

Description Gustavo Noronha (kov) 2011-05-17 13:00:22 UTC
It's hard to find what you are looking for if the icons are too similar or the same (say, when they are chat buddies who didn't set a picture for their accounts). I would suggest making the icons bigger and always displaying the title at the bottom. (P.S: I'm trying to split up #650154 by reporting what I could not find in a search)
Comment 1 John Stowers 2011-05-18 10:32:52 UTC
I agree. The accordion effect is really hard to use (with all precision poting devices...). The moust always has to be adjusted to the lef once the text becomes visible.
Comment 2 Will Riley 2011-06-09 21:27:32 UTC
+1, see my comments in bug 617224, comment 52
Comment 3 Nguyen Thai Ngoc Duy 2011-06-25 14:03:39 UTC
I think the delay proposal in bug 617224, comment 21 is fine and it does not cause without major changes in current design. I think delaying even half a second before expanding would give me enough time to locate an icon with my mouse.
Comment 4 Will Riley 2011-06-25 21:38:54 UTC
I disagree, I think the label should always be shown for all notifications. It makes it easier to select since the target size is bigger (Fitts' Law). I also feel like it's not dealing with the larger problem... the accordion effect just make things hard to select in a reasonable amount of time.
Comment 5 Jasper St. Pierre (not reading bugmail) 2011-06-25 22:04:40 UTC
(In reply to comment #4)
> I disagree, I think the label should always be shown for all notifications. It
> makes it easier to select since the target size is bigger (Fitts' Law). I also
> feel like it's not dealing with the larger problem... the accordion effect just
> make things hard to select in a reasonable amount of time.

If we showed the entire title of the notification, the whole bottom portion of the screen would be unusable. It wouldn't really solve anything else, though: while a "loss" from having to travel the length of the longest label may be bad, you'd have to traverse all of the labels to do anything in this model.

"Fitts' Law" isn't just "a larger click target means you have a larger area to click on it". Because, well, that's not a law, that's a tautology.
Comment 6 Will Riley 2011-06-25 22:24:36 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I disagree, I think the label should always be shown for all notifications. It
> > makes it easier to select since the target size is bigger (Fitts' Law). I also
> > feel like it's not dealing with the larger problem... the accordion effect just
> > make things hard to select in a reasonable amount of time.
> 
> If we showed the entire title of the notification, the whole bottom portion of
> the screen would be unusable. It wouldn't really solve anything else, though:
> while a "loss" from having to travel the length of the longest label may be
> bad, you'd have to traverse all of the labels to do anything in this model.
> 
> "Fitts' Law" isn't just "a larger click target means you have a larger area to
> click on it". Because, well, that's not a law, that's a tautology.

I don't see how it would make things unusable. What I described is pretty much the exact same thing as the old window list applet in gnome 2, just that it autohides. By showing the labels it would make it easier to get a sense of where the notifications are when the bar is closed (mainly for chat notifications). It would take around the same amount of time to reach an item when compared to showing just the icons; in the former case, the notifications will be farther but with bigger target areas, but in the latter case the notifications would be closer with a smaller target area.

When I mentioned Fitts' Law, I was trying to get at opening notifications when the bar was closed, since the mouse would be more distant from the notifications, and having to target such a small area from that kind of distance would be difficult.
Comment 7 Will Riley 2011-06-25 22:38:38 UTC
> in the former case, the notifications
> will be farther but with bigger target areas, but in the latter case the
> notifications would be closer with a smaller target area.

Err, when I wrote that, I meant that we'd be assuming the cursor was starting in the bottom right corner, sorry.
Comment 8 Allan Day 2011-06-28 12:41:39 UTC
Created attachment 190855 [details]
Mockup of the tray without the accordion

The accordion results in small moving click targets, which are error prone.

Sole reliance on icons for tray items also means that they can be difficult to understand. This can have the knock-on effect of obscuring the purpose of the tray. It just looks like a bunch of random icons.

So yeah, these issues could be alleviated by always displaying tray items' labels.
Comment 9 Nguyen Thai Ngoc Duy 2011-06-28 15:19:04 UTC
Created attachment 190876 [details] [review]
Accordian effect removal

A simple ripoff, seems to work for me (based on gnome-3.0.2).

Should we also define maximum width of a summary item and put an ellipsis at the end? "Pidgin Instant Messenger" looks horrible on the tray.
Comment 10 Dan Winship 2011-06-28 16:06:59 UTC
Comment on attachment 190876 [details] [review]
Accordian effect removal

>+        summaryItem.setTitleWidth(summaryItem.getTitleNaturalWidth());

If the summary items are going to each have their natural width (as they do in Allan's mockup), then we don't need this, or the associated methods in SummaryItem. Just let the _sourceTitleBin size itself normally.

>+        summaryItem.setEllipsization(Pango.EllipsizeMode.END);

You can set the correct ellipsization mode when you create _sourceTitle, and then you don't ever need to change it after that. (Although, this is only needed if there is a max width.)


Also, see the last part of the comment just above #summary-mode in gnome-theme.css. That should be removed, and summary-source and summary-title fixed to not be weird.

(It looks like his mockup probably also increases the spacing between summary items.)
Comment 11 Nguyen Thai Ngoc Duy 2011-06-29 02:10:33 UTC
Thanks. I will need some time to understand what that #summary-mode is for.

I think we should still keep hovering effect though, maybe text highlighting.. (like in the top bar)
Comment 12 Will Riley 2011-06-29 02:14:04 UTC
I agree, a hovering effect would be nice.
Comment 13 Nguyen Thai Ngoc Duy 2011-06-29 10:10:20 UTC
Created attachment 190917 [details] [review]
Remove accordion effect and highlight hovered item
Comment 14 Nguyen Thai Ngoc Duy 2011-06-29 10:13:07 UTC
Created attachment 190918 [details]
Message tray screenshot with the previous patch

The highlight effect turns fg color from #ccc to #fff on hovered item. It works great if the background is completely black. If the background is not, contrast  on unhovered items is not so good though. Not sure if it's OK this way.
Comment 15 Allan Day 2011-06-29 16:35:28 UTC
Though I do think the problems with the accordion are real, I'm not 100% sure about this solution. Adding the ui-review keyword.
Comment 16 Gustavo Noronha (kov) 2011-07-04 22:55:20 UTC
I would love to see bigger icons and the text bellow them, with 1 level of wrapping and ellipsis if necessary.
Comment 17 Rui Matos 2011-08-01 17:14:49 UTC
*** Bug 655730 has been marked as a duplicate of this bug. ***
Comment 18 Nguyen Thai Ngoc Duy 2011-08-03 13:46:40 UTC
Created attachment 193169 [details] [review]
Updated patch with hovering effect
Comment 19 Nguyen Thai Ngoc Duy 2011-08-03 13:47:57 UTC
(In reply to comment #18)
> Created an attachment (id=193169) [details] [review]
> Updated patch with hovering effect

Gaah.. _without_ hovering effect. Sorry.
Comment 20 Nguyen Thai Ngoc Duy 2011-10-01 02:12:22 UTC
A side effect from this patch. The hot spot to show up status bar is actually not a hot spot but a bottom line covering all icons in status bar.

Now that we show icons and text, this hot line is extended longer. As a result, status bar shows up more often when I move my mouse close to the right bottom corner.
Comment 21 xcorex 2011-11-28 14:43:49 UTC
I always missclick the icons, and dislike the icons "dancing". I'm not the only one annoyed... It is not "distraction free" (for me!) Here is a mockup with what I dream. http://i.imgur.com/C3wdg.png
Comment 22 xcorex 2011-11-28 15:48:00 UTC
I've found that https://bugzilla.gnome.org/show_bug.cgi?id=661077#c6 Fixed my complain. And did exactly the same thing I had design with the previous mockup.
Thanks a lot.
Comment 23 Jasper St. Pierre (not reading bugmail) 2012-06-01 11:25:53 UTC
Message tray redesign in progress.