CHAPTER 16: Tricks of the Trade – User Interface Design for Programmers

Tricks of
the Trade

Here we are, almost at the end of the book, and I still have a whole bunch of important factoids to tell you that don't fit neatly into chapters. But they're pretty important factoids:

  • Know how to use color.
  • Know how to use icons.
  • Know the rules of internationalization.

Let's go through these one at a time.

Know How to Use Color

When I set up my office files, I bought a big box of file folders. The box came with four different color folders: red, yellow, manila, and blue. I decided to use one color for clients, one color for employees, one color for receipts, and the fourth color for everything else. Outrageously sensible, right?

No. The truth is that when I'm not looking at the files, I can't remember the color scheme, and in fact, the color scheme doesn't seem to help at all. As it turns out, using different colors is good for distinguishing things, but not for coding things. If you have a bunch of red folders and a bunch of blue folders, it's easy to tell that they are different, but it's harder to remember which color means which.

The general rule for how to use color was best stated by Web designer Diane Wilson:

"Design in black and white. Add color for
emphasis, when your design is complete."

Strange as it may seem, creating a color code doesn't really work. People have trouble remembering the association of colors to meanings. In fact, if you make a pie chart using five different colors, with a little legend showing the meaning of the colors, it's surprising how hard it is cognitively for people to figure out which wedge belongs to which label. It's not impossible, of course, it's just not super easy. Putting labels next to the wedges is a million times easier (see Figure 16-1).


People have trouble remembering color codes. Don't rely on color to convey meaning.

There's another important reason you can't rely on color to convey meaning: many people can't see it. No, I don't mean the old timers who still have green-on-green screens. But about 5% of all males (and a much smaller number of females) have some degree of color blindness and simply cannot distinguish colors (particularly red and green, which is why stoplights are vertical).

Color can be used successfully for a few things:

  1. As decoration—in pictures, icons, and text, where the effect is solely decorative.
  2. To separate things—as long as you do not rely on the color as the only indicator, you can use color as one distinguishing factor, for example, by using a different color and a larger font for headings.
  3. To indicate availability—by using grey to indicate an option that isn't available. Even most colorblind users can distinguish greys from blacks. Similarly you can use lightly shaded backgrounds to indicate areas where the user can't edit, and white backgrounds to indicate areas where the user can edit. This has been a GUI convention for so long that most people understand it subconsciously.

Always honor the system color settings, that is, the colors that the user chose in the control panel. Users have deliberately chosen those colors to give their computer the color scheme they like. Also, many of your vision-impaired users have deliberately set up schemes that they can see more clearly. (For that matter, always honor the system fonts so that your text is readable by people who prefer larger fonts.)

Know How to Use Icons

A picture is worth a thousand words, you think? Well, not if you're trying to make a picture of the "schedule meeting" command and you've only got 256 pixels total to do it in. (I know, I know, now you're all going to email me your clever icon renditions of "schedule meeting" in 256 pixels...) Here's the trick with icons. As a rule of thumb, they work pretty well for nouns, especially real-world objects, where you can create an icon by making a picture of the thing. But they don't work so well for verbs, because 16×16 is not a lot of space to show an action. In a typical word processor, the icon for numbered lists (Figure 16-2) is amazingly obvious. Hey, it looks like a numbered list! But the icon for "Paste" (Figure 16-3) is not so obvious. Even after you've learned it, it requires too much cognitive effort to recall.


The icon for numbered lists is just a picture of what it does, so it's easy to recognize.


The icon for Paste is attempting to depict a verb, so it's not very easy to recognize.

Know the Rules of Internationalization

You may not be internationalizing your product now, but chances are, you will. The cost of translating a software product is far less than the cost of writing it in the first place, and you can often sell as many copies in a second language as you can in the original (especially if the original language is Icelandic, and you're translating it to English.) There are a lot of rules about how to write good international software, which are beyond the scope of this book. In fact, there are whole books on the topic. But for user interface design, there are three crucial things you should try to keep in mind.

Rule One: the translated text is almost always longer than the original. Sometimes it's because some languages like to use forty-seven-letter words for the simplest concepts. (Ahem! You know who you are!) Sometimes it's just because when you translate something, you need more words to convey the exact meaning of the word in the original language. In any case, if your user interface relies on certain important words fitting into a certain number of pixels, you're almost always going to have trouble when you go to translate it.

Rule Two: think about cultural variables. Americans should realize that phone numbers are not always seven digits long with a dash after the third digit. If somebody's name is X Y, don't assume that they are Mr. Y; they could just as well be Mrs. X. Non-Americans should remember that Americans don't have the foggiest idea what a centimeter is (they think it's a multilegged creepy-crawly). Microsoft Excel uses a U.S. dollar sign icon ($) to format cells as currency, but in non-U.S. versions of Excel, they use an icon showing coins instead. And don't get me started about lexical sort orders or the odd way the Swedes sort things—you could never find yourself in the phone book in Stockholm, even if you lived there and had a Swedish telephone, and so forth.

Rule Three: be culturally sensitive. If your software shows maps, even for something innocuous like time-zone selection, be real careful about where the borders go, because somewhere, someone is going to get offended. (Microsoft now has a full-time employee who worries about this, after Windows 95 was banned in India for failing to reflect India's claim on Kashmir—a matter of a few pixels in the time-zone control panel.)

Don't use a little pig for your "Save" icon (get it? Piggy banks? Savings?) because piggy banks aren't universal. In fact, don't use puns anywhere in your user interface (or in your speeches, or books, or even in your private journal; they are not funny). Don't use a hand palm-up to mean "stop," because it's offensive in some cultures.

In general, don't release software in another language without doing a little bit of cultural testing on native speakers. I had a scanner once that displayed a dialog box saying, and I quote: "The Scanner begins to warm up!" The upper case 'S' in "scanner" was proof, but the whole sentence just sounds like it was written in German and translated to English (as, indeed, it was). Weird, huh? There's nothing grammatically wrong with it, but it doesn't sound like something a native English speaker would say. One famous program from Australia, Trumpet Winsock, made Americans think that it was written by an illiterate moron, mainly because it used the word "Dialler" all over the user interface, which Americans spell, "Dialer." To an American, using two 'L's looks like the kind of mistake a young child might make. (Other Australian spellings, like "neighbour," look merely British to the average American, not illiterate).

The best way to become culturally sensitive, I think, is to live in another country for a year or two, and travel extensively. It's especially helpful if that country has nice warm beaches, or wonderful cultural institutions, or spectacularly beautiful people. Great restaurants also help. You should ask your boss to pay for this as a part of your UI training. And when you've figured out where the best beaches and restaurants are, you should top off your training with a course in UI design from someone like, ahem, myself.