GNOME Bugzilla – Bug 646927
Removing cropping from current-app-icon
Last modified: 2014-04-26 16:51:27 UTC
Created attachment 185325 [details] samples of app icons adversely affected by crops The icon for the currently-focused app is cropped in on the top, bottom, and right sides, making app icons hard to distinguish from one another. In some cases, several apps are indistinguishable from one another as a group, while in many others, they are simply unrecognizable as themselves. This stems directly from only showing the center portion of each icon. Many icons' exterior outlines form a key piece to their recognizability factor: Gwibber's "speech bubble," Banshee's "note," Brasero's "flame," etc. Cropping off three sides removes this information, making the icon unusable as a visual reference point. In addition, some icons look too much like each other to be helpful. Such is the case for suites of related apps, which use the same overall design but add on distinguishing marks per-app, such as QtLinguist, QtDesigner, and QtAssistant. It can also happen with unrelated apps -- e.g., the cropped Gwibber icon and the cropped Epiphany icon both become nearly-identical globes.
I believe this is working as designed. Admittedly, it works better for some icons than for others.
It's not acceptable for multiple app icons to be broken simply because others are still readable. "Works better for some than for others" is, still, a defect.
I do not think that is such an issue: there is few icons which center is the same, even if you've got good examples, at least gwibber vs epiphany. But these are really rare cases, and you have the title of the application written over it, which is quite distinctive. Also, since then, Qt gained different icons for its apps. Know suites of related apps usually have distinctive colors or forms at least. If the suite icons can only be differentiated by the cropped area, that's a serious usability issues. I still agree with the issue ... maybe we could reduce the zooming a bit, but that has been part of the design since a long time, and everybody has been used to it, don't you think?
Hi. Signs of life! I'm really sorry, but I've read it through and I guess I'm not entirely sure where you're at in your comment: first you agree that I have shown legitimate examples where the effect impedes usability, but you say it is not an issue. But below that, you say you agree with it. Is there any chance I could convince you to clarify for me? Like what other info is needed? Also, it's totally orthogonal whether or not people are used to the effect, since it is demonstrably detrimental. As in comment #2, the fact that the effect doesn't damage 100% of icons doesn't justify the breakage for those icons that are affected. This is a purely cosmetic effect; fixing it does not cost any functionality -- whereas the status quo *does* cost functionality for a finite set of application icons. We've shown where it's causing harm to the user experience. This is an "every detail matters" issue, to borrow/steal Allan's phrase.
I'll try to explain better :) What I was trying to tell is the text is "overlayed" on the icon, so it helps with the last cases that are problematic: its start is part of the icon, so the eye is strained to identify the application using both, contrary to a regular icon which is detached from its label where the eye scans the icon, then the label or the center of icon+label. That's why I'm telling people are used to it: there is no duplicate to this bug, and I suspect the identification is already good. I do not think it is purely cosmetical, as the icon gets more prominent in the UI, it helps identifying quicker. The smaller the icon gets, the more precise the eye needs to focus to understand the active application. With today's size, you get the color of the icon when your eye is near the top of the screen: try to fix a point in your screen (or top of the screen if it is really big): you should notice a dominant color for most icons. Now, try with a 1.0 factor in panel.js#_sync (instead of get_faded_icon(2 * PANEL_ICON_SIZE)): I'm not able to find the icon anymore. eye Where you would put it if it were not cropped anymore? If you do not crop the label, it drains the eye towards the first letters instead of conveying the icon intention at the current location or make the text look bad (for example Skype has text inside the icon and is very bright, so you get two "S" near one an other and you feel it's buggy), and if you put it next to the label like a regular button, you do not feel the click target as large: like it is done today its clear its the same button because they are blended. As an intermediate step, we could adjust the zoom factor further just a bit: the cropped part seems to be ~20% on top/bottom edges at this point, and only ~12% of gnome/tango icons (because of their high padding). Let's ear the original design decision anyway ;)
So you're talking about the placing of the icon behind the first letter of the application name label. In that case, yes, I would say placing the icon *next to* the text label is the correct thing to do. The Skype example is a good one; there are other icons that incorporate a letter/glyph too (Emacs, Xournal, Parcellite, Sigil, a whole bunch of games, for some reason...). I don't really see what the advantage is in reducing the zoom to a smaller amount but keeping it non-zero. As near as I can tell, there is no added value in having the zoom/crop overlay effect at all. As if it's there because the toolkit now supports it, and somebody wanted to see how it would look. But we don't crop out icons and composite text labels on top of them anywhere else in the UI -- switcher, Activities overview, etc. Besides, the more I stare at this, the more I realize that cropping into the icon and leaving no padding subtly breaks the metaphor used everywhere else in the panel -- it looks as if the app icon is floating behind the panel. All of the other text and status icons are clearly either within or on top of it.
Also, on a side note, I'd say that cropping off the sides of the icon breaks the GNOME HIG guidelines for icons: http://developer.gnome.org/hig-book/3.5/icons-design.html.en ...specifically the "Make Icon Silhouettes Distinct" bullet point, and also in a way it falls under the "may render the icon unintelligible when it is shrunk in size" problem area.
This is still working as designed, and unless we get a design update it won't change; leaving an old bug open won't change that. If you still feel passionate about this issue, trying to get in touch with the design-team and discuss alternatives is a much better option.
As I have stated multiple times, there are demonstrable PROBLEMS caused by "the design", so saying "working as designed = NOTABUG" is nonsense.
(In reply to comment #9) > As I have stated multiple times, there are demonstrable PROBLEMS caused by "the > design", so saying "working as designed = NOTABUG" is nonsense. No, it is not. Do you really think leaving this bug open indefinitely (burried among >1500 other reports) will change anything? Apparently this is a big issue for you (up to the point of SHOUTING), but nobody in three years has shared your concern (not in this bug report, or any of the >1500 other reports). So I can only repeat myself: if you want to see this addressed, you need to convince the design team first. Until that happens, the icon will stay as it is - keeping the bug around just to pretend otherwise would just be silly and dishonest.
If your argument is that it's a "design bug" rather than an "implementation bug" then the appropriate action is to reassign the bug to a different module. How do I do that? Who does that? Is that even possible? But I already showed multiple examples of the harm caused; that is what defines it as a bug. Saying it's not a bug because you don't care about those situations is dishonest. It's a bug - by definition - because it breaks things.
And in case it's not clear from the above, it's the ignoring of a bug report that makes it aggravating, not the issue itself.
(In reply to comment #11) > If your argument is that it's a "design bug" rather than an "implementation > bug" then the appropriate action is to reassign the bug to a different module. There is no design module to reassign. And no, I'm not arguing that it's a "design bug". I'm arguing that in three years, there has been exactly 1 (in words: _ONE_) user considering this an issue. So I'm arguing that you need to convince designers that this is an actual bug in the first place (preferable with an alternative design).