GNOME Bugzilla – Bug 588668
Guideline on appropriate usage of icons in menu
Last modified: 2020-12-04 18:18:54 UTC
The change requested in bug 557469 has been commited and menu items are now displayed without icons by default. In http://bugzilla.gnome.org/show_bug.cgi?id=557469#c1 mpt proposed this: > Whether a menu item is faster to use with an icon depends much more on the > item than on the user. I think the guideline should be: A menu item should > have an icon only if it represents a dynamic object such as an application, > file, device, or user, or if it makes the items in that menu segment very > much more recognizable. (For examples of the latter, see > <http://mail.gnome.org/archives/usability/2006-February/msg00000.html>.) In an IRC conversation earlier today, I also wondered if "rotate clockwise / counterclockwise" menu items (in eog) could be considered as exceptions, as the visual hint provided by those icons is quite helpful.
"rotate clockwise / counterclockwise" menu items (in eog)" Idem for Back / Forward in Epiphany & Evince (both in menu bar & contextual menu) all the more these icons are displayed in toolbar therefore user is used to them and associates these actions with corresponding icons
I've been vacillating on the "or if it makes the items in that menu segment very much more recognizable" part, because (as antistress demonstrated in the previous comment) it is so subjective and it would be hard to tell when to stop. I think probably that should be left out of any written guidelines, so that application developers include icons for non-object items only if they are so confident in their design skills that they're wilfully going against the guidelines anyway. Separately, I think it would be useful to introduce a standard way of displaying guidelines for where Gnome deliberately goes against Windows. Here is an example: in Windows a menu item should have an icon if it has an equivalent toolbar button, but that is not true in Gnome.
I'm currently trying out no icons on buttons and in menus at all. The very first case where it made me stop and wonder was when I needed rotate-clockwise (in gimp, but could be anywhere you can rotate images). A term like clockwise or counter-clockwise is si much harder to understand than a well drawn arrow icon showing the direction. That doesn't need to be handled with a broad "or if it makes the items in that menu segment very much more recognizable". Instead I would propose: "or if the function is about movement or translation that can be clearly expressed with an arrow".
i guess that the decision to remove icons in menu will have some side-effects like putting some new buttons on the toolbar (for actions that would be better understood with an icon). Therefore it is possible that the problem will soon concern toolbars which could quickly become clutter
IMO,icons are of 2 types - Icons which quickly convey the meaning even when viewed the first time - Nonsensical icons , which can never be understood unless there is text accompanying it. Stripping down the first group of icons is not an ideal decision. Even the nonsensical icons ,in some places, can make sense over usage of the OS and also helps in identifying the items/options/buttons quicker. Quoting mpt from the mailing list mentioned above: "... Even then, I think icons should either be used for every item in a section (between the end of a menu and a separator, or between two menu separators),.. " This i believe would be the ideal solution. Proper arrangement of the options with icons and the options without icons. The menu arrangement also needs to be discussed , would that be a separate bug? I hope this bug covers those aspects too and not just icons.
I think I'm largely in agreement with comment 2 on this one. Could be revisited if we can find a way of expressing the guideline adequately, but I'm not sure that's possible.