# Icons

A user encounters many small, usually clickable graphics in a desktop environment. These graphics represent objects, actions, properties or provide status information of objects. Graphics representing objects or actions are called "icons," and graphics representing object properties or statuses are called "glyphs." Since glyphs constitute a small portion of the graphics pool in desktop environments, they are briefly explained in this section of the chapter along with icons.

Icons are small graphics that represent objects (applications, files) or actions ("Create new," "Save") in a user's desktop environment. They come in standard default sizes of 48x48, 32x32, 24x24 and 16x16. Icons are originally designed on a 48x48 canvas, then automatically scaled-down in GNOME to appear in context-dependent sizes.

Glyphs are graphics are usually, but not always, smaller than what are formally considered icons. They do not have default sizes. They don't initiate actions or represent objects, but usually represent the state or distinguishing attribute of an object in a larger set of objects. A sort indicator in a table component, a tree turner in a navigation tree, alarm badges on object icons and emblems in Nautilus are all glyphs.

The first graphic in each category is the original size in which it was designed. The object icon represents a jar file, The action icon represents a "save as" action in a toolbar or menu and the glyph represents one property ("important") of a directory object in Nautilus.

## Different Types of Icons

Object Icon | Action Icon | Glyph
FIXME - icons here | FIXME - icons here | FIXME - icons here
48x48, 24x24, 16x16 | 48x48, 24x24, 16x16 | 48x48, 22x22, in context

## Style

All of these graphics should be designed with a global desktop look and feel in mind. GNOME uses a soft, three-dimentional look that is exemplified in the stock icons. This style is achieved by using antialiasing, shading and highlighting techniques. A simple icon design tutorial by Jakub Steiner of Ximian, focusing on gradient and alpha channel use in the GIMP (GNU Image Manipulation Tool), can be found here: http://www.ximian.com/devzone/tutorials/icon-design/

Components of an icon style can be broken down into several categories such as perspective, dimentionality, lighting effects and palette. These components play an important part in giving a group of icons a collectively distinctive look. For instance, the Java Look and Feel, or "metal," is recognizable by its use of a primary eight-color palette, interior highlighting and diagonal gradients. The Macintosh Look and Feel, or "aqua," is recognizable by its use of a cool palette based on blue, lighting effects mimicking reflectivity and antialiasing. The GNOME look and feel currently being developed exhibits a thirty-two color palette, soft drop shadows and a mix between cartoonish and photorealistic graphics.

### Different icon styles

Java Look and Feel | Macintosh Look and Feel | GNOME Look and Feel
--- | --- | ---
FIXME - icons here | FIXME - icons here | FIXME - icons here

For the GNO ME Look and Feel, the following should be observed:

- ### Perspective

  Flush perspective (as if you were looking at a three-dimentional object at eye-level) is useful for designing graphics representing actions because these usually appear in toolbar buttons and express a "shelved" metaphor. However, angled perspective can be used for variation, particularly for icons representing objects (such as application icons) or for central image components within a bounding component using the flush perspective.

  ### Different perspectives

  Flus Perspective (action) | Angled Perspective (object) | Angled within Flush Perspective (object)
  FIXME - icons here | FIXME - icons here | FIXME - icons here

- ### Lighting

  Icons should be designed as if there is lighting coming from the upper left corner, with a soft drop-shadow cast within the icon's 48x48 (original design size) borders (120 degrees, 4 pixel distance, 4 pixel blur).

- ### Palette

  Icons should use colors based on the basic thirty-two color palette (FIXME - put a link to this section in visual design), and darken or lighten the hues by hand as necessary when antialiasing.

## Size

When designing default size icons for GNOME, make sure that you create them to be as close to 48 pixels in height and 48 pixels in width as possible. These dimensions should include drop shadows and other effects, such as antialiasing.

This will ensure that icons appearing next to each other will not only have consistent color and style, but also be uniform in size.

GNOME will automatically scale icons down form their default 48x48 size to exactly one-half that size, to 24x24 pixels when placing versions of the icons in menu entries. GNOME will also provide padding around the icons in menus (4 vertical pixels between icons and 4 horizontal pixels between icons and their menu entry labels), so there is no need to build in the space around the icons when designing them.

## Context

### Different perspectives

Panel | FIXME - icon here | 24x24 | FIXME - icon here | These icons will primarily be launchers.
Menus | FIXME - icon here | 24x24 | FIXME - icon here | These icons will accompany menu entry text to aid the user in scanning menus, but will also enable the user to create their own launchers by dragging them onto the panel or the desktop (exactly one-half the size of default desktop icons).
File Browser | FIXME - icon here | 48x48 | FIXME - icon here | These will be file type icons and launch appropriate applications to open a documents they represent.

FIXME - I left a lot of these rows off the end. It seems pretty whacky to list all these. Not sure I agree with the way "contexts" are presented anyway. Its sort of confusing.

FIXME - There's a whole accesibility section missing here

## Do's and Don'ts

- ### DO make icons easily scannable

  Toolbar and menu icons are downsized to exactly one-half of their original icon sizes and appear in groups; their small sizes and other shared charactics can make it difficult for users to scan for a particular icon quickly. Therefore, it's doubly necessary in this context to make sure that each icon is visually distinct from another. One way to achieve this is by giving icons distinct (e.g., irregular versus perfectly square) outlines.

- ### DO denote categories

  I have some strong disagreements with this one. Specifically I think the sheet of paper thing for document icons is altogether unhelpful. It violates "DO make icons easily scannable" up the wazoo. The contexts in which documents appear in the file manager already categories them to a large extent. Its ok to have some sort of weak categorization/theme in the icon, but that sheet of paper gets old quick

- ### DO opt for simplictiy

  Icons are often viewed in smaller sizes than ones they were originally created in; keep in mind that your icons need to be recognizable when reduced to 24x24 or even 16x16. If a user has to spend more than a second or two looking at the icon to recognize what it's representing, then the metaphor used in the icon is too complex.

- ### DO use stock icons

  GTK provides many stock icons, and you should use these whenever you provide a toolbar button for one of the functions they represent. This establishes consistent language across applications, and makes it easier for users to search for items on the toolbar. FIXME - provide info on viewing these

- ### DO NOT use stock icons for anything other than their intended purpose.

  This will make your application inconsistent with others, and could easily confuse your users, as well as weakening the effectiveness of the stock icon in other applications.

- ### DO NOT use text as the distinguishing feature of an icon

  I disagree with how mildly this point is worded. The reason is not soley internationalization, and I entirely disagree with the use of file extensions such as "GIF" and "JPG" in the icons. If this information is really useful (I think it is not and should be discouraged) it should be automatically overlaid by the file manager based on the *actual* extension of the file. This is just more visual noise.

- ### DO NOT represent body parts in icons

  these may be offensive to certain cultures, and in actual use frequently do not succeed in conveying meaning.

- ### DO NOT base icon designs on idioms or product names

  Instead, base designs on a product's functionality, which will pose less internationalization problems and be easier to recognize for new users. For example, the Nautilus icon is that of a nautilus shell, which does not make its functionality (file browsing) explicit.

- ### DO NOT use violent imagery

  Just as words like "kill" and "slay" are inappropriate in interfaces, violent or destructive icons (such as an explosive detonation swtich) should be avoided.