6-3 Icons


Human Interface, The: New Directions for Designing Interactive Systems
By Jef Raskin
Table of Contents
Chapter Six.  Navigation and Other Aspects of Humane Interfaces

Icons, those familiar little pictures used to identify buttons and other objects, are a shibboleth of modern interface design. Apple Computer, which is well known for its leadership in this field, advised us that "icons can contribute greatly to the clarity and attractiveness of an application. The use of icons also makes it much easier to translate programs into other languages. Wherever an explanation or label is needed, consider using an icon instead of text" (Apple Computer 1985, p. I-32). Later versions of the manual were not so dogmatic about using icons, but the damage had already been done.

Icons contribute to visual attractiveness of an interface and, under the appropriate circumstances, can contribute to clarity; however, the failings of icons have become clearer with time. For example, both the Mac and Windows 95 operating systems now provide aids to explain icons: When you point at the icon, a small text box appears that tells you what the icon stands for. The obvious reaction, which I have observed repeatedly when users first see this facility, is Why not just use the words in the first place? Why not indeed? Instead of icons explaining, we have found that icons often require explanation. If you wanted to obscure or to encode an idea to keep it from prying eyes, substituting icons for the words might not be a bad start. The problem with icons can be considered an issue of diminished visibility: The interface presents an icon, but the meaning of the icon is not visible, or it may give the wrong message to someone for whom the graphic is unfamiliar or has a different interpretation. For example, an icon that shows the palm of an upraised hand indicates "halt" in the United States but signifies "here's excrement in your face" in Greece (Horton 1994, p. 245).

You do not have to be an interface expert to be bothered by icons. A car reviewer's complaint is typical, "You had to get out the manual to understand the [radio's] controls there were no words on the buttons (you know, like 'volume'), only symbols" (Hotchkiss 1997, p. 14A).

Sometimes, the use of icons is rationalized on the grounds that they are language-independent, which is a useful property for software to have in an increasingly international marketplace, although, as noted, icons are not culturally independent. But even if an icon does not require translation, the linguistic aids and help screens used to explain it must be translated, nullifying any supposed advantage. With either icons or words, careful translation by an acculturated expert native speaker and writer of the language used by the target audience is required, as well as review by editors who have grown up and lived in the culture. Although words can be understood in at least one language, an icon is an equal-opportunity puzzle, potentially lacking comprehensibility across the entire spectrum of Earth's tongues.

In this example, the meaning of an icon was understood by only a minor subculture, to the detriment of nearly everybody else: On the Apple IIe, each connector on the back was identified by a distinctive icon. One especially enigmatic icon consisted of a horizontal line under which was a dashed three-segment line of the same total length (Figure 6.10). Of the thousand or so people I have asked, primarily at conferences, fewer than a dozen have known unequivocally its meaning and fewer still its derivation.

Figure 6.10. A particularly obscure icon.


The icon represents an oscilloscope trace: An oscilloscope (Figure 3.5) is a device used by electronics technicians to render electrical parameters, such as voltage, visible. The dashed line in Figure 6.10 is the zero volt position, and the solid line is what you would see on the display of the oscilloscope if you put the DC voltage from the power supply across its inputs.

In the preface to The Icon Book, author William Horton says, "I've used systems with graphical user interfaces for a decade and would prefer to click on an understandable image than to enter technojargon commands even if I could remember how to spell them" (Horton 1994). Of the two poor choices he presents, icons may be preferable, especially for the newcomer or the occasional user. However, he omits another choice: clicking on a button identified by a well-chosen word or two. To be fair to Mr. Horton, he states that in certain places, both words and icons are needed, and he correctly emphasizes the importance of testing, whether words or icons or both are used in an interface. Bob Horn (Jacobson 1999) has developed a style of combining the attributes of words and icons into combined symbols, which reinforces the dictum that text is often the best visual cue. We are expert at visually differentiating one word from another, and words can convey quite specific content. Ergonomic factors, such as case, font size, color, and other attributes of the text, are also important.

Mayhew (1992) cites a number of research studies on the use of icons. Unfortunately, most of the studies did not compare labels to icons. But from these and other studies, we can conclude that icons are most effective when there are at most a dozen of them and when at most a dozen are seen at one time. In addition, it is essential that they

  • Are visually distinct

  • Do a good job of representing the appropriate concept

  • Are presented at a reasonably large size, typically larger than a text label would be

In every study that considered the question, icons were demonstrated to be more difficult to understand than were labels, especially at first viewing, which contradicts one of the most frequently cited reasons for using icons, namely, comprehensibility for beginners. GUIs often present us with windows full of identical icons, each with a label. The icons are small and numerous, and there are dozens of different icons. The limited conditions under which icons are effective do not obtain in present computer systems.

Although it is true that tiny icons can take less screen space than labels, you have to ask: At what cost? The smaller a button, the longer it takes to operate it, and the more difficult it is to find; also, it is difficult to make a small icon distinctive. Another small point: Icons take more time to create than do words.

A major problem with icons is that it is often difficult to figure what to call them, whether for communicating with others, when writing about them, or even if you want to think about them in a verbal way. How do you sort or classify them; where do they fit in an index? For example, one icon on Macintosh keyboards looks somewhat like a diagram of a freeway clover-leaf interchange. In print, it has been called a cloverleaf, the propeller, or the pretzel. In this case, the key does have a name: In Apple manuals, it is called the Command key. This leads to the natural question as to why, on a keyboard that has explicitly labeled Shift, Option, and Return keys, did Apple not put the word Command on this key? What advantage does this icon confer on the user? How can you tell, by looking at it, that it is the Command key? The key with the little window on it on current Windows-specific keyboard falls into the same category of marketing triumphant over usability.

If we are to be consistent, pressing a key with a funny shape on it should simply type that funny shape into our document; keys with words perform other functions. (Arrow keys are probably a useful exception.) I suspect that the increase in sales due to such shenanigans is nil, whereas the difficulties that they cause for example, requiring a new character in the fonts used for writing the manuals of every product that will require mentioning that key are unending.

Trying to describe icons with words can lead to extreme verbal calisthenics. Consider the elaborate vocabulary that describes the heraldic symbols of English nobility. A shield might be emblazoned "Per pale or and vert a lion argent rampant."[*] Will we require such a language to describe icons when you phone up someone to get help in making a computer work properly?

[*] I believe the translation is: a shield divided into left and right halves, with the left half gold and the right half green. In the center of the green half is a silver image of a lion in heraldic style, set at about a 45 degree angle to the horizontal, with its head to the right and above.

There are, of course, many places where words fail. A color palette is such an example. One program on my computer offers the palette in words, presented in (mostly!) alphabetic order. Here is a portion of the list:


Blue Violet


Brick Red

Magenda [sic]

Burnt Orange


Burnt Sienna


Cadet Blue


Carnation Pink

Blue Green

Corn Flower

Blue Gray

Forest Green


Indian Red


Lemon Yellow



Green Blue


Green Yellow


What color is "Bittersweet"? What if you are botanically challenged and don't know a dandelion from a corn flower? The index for a collection of clip art is often effective when it has thumbnail representations of each image, but the list of categories of images, or any higher-level organization, should be text. An image of a number of a flowers does not convey the same information as the word "flowers." The image might represent "summer," "a listing of florists," or "hayfever sufferers chat room."

On the desktop of my Mac, I have exactly one often-used icon outlined in red; changing the border color of an icon is a system option. The color does make that particular icon easier to find among the dozen or so icons that clutter my desktop. I do not have the option, which I would prefer, of having one red word. Horton (1994) points out that "color coding can fail if you use too many colors or if there are too many icons in each color." He specifies that if the icons are close together, you should use no more than seven colors; if they are scattered about, you should use no more than four colors. He is right, and his suggested limits apply to the use of color with words, as well. But too many GUI designers seem not to be reading Horton.

Apple's early guidelines state that "To use the screen to its best advantage, Macintosh applications use graphics copiously, even in places where other applications use text. As much as possible, all commands, features, and parameters of an application, and all the user's data, appear as graphic objects on the screen" (Apple Computer, Inc. 1985, p. I-31). However, the best advantage for the user is to achieve clarity and ease of use. The tendency to overuse graphics has been an impediment to good interface design.

In creating a telecommunications interface, its designers had to indicate the following states: dialing, ringing, busy, no dial tone, excessive noise on line, attempting to connect, and connected. After some months of trying icons and testing them, they found it impossible to design a set of icons that would invariably convey the information to users. When consulted about this problem, I asked: How do you draw the sound of a busy signal? I suggested that they use the list of words they had provided instead of icons; they did, and testing confirmed the utility of the solution. That they did not see this for themselves is probably a result of the effective "brainwashing" of interface guidelines such as those quoted.

Using icons sometimes prevents designers from seeing the possibility of direct manipulation. To discard a document in most GUIs, you drag its icon to the wastebasket or trash can. If the document is visible at the time, why not drag the document itself? In a case like this, the icon is an unnecessary proxy and a level of abstraction you must learn and understand. We can do even better and avoid having a trash icon altogether: Why not simply select the document to be erased and use the Delete key? That would make deleting a document monotonous with other forms of deletion.

Icons seduce designers into looking for a representation, model, or analog for the task and then implementing an operation on the representation instead of the thing itself. On occasions such as the one just mentioned, this is a design error. Sometimes, icons seduce designers into creating yet more icons. A bibliographic database application designer asked me to comment on the quality of his team's choice of icons. I responded that most people who use bibliographies can read and that therefore words might be preferred. Figure 6.11 shows a few of the dozens of icons they had created. See whether you can decipher them (footnoted answers on next page).[5]

[5] Answers: display the main menu, change language, display information about this facility, browse, thesaurus, reduce the number of returned results, display information about the selected object's location (for example, the URL of a web page or a shelf location in a library), retrieve items in search for which both Boolean expressions are true, international standard book number, keyword, subject, title, clear current information, reduce view of current information, display a brief list of current search results, show all fields, show the results of the current search, author.

Figure 6.11. Bibliographic icons (from http://www.scran.ac.uk/iconstd/ 8 June, 2001). Many are inscrutable, as you can ascertain by looking at each and deciding what bibliographic category or operation it is supposed to represent.


The clearest ones are probably Menu, AND, and, especially if you are professionally interested in books, ISBN. Having read the intended interpretation of each only two days before writing this paragraph, I find that I still cannot remember what they all mean, especially the one that looks to me like a beach ball.

To summarize: Surprisingly, icons violate the principle of visibility: It is their meanings that are not visible. Use icons only in the few situations where research has shown them to be advantageous. Otherwise, words are better.


    The Humane Interface. New Directions for Designing Interactive Systems ACM Press Series
    The Humane Interface. New Directions for Designing Interactive Systems ACM Press Series
    ISBN: 1591403723
    EAN: N/A
    Year: 2000
    Pages: 54

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net