Iconitis

[Stan Switzer]

In article <4971 at pbhyf.PacBell.COM> rob at PacBell.COM (Rob Bernardo) writes:
> +I've also seen a lot of effort expended to come up with an icon for 'Help'.
> +Those people got mad when I suggested the string 'Help' would do nicely.
> In any case, with this distinction in mind, we might rephrase what Walter
> Bright had to say as:
> 
> 	1. Use only an icon that clearly depicts the intended referent,
> 	or else it isn't a good icon.
> 	
> 	2. Use an icon if it communicates more effectively than a symbol
> 	purely sign (such as a word or letter).
> 
> In other words, using an icon for the sake of using an icon is not
> using an icon for the sake of better communication.

[This is an interesting discussion, but I'm directing folowups to
comp.windows.misc]

The trouble with icons is that they depict things (i.e. files or
"closed" windows) reasonably well and actions (commands) rather badly.
Sometimes a gesture serves well as a verb, as the "drag a file over
the trashcan" style indicates.  In general, though, what sense can I
make out of a "printer" icon?  Will clicking it display the printer
queue, pop up an image of a status panel, or ship some file (which
file?) to the printer?  None of this is *really* self-evident.

Don't get me wrong.  Graphical, mouse driven interfaces can be quite
wonderful. As with any other software construct, it really comes down
to the power, predictability, and believability of the illusion of the
user interface.  All programming is magic, after all: the creation of
an illusory reality -- which is why the Model-View-Controller paradigm
works so well.

On a related note (and one which *does* belong in comp.lang.c), I
always wondered why some people put ones and zeros on power switches
and others use #defines for ON and OFF.  Each practice is equally
misguided.

Stan Switzer  sjs at ctt.bellcore.com