Icon (Functional)

A.K.A.

Symbol

Examples

Example of Glyph Font Navigation, With Labels

Examples of Glyph Font Icons on Buttons with Labels

Example of an Icon­Based Image Used as Navigation With No Associated Text

Problem

The system needs to present a way for the user to access commonly used functions like saving work, printing, emailing, etc., yet space on the interface is too limited to permit buttons containing text.

Solution

Display a small graphic (an icon) that looks clickable and communicates the meaning of the feature functionality with the image itself.

How to Use

Use when…

Conditions for using an icon — All of the following conditions should be present to warrant using a functional icon

• Space is too limited to permit a text­-based interaction element (e.g. button or link).
• The feature functionality is common enough to be recognizable in icon form.
• The feature functionality is based on a single concept (e.g. save, print, email, etc.).
• The proposed location for the icon is a location in the interface where the user would expect access to the feature functionality to exist.

Don’t use when…

Do not use an icon if all of the above conditions cannot be met.

Rationale

User Perception and Recognition

The Premise of Visual Recognition — The use of icons is predicated on the idea that the concepts represented by the icon will be interchangeably understandable to the user as if they had encountered the same concept represented expressed in text. This means that the icon is only successful if the label is not necessary for understanding. It also means that users should be able to understand its meaning without having to remember it from the last time the discovered its meaning through usage. User interface elements should always follow the primary heuristic of recognition rather than recall.

Conceptual Expression Limitations — The essential requirement of a functional icon is its ability communicate the nature of the feature functionality based on the graphic alone, without any supporting text. Given that the available space functional icons is almost always small (commonly 16 x 16 pixels), icon graphics are very limited in the number of concepts they can present. The most successful icons only express a single concept, commonly in verb form (e.g. save, print, email). As additional concepts are added (e.g. Save as website), the ability for the icon to effectively communicate the functionality quickly diminishes. To illustrate this point, consider the following set of icons representing documents, appearing here in order from simple to complex:

Document — This icon represents the single concept of “a document.” The image is easily recognizable as a document, instantaneously communicating the expected result of clicking on it: Opening a document.

Word Document — This icon represents two concepts: It’s a document and one from Microsoft Word. The image is somewhat recognizable as a document as it is partially obscured by the “Word” concept. Recognition of the meaning of this object is partially dependent on repeated usage.

Word Web Document — This icon represents three concepts: It’s a document, it’s a Word document, and one that is a Web based document. At 16 x 16 pixels, the three image elements of the document, the “W” (for Word), and the globe (for the Web) are barely recognizable. Only the “W” stands out as the top most element. Recognition of the meaning of this object is almost entirely dependent on repeated usage, and only within the context of those user who use Microsoft Word.

Word Web Document with Embedded Images — This icon represents for concepts: It’s a document, it’s a Word document, one that is a Web based document with images embedded, not referenced. At 16 x 16 pixels, the icon cannot even display all four concepts as images. The image of the document is present, though completely obscured. The globe (for the Web) is entirely missing. The picture frame, representing embedded images, is not visible enough to be recognizable. For most Word users, this image represents little more than a “Word something” and is entirely dependent on repeated usage or a explanatory label.

The Role of Perception — As human beings, only about 1/1000 of 1% of visual information survives our short term memories. When make up the difference with information from other sources:

·       We remember most what interests us most.

·       If multiple interpretations are possible, we first assume an image to be the one which is most familiar to us, especially images that carry archetypal meanings.

·       We fill in visual gaps to perceive a familiar object, even if it wasn’t intended.

·       We are influenced by what our sub conscience interprets and infers.

·       We interpret meaning of images, especially simple ones, based on the context in which they appear.

If these aspects of human perception are not taken into account, an icon is far more likely to fail than succeed it communicating it’s meaning.

The Influence of Archetypal Images — In Jungian psychology, an inherited pattern of thought or symbolic imagery derived from the past collective experience and present in the individual unconscious. Consider the following image:

Even in black, this simple graphic will always communicate the sun on the horizon, perhaps even the more complex concept of “a new day.” Such powerful archetypal images must be taken into account when creating an icon. As much as you may try to frame the icon as being something else, the archetype will always win.

The Influence of Context — The context in which an icon appears can greatly influence perception. Consider the following icon:

In a hospital hallway, this icon would most likely be perceived as meaning Restaurant or Cafe. On a restaurant menu, it would more likely be perceived as Beverages. In a grocery store, the icon would probably be perceived as Coffee, unless that store is an a country that primarily drinks tea, in which case, Tea would be the first interpretation. The same contextual limitations come into play in an interface. Icons may easily carry different meanings in a tool bar than they would on the page.

The Influence of Other Icons — An icon appearing by itself can carry a different meaning than when it appears adjacent to other icons. Consider how the airplane icon below changes in meaning when placed next to other icons:

The airplane icon changes its perceived meaning when it is placed next to other related icons, even another version of itself.

The Influence of Established Common Computer Interfaces — Some icons are so ubiquitous in common user interfaces, their established meaning simply cannot be changed. This also means that the concept represented by that icon cannot be communicated with any other icon other than the established icon. One of the most glaring examples of this phenomenon is the icon used for Save, as in saving a document:

The image represented in this icon is a three and half inch floppy disk, a method of saving files that is so outdated and obsolete, that many users of a younger generation would not recognize it. Yet, it is so ubiquitously used in user interfaces to mean Save, designers dare not use any other icon in its place, nor should they dare using the icon to represent any other functionality than Save.

Usability and User Research

Microsoft Recognizes That Labels Work Better Than Icons:

What follows is an article from a former Microsoft Program Manager who witnessed usability testing on Microsoft Outlook. In the article, he reports on the significance of the findings regarding the toolbar icons. 

My first experience in Office was working as an intern program manager on Outlook 98.  During that summer I learned one of the key usability lessons that carried over into the DNA of the Ribbon: the importance of labels.

Different fixes were tried: new icons, rearrangement of the icons, positioning icons under the menus from which the commands came from.  In the end, one change caused a total turnaround: labeling the important toolbar buttons.  Almost immediately, the toolbars were a big hit and everyone at all skill levels starting using them.

It’s not really any big surprise if you think about it.  It’s pretty rare in the real world that we rely on iconography alone to represent ideas.  Bathroom doors generally have an icon of a man and the word “Men.”  Stop signs have the word “Stop” on them.  On the other hand, I can recount dozens of experiences where the icon-only design of something has frustrated me.  On a recent vacation, we spent probably 10 minutes trying to figure out how to turn an oven on before just giving up because we couldn’t tell what any of the icons meant.  I have buttons in my car that I have no idea what they do because the icon is so cryptic.  I guess I could look them up in the manual…

It’s not that icons can’t work by themselves, but that most people have a fairly limited vocabulary.  Floppy disk = save.  Printer = print.  Play, Pause, Stop, Forward, Back all got defined by tape players from the 1980s.  And, yes, if an icon is ideographic enough, it can be infused with meaning and remembered–take the “Apple” menu in Mac OS, for example.  But the richness is just not there relative to human language.  (Especially considering that I already know how to speak English; it’s a lot of work to learn how to speak “Iconese” on top of that.)

This is one of those areas in which Windows applications should learn from web design.  Why do people find many web sites straightforward to use?  One reason undoubtedly is because everything is labeled.  People never need to decipher cryptic rows of 16×16 unlabeled icons in order to be successful using a web site.  Yet, the unlabeled toolbar remains a staple of most Windows programs today.

Web sites do often pay for their verbosity by requiring visitors to scroll the page in order to see the entire content area.  Toolbars, on the other hand, have the advantage of extreme density and more predictable layout.

The Office 12 Ribbon is designed to exploit the importance of labels in a way that doesn’t compromise the predictability of a fixed UI location at the top of the screen.

We designed a layout and scaling system to provide as many opportunities to label commands as possible–especially as screen resolutions increase.  At the same time, the rich layouts of the Ribbon allow the density afforded by skipping labels on those items which work just as well as unlabeled icons (Bold, Italic, Center, etc.)

I hope the days in which rows of 16×16 unlabeled icons represent “standard UI” will soon be in the past.

(Citation)

[/expand]

A Case Study of How Icons Can Be Misconstrued

In 1995, Nielsen Norman Group tested several iterations of icons for Sun Microsystems. The finding underscore the importance of simplicity and validate many of the guidelines presented in the design pattern.

http://www.nngroup.com/articles/icon-usability-1995-sun-microsystems-website/

International Considerations

Icons Can Have Different Meaning in Different Cultures

It is very important to remember that icons can carry different meanings in different cultures. While a print icon can be cross-cultural because it’s based on the image of an actual printer, a common device in all countries, icons that depend on metaphor can easily convey an unintended meaning in a different culture. Icons that attempt to communicate carry multiple concepts (or even single concepts) based on metaphor must be evaluated across all applicable cultures to validate that the intended meaning is being communicated effectively.

Accessibility Requirements

Requirements Specific to Functional Icons

IF the icon is presented as a glyph font with no associated text-­based label:

• The actual icon text character must be hidden to screen readers.
• A text equivalent specific to the icon's contextual meaning must be supplied in a neighboring span tag using the "sr­-only" CSS class.

<a href="#">
   <span class="icon-nav">
      <span class="icon-calendar" aria-hidden="true"></span>
   <span class="sr-only">Calendar</span> </span>
</a>

• The "icon-­nav" span creates the clickable item.
• The "icon­-calendar" span supplies the visually­ based icon.
• The "icon­-calendar" span also hides the glyph character from screen readers using the aria­-hidden attribute.
• The "sr­-only" span supplies the screen reader with the appropriate text to read aloud.

.sr­only {
    position: absolute; 
    width: 1px;
    height: 1px; 
    margin: ­1px; 
    padding: 0; 
    overflow: hidden;
    clip: rect(0, 0, 0, 0); 
    border: 0;
    }

If the icon is presented as a glyph font WITH associated linked text­:

• The actual icon text character and its associated link must be hidden to screen readers.
• A text equivalent specific to its contextual meaning should not be supplied.

<div class="icon-array">
  <span class="icon-nav">
    <span class="icon-selected">
      <a href="#" aria-hidden="true">
        <span class="icon-info" aria-hidden="true"></span>
      </a>
      <a href="#"> 
        <span class="nav">Task Status</span>
      </a>
    </span>
  </span>
  <span class="icon-nav">
    <a href="#" aria-hidden="true">
      <span class="icon-calendar" aria-hidden="true"></span>
    </a>
    <a href="#">
      <span class="nav">Calendar</span>
    </a>
  </span>
  <span class="icon-nav">
    <a href="#" aria-hidden="true">
      <span class="icon-attach" aria-hidden="true"></span>
    </a>
    <a href="#">
      <span class="nav">Attachments</span>
    </a>
  </span>
  <span class="icon-nav">
    <a href="#" aria-hidden="true">
      <span class="icon-back-in-time" aria-hidden="true"></span>
    </a>
    <a href="#">
      <span class="nav">History</span>
    </a>
  </span>
  <span class="icon-nav">
    <a href="#" aria-hidden="true">
      <span class="icon-comment" aria-hidden="true"></span>
    </a>
    <a href="#">
      <span class="nav">Comments</span>
    </a>
  </span>
</div>

• The "a" tag for icon and the "a" tag for the associated text make duplicate clickable objects.
• The "a" tag for the icon and the icon itself are hidden from screen readers using the aria-­hidden attribute while for sighted users, the icon is still clickable.

If the icon is presented as a glyph font IN a button with text:

• The actually icon text character must be hidden to screen readers.
• A text equivalent specific to its contextual meaning should not be supplied.

<button class="btnDefault-left">
   <span class="icon-angle-left" aria-hidden="true"></span> 
   <span class="prev-next-text">Previous</span>
</button>

• The "button" tag creates the clickable object.
• The "icon-­angle-­left" span supplies the visually­-based icon.
• The "icon­-angle­-left" span also hides the glyph character from screen readers using the aria-­hidden attribute.
• The "prev-­next­-text" span presents the the text in the button that is also read aloud by the screen reader.

IF the icon is presented as an image with no associated text­-based label:

• The linked image must include the "alt" attribute with the text equivalent specific to its contextual meaning.

<a href="http://www.w3.org/">
   <img src="http://www.w3.org/WAI/tutorials/img/w3c-796023c4.png" alt="W3C home">
</a>

• The "a" tag surrounding the image tag creates the clickable object.
• The "alt" attribute in the image tag supplies the alternate text that is read aloud by the screen reader.

The Image “Alt” Property Must Be Included

Because icons exist as images that initiate functionality, all functional icons must include text in the image “alt” property that informs the users as to what functionality the icon initiates.

Related Patterns

• Icon (Graphical)

Resources