Pixelcentric IHS: Use of Color

Color should be used in interfaces very sparingly except in icons. Users rarely have trouble seeing black text on a white background (or vice versa, if using White on Black mode due to eyesight disabilities). However, other color combinations can be troublesome.

1. Consider Readability

When making colorful user interface elements, think about what kind of elements can be next to them. Especially consider the background colors on which a text element can reside. Apple failed to consider this when designing the Mac OS X version 10.2 Force Quit applet. The idea here is that applications that don't respond for a while are displayed in red type. In theory this sounds like a nice feature that could make finding crashed apps quick and easy. However, the color for indicating the selected item is blue (regardless of the user's appearance settings, apparently). Thus, the red text is displayed on a blue background, rendering the text nearly unreadable.

Another issue relating to contrast is the visibility of certain key elements within your user interface. Consider the movie control buttons in QuickTime 4 and QuickTime 5&6, respectively. The gray, low-contrast QuickTime 4 button icons can be very hard to see for some people – especially the elderly, whose eyes are much less sensitive to light than the eyes of younger users – while the "Aquafied" buttons in QuickTime versions 5 and 6 provide much better contrast and are thus much more usable.

2. Consider Associations

In many cultures it is recognized that the color red can be used to depict negative answers or commands, while green is associated with positive ones. Red is "no", green is "yes". This can cause all sorts of problems if used carelessly.

Not only is this example a horrid Windows style Yes/No dialog box right in the middle of Mac OS X, the promised land of verb-based command buttons, it also makes rather questionable use of color. "No" is marked with a red X, as if it were the undesired, negative choice – but reading the message reveals that "No" is in fact the choice that will not lead to data loss, while the safe-looking option with the green checkmark is in fact destructive.

This works both ways: some applications make safe operations or options look dangerous. For instance, a notification dialog using a red error symbol is needlessly scaring the user. Conversely, the dialog depicted in the screenshot is using a white notification icon when it should be using a yellow warning icon. Make sure to use the right types of color cues in various contexts.

Using the red-green color pair for notifications that aren't associated with yes/no question-answer pairs is generally harmful. For example, a planning program that uses green and red to represent people that either are available or aren't is clearly flawed, since it's not instantly obvious what each color represents. In these situations a combination of a bright color and a shade of gray usually works better, since gray is widely recognized to represent a disabled state.

3. Don't Hard-code colors

If your application uses custom controls or custom highlight colors for e.g. text, don't hard-code these colors. If the user is using a visual theme that's different from the window manager's default appearance, your application may end up looking hideous or unreadable – or both. Instead of hard-coding colors, use the colors provided by the system. For instance, on Mac OS, accent colors and control colors are provided by the Appearance Manager.

If using system-provided colors is impossible (for example if the platform your application runs on doesn't provide such a feature), try to make colors user-definable. For example, let the user change text colors through a color picker in your application's preferences window.

Always make sure to test your application using various window manager themes in order to make sure that alternate color schemes don't render your app unusable.

4. Don't Overdo It

Just as sounds in an interface, color can be effective if used conservatively enough. But too much color can make your interface distracting and gaudy. When too many elements in an interface are brightly colored, the colors negate each other and as a result none of the items stand out any better than they would if they were a boring gray. This is especially important when designing icons, as large, bright areas of color in a small canvas can overwhelm the rest of the icon. Use color only when it really makes sense.

Site contents copyright © 2002-2003 Pixelcentric. Software products, brand names and logos are Copyright their respective owners.