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 583352 - set buttons_have_icons=false by default
set buttons_have_icons=false by default
Status: RESOLVED FIXED
Product: libgnome
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libgnome maintainer
libgnome maintainer
: 583354 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-05-20 17:34 UTC by William Jon McCann
Modified: 2009-11-27 15:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description William Jon McCann 2009-05-20 17:34:17 UTC
I think we should consider making /desktop/gnome/interface/buttons_have_icons
default to false.
Comment 1 Christian Persch 2009-05-20 17:58:17 UTC
*** Bug 583354 has been marked as a duplicate of this bug. ***
Comment 2 Andreas Nilsson 2009-05-20 23:36:20 UTC
Not going to touch any of the issues of what could be faster, more usable, etc. that I'm sure will come up, but only focus on the pure ascetic reasons on why I think this is a good idea:

* the text in the buttons would no longer be pushed off too far to the right, instead the text would rest peacefully in the center of the button. [1]

* buttons would align better with other controls next to them, such as combobuttons and text entrys. [2]

* the labels in buttons that are aligned vertically would no longer look off and uneven. [3]

* It would look clean and slick, as opposed to cute.

* More artist manpower could be spent on drawing sweet application icons and less icons in action buttons. (I guess that's kind of a ascetic reason as well :) )

1. http://www.andreasn.se/diverse/temp/button-icons1.png
2. http://www.andreasn.se/diverse/temp/button-icons2.png
3. http://www.andreasn.se/diverse/temp/button-icons3.png
Comment 3 Andreas Nilsson 2009-05-21 17:19:04 UTC
Some more thoughts on this:

* there would be a logic to dialogs such as the "run executable" dialog in Nautilus [1] (Q: why is Cancel the only button with a icon in it? A: The artists couldn't come up with illustrations to fit the other verbs), or the Replace dialog in Inkscape (and others) [2]
This worked in pre-2.0-GNOME where you would usually have OK/Cancel as a choice, where both have suitable stock icons, this is no longer the case.

1. http://www.andreasn.se/diverse/temp/button-icons4.png
2. http://www.andreasn.se/diverse/temp/button-icons5.png
Comment 4 Bryan W Clark 2009-05-21 19:46:12 UTC
I think I have a similar stance here as I do with bug 557469.  Icons should be used sparingly to create real value.

At the same time I guess my initial thoughts here are more about the overall goal of button icons.  Andreas' example of the cancel button is something I think that offers a lot to examine.

There are a lot of styling issues with the icons making buttons larger than they would be normally.  Remove icons altogether is one way to solve this issue but doesn't seem like the only solution available.

I do think there is real value to a consistent "Cancel" indicator.  I don't know that this has to be an icon on the button.  A cancel button could use other visual cues to indicate that it is a cancel action.  Using a background colour or different styling could be an option that doesn't resize the button but provides a way to indicate a common button.

For example, taking andreas' button icons could be something like this:
http://www.gnome.org/~clarkbw/tmp/red-cancel-button.png

There would be some obvious theme implications with that kind of scheme that would require a lot of thought.
Comment 5 William Jon McCann 2009-07-14 16:06:51 UTC
After further discussion with the gnome art community and the release team (at GUADEC and on IRC) I've committed the change.  It still may be interesting to explore use of a different Cancel button but perhaps that is best done in another bug.

Anyone who does not like the new default may change the gconf setting to their own preference.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2009-07-20 18:41:09 UTC
(In reply to comment #5)
> After further discussion with the gnome art community and the release team (at
> GUADEC and on IRC) I've committed the change.  It still may be interesting to
> explore use of a different Cancel button but perhaps that is best done in
> another bug.
> 
> Anyone who does not like the new default may change the gconf setting to their
> own preference.
> 

That would have been worth a wider discussion. Couln't we (Gnome) use a poll for this. I don't feel like we knowknow that the majority will like it and it feels pointless to change it, if the first thing everyone does is to change it back.
Comment 7 Andreas Nilsson 2009-07-20 19:14:01 UTC
I'm afraid a poll on such a trivial UI matter would be a terrible idea.

People never like change for sure, but one of our goals for 3.0 a cleaner and more well balanced interface. This is one of the steps, and I hope it will turn out as the better choice in the end. I don't think we should be afraid to fail every once in a while, and this one is easy to change back. :)
Comment 8 Vish 2009-08-01 15:53:02 UTC
Now that this has been "fixed" , what about gnome 3.0?
Is there going to be a gconf option to have icons displayed or simply no icons
at all with no gconf option?

I agree that having icons for some buttons while not having icons for others does create an imbalance.

But more needs to be done [ in the button ] to indicate a cancel or a delete .
Giving such buttons a hint of red would be better as a visual hint. a hint of green for the save buttons... 
Something in the buttons themselves , to be more visually stimulating and the actions instantly recognizable, than reading the buttons to recognize them.
Comment 9 Andreas Nilsson 2009-08-01 17:29:31 UTC
(In reply to comment #8)
> Now that this has been "fixed" , what about gnome 3.0?
> Is there going to be a gconf option to have icons displayed or simply no icons
> at all with no gconf option?

Yes, you can set /desktop/gnome/interface/buttons_have_icons to "true" if you still want icons in your buttons.

> But more needs to be done [ in the button ] to indicate a cancel or a delete .
> Giving such buttons a hint of red would be better as a visual hint. a hint of
> green for the save buttons... 
> Something in the buttons themselves , to be more visually stimulating and the
> actions instantly recognizable, than reading the buttons to recognize them.

While colors are indeed very quick to recognize, text skimming speed for adults is around 400-700 words per minute. [1]
Colored buttona would be neat, but needs to be filed as a separate bug report/feature request.

1. http://en.wikipedia.org/wiki/Reading_%28process%29#Reading_rate
Comment 10 Vish 2009-08-01 18:27:25 UTC
(In reply to comment #9)
> While colors are indeed very quick to recognize, text skimming speed for adults
> is around 400-700 words per minute. [1]

Text skimming applies only for adults well-versed in the language , 
But for non-native users , kids, visually-challenged individuals , this is not the same rate.

I do understand the words are just minimal , but having a color hint of the action buttons will be a better visual stimulus , IMO.

The dialogues windows are now monotonous/boring , the icons had added a bit of visual hint/bling [whatever people want to call it]

So, i felt the dialogues need a face lift ;)

> Colored buttona would be neat, but needs to be filed as a separate bug
> report/feature request.
 
Anyways , I filed a separate request.
http://bugzilla.gnome.org/show_bug.cgi?id=590473

> Yes, you can set /desktop/gnome/interface/buttons_have_icons to "true" if you
> still want icons in your buttons.

I realize this option is present *now* , 
I was wondering about gnome 3.0. if that would be still available , or did you answer about gnome 3.0 ... if so great :)
Comment 11 Tobias Wolf 2009-08-02 12:58:44 UTC
(In reply to comment #9)

> While colors are indeed very quick to recognize, text skimming speed for adults
> is around 400-700 words per minute. [1]
> Colored buttona would be neat, but needs to be filed as a separate bug
> report/feature request.
> 
> 1. http://en.wikipedia.org/wiki/Reading_%28process%29#Reading_rate

I don’t think this figure for text skimming applies to discrimination of buttons by text only or by text and icon. Text skimming is evaluated by skimming runs of text in paragraphs and reproducing the contents afterwards.

There must be plenty of usability study results pertaining to this bug. This study doesn’t corroborate your point at all.
Comment 12 Benjamin Otte (Company) 2009-08-04 19:59:04 UTC
I'm just gonna dump http://www.uie.com/brainsparks/2009/06/28/old-news-about-icons/ here.

I still do think that response buttons in dialog should always have icons.
As it is, everybody agrees that cancel buttons are less discoverable with this change than they were without, so I'd consider this a regression.
Comment 13 Jean-François Fortin Tam 2009-09-01 12:00:22 UTC
This decision creates side-effects like bug #593736. How are we supposed to fix that?
Comment 14 Thomas D Ahle 2009-11-27 15:21:36 UTC
As a developer this has totally taken me be surprise. Suddenly only half of the buttons in my app (all the none stock) have icons, which looks awful.

I'm quite uncertain what to do here. The HIG states nothing.
If the problem is the size of the icons, should I just let the glitch wait tempoarily until gnome 2.30 brings smaller icons?
Or should I remove the rest of my icons?
And in that case, should I color important buttons red or green instead of the icons?