Re: [lmi] using standard icon sizes and wxArtProvider

[Vaclav Slavik]

On Fri, 2008-08-29 at 13:38 +0000, Greg Chicares wrote:
> Here are icons distinguished by what seem to me to be tiny details:
>   http://tango.freedesktop.org/Tango_Showroom#OpenOffice.org
> I can distinguish Filmy, Hudba, and Obrázky at large size, and even
> at medium size Složky is recognizably different from them; but would
> they remain distinct at 16x16?

They wouldn't if simply downscaled. The 16x16 versions almost always
have to be designed separately, with much less detail (and the important
details enlarged). See how these Windows XP's icons look like at 16x16:

http://www.imagebin.eu/pics/91a14f1e0a3ac3d0f023c17db44d2ceb.png

> Let me ask, though, whether this really matters. AIUI, 16x16 icons,
> which tango calls "extra small", would be used mainly in menus. Must
> they really be quite distinct there? Probably the answer depends on
> the purpose of icons in menus. 

I always thought about them as navigation aids: recognizing a small,
familiar image is faster than reading even a short text label and if the
menu item you're looking for has an icon, you can navigate to it faster.

Also, some people (myself included) are spatially oriented and learn
frequently used menu commands by their _position_ in the menus. If a
menu is larger than just a few items, the icons serve as useful visual
"anchors" when looking for an item somewhere in the middle of the menu.

> http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines
> |
> | The Tango Project recommends keeping the number of menu items with
> | an icon to a minimum. Only the most frequently used menu items
> | should feature an icon. Otherwise the purpose of visual anchor is
> | nullified by introducing visual noise in the menu.

Thanks -- I knew I read this somewhere, but couldn't find it (it wasn't
in GNOME HIG as I expected and Google wasn't useful). This is related to
the spatial navigation function I wrote about above.

> Then again, is it really bad or unusual to display no icon next to
> any menuitem whatsoever?

It depends on the platform. OS X, for example, never uses any menu icons
(which you could argue is circumstantial evidence that usability
benefits of having the icons are relatively minor, given OS X's
usability record). On the other hand, GTK+/GNOME apps do use them for
"stock" actions and any app not using them looks a bit out of place. On
Windows, consistency among apps is nonexistent, so it's hard to say.

> > It's probably better to have 1,2,3 objects in the icon at this
> > size.
> 
> Let me be sure I understand. I could imagine several interpretations:
...
>  - 1, 2, or 3 superimposed..."things" (there's probably a technical
>    term for that, but I don't know it) like my little human figures?

This one is what I meant, sorry for being unclear.

>    I saw a tango theme for thunderbird that distinguishes "reply"
>    (an envelope with an arrow) from "reply to all" (same, but the
>    arrow points to two human silhouettes [0]). That seems clearer
>    than the old thunderbird icons (one envelope with a green arrow,
>    versus two envelopes with a blue-green arrow).

This is good icon, it has distinctive shape and is easily recognizable.
Let me show you how Evolution does the same for both menu and toolbar
items: http://www.imagebin.eu/pics/0cab433e67c03daf513ba690bd525aa7.png

Notice that it has distinctive shape and that the small size is much
simpler and contains only the distinguishing element (the double arrow).

>  But aren't you
>    recommending that we avoid superimposed "things"?

I wasn't clear, sorry. Superimposed things are a problem when they are
small, low contract or otherwise hard to recognize or when they are
"hidden" on top of the object and don't affect the overall shape
(compare Thunderbird icons with the edit-{case,cell,class} icons).

This is because good icons should be distinguishable not only by the
"content" and colors, but also by the overall shape of the icon. Here is
how GNOME HIG explains it:
 
http://library.gnome.org/devel/hig-book/stable/icons-design.html.en
| It is important to make it easy to visually distinguish icons that
| will be used together, for example toolbar icons and document icons.
| The human visual system is excellent at making rapid distinctions
| between items based on shape, thus a good way to help your users sort
| through a large number of icons is to use different shapes. You can
| see the shape of an icon most clearly by turning it into a silhouette:
| blacken all areas of the icon which are not transparent.

Usability "rules" like this are rarely 100% applicable (case in point:
GNOME's own MIME types icons use only a few different shapes), but it
makes sense for menus and, mainly, toolbars.

> > But in general, the counting approach worked for me we with the
> > existing icons (where you do the same, only with more complicated shapes
> > than the "rods"): the cardinality was clear even without knowing the
> > precise meaning of "class" and "case" terms in this domain.
> 
> Perhaps the basic approach is sensible, then: a common picture
> symbolizing the operation, with a superimposed cardinality
> signifier?

For toolbar icons, yes, I think so (assuming it affects the shape
visibly), but it would be trickier for menu icons.

> >> BTW, are there stock icons for menuitems on the MDI "Window" menu,
> > 
> > Not that I'm aware of -- Qt doesn't have them, GTK+ doesn't do MDI and
> > Windows doesn't have stock icons. Some GTK+ 
> 
> I think you were going to write more there.

I wanted to write that some GTK+ stock icons could be used for that
before realizing that it isn't true (there's nothing suitable except ofr
GTK_STOCK_CLOSE) and forgot to delete these two words...

Regards,
Vaclav