Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

  (email not shown publicly)
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)

I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Sunday August 14, 2005
07:50 PM

the issue with icons

[ #26281 ]

We use Kwiki::Icons::Crystal at work, because (to quote John) "otherwise the toolbar ends up taking two rows!" I don't want a multi-row toolbar, but neither do I want a huge array of tiny icons that often have little bearing on their link's action.

See, the issue with icons is this: it's hard to make icons that are actually iconic and suggest, to the user, what they mean. If you want to make an icon for a text editing application, it might be pretty straightforward: some text, maybe on a piece of paper, maybe with a pencil near it. An icon for a video player is simple: a length of film, a projector, maybe a TV. How do you make an icon for a concept like "show diffs?" Mac OS provides a good one, actually, although it doesn't scale well to 16 by 16. What about "keywords?"

Now, I think that someone could come up with an icon for a lot of these concepts, given some time and creativity. The problem is that there's a secret third requirement: the ability to transform the idea into an icon. Most programmers don't have that ability, which means that they resort to the Worst Possible Option: they find the free icon sets (GNOME, Crystal, etc) and look for icons that are sort of kind of indicative of what they want, then use those.

It leads to users hovering over unhelpful icons, reading the tooltip, and then moving on to try the next icon until the right one is found. Now the user has to learn an association between each icon and its purpose, and then he must remember it. This defeats the entire idea of creating automatically understood visual clues.

I keep trying to make friends with someone who'll want to make icons to my specifications, but so far it hasn't worked out. Until then, I'm sticking with text.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Yes, it's a tough problem. I used to work with a bunch of talented graphic designers and they all hated having to do icons. It's hard enough to come up with a number of icons that are each meaningful in their own right. On top of that though, giving them all a common theme so that they look like they belong together is extremely difficult.

    The OpenOffice toolbars are an uninspiring collection and the buttons in the Firefox default theme are another hodgepodge of apparently unrelated images.
  • It leads to users hovering over unhelpful icons, reading the tooltip, and then moving on to try the next icon until the right one is found.

    This is also known as “mystery meat navigation.”

    I suggest short textual monikers, even if they are somewhat cryptic without a description, and providing such a description using a tooltip. The benefit is that reading a well-chosen moniker helps you recall its description.

    Icons cannot offer this linguistic association. With them, it is necessary to m