Re: [Usability] Rational for icons in button

On Fri, 2003-10-24 at 14:39, Ronny V. Vindenes wrote:
> On Fri, 2003-10-24 at 14:29, Julien Olivier wrote:
> > OK, that's clear enough now.
> > 
> > But what I still don't understand is: how is it more of a problem to
> > design icons for buttons than it is to design stock icons (for toolbars)
> > ?
> > 
> > What I mean is that theme developers (currently) also have to design
> > stock icons. Most of them don't do this (for the reasons you gave) and
> > we end up having nice GTK themes with clashing/ugly icons.
> > 
> > So if your point is: "it's very difficult for theme designers to create
> > _button_ icons and so we have to get rid of them", I don't really
> > understand why it would be more difficult to design _button_ icons than
> > stock icons.
> Because the button icons tend to be icons for abstract concepts that are
> hard to represent visually in a way that makes sense everywhere.
> Hmm..I guess what I'm really saying is that some concepts should be
> removed from the stock icon set, or at the very least be removed from
> buttons.
> stock icons typically used in menus and toolbars, like cut & paste or
> print, have natural physical representations. stock icons typically used
> in buttons, like apply, cancel, close or credits, does not have natural
> or universal representations. 
> Now take a dialog with the buttons email, save, print, and cancel. It
> has a mix of real and abstract action. So either you:
> - have an icon theme that implements icons for all those (let's pretend
> cancel can be represented universally)
> - have an icon theme that implements some of the icons and using default
> icons for the rest
> - remove abstract icons from the stock icons so you have no icon for the
> cancel button
> - remove all icons from all the buttons.

I understand what you mean, and I think you're right. One solution
though would be to show icons on buttons only if those icons are present
in the current icon theme (not falling back to the default icons). That
way, if an icon theme designer doesn't want to/can't design a matching
icon for cancel, the cancel button won't have any icon (instead of
having the default/clashing icon).

> >>From a visual & practical point of view I think the latter is better.
> > 
> > But if your point is: "it's difficult for theme designers to create any
> > icons", then I think it's off-topic.
> It is difficult, but that wasn't the point I was trying to make.
> My point is more that, because something is difficult and time consuming
> we should try to reduce the problem, since we know that not many will be
> able to do it.
> Let's say I have time and energy to make 10 icons, as it stands now I
> either have to do icons that are mostly used in dialog buttons or
> concentrate on icons used in menus and toolbars or try to find some mix.
> Either way it will mean that the theme won't be consistent if it doesn't
> match with the default stock icons. Even if I turn off icons in toolbars
> & menus and do the most common dialog button icons, I still have the
> problem that any stock icon could be used in a button. If no buttons had
> icons, then I can start by turning icons off everywhere, then add later
> add icons for common toolbar items and so on.
> At best icons in buttons add some color and familiarity to the
> interface, at worst they disrupt the flow of the design. I don't think
> we should rely on icons on buttons to make them more friendly or usable,
> that should come from consistent naming and placement.
> Basically, the whole stock icon thing is full of difficult problems, and
> I feel that disabling icons on buttons is a good place to start :)
> Or do you have any good reasons for keeping them? Maybe I'm forgetting
> some important aspect here?
> Perhaps this is only making sense in my head after a long week ;)

No, what you say makes a lot of sense :) But as I said upper, it might
be better to let the icon theme designer decide whether he wants button
icons or not, rather than removing all of them. But maybe I'm on

Julien Olivier <julo altern org>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]