Idioms and the Software Experience

Now that I’ve pretty much made the case that software cannot be intuitive, I want to show you what takes the place of intuition: the idioms. The term idiom is often used in reference to spoken languages. People learning foreign languages often study idioms before traveling to the countries using those languages. An idiom is a common phrase that, when taken for its pure word-for-word meaning, has nothing to do with the way people use it. I found a website that has a great list of common American idioms; you can visit it at http://www.englishdaily626.com/idioms.html. Here are some idioms this page mentions:

• Spill the beans

• Jump the gun

• Hang on

The first of these has nothing to do with spilling the beans. To “spill the beans” means that you are revealing something that you were not supposed to, like, “She spilled the beans that she’s taking me to the mountains for a vacation.”

The second, “jump the gun,” has nothing to do with guns. It means somebody started something too early (although the root of this phrase has to do with races and a gun firing to signify the beginning of the race).

And finally, “hang on” has nothing to do with hanging on. You might use it like, “Hang on, I’m on the telephone,” or “Hang on, I’ll be with you in a minute.” It means “wait.” (Although I suppose it could be used as in, “Hang on, Dad! Grandpa is bringing the other ladder that’s still in one piece! Don’t let go!”)

Software is filled with idioms, which are simply cues that are visual or otherwise that we know to mean something. One idiom is the Taskbar in Windows. I know what the Taskbar is, and so do you. It wouldn’t take long to teach somebody what the Taskbar does. Now the Taskbar doesn’t have much of a literal meaning: It’s just a bunch of rectangles at the bottom of the screen, each containing an icon and some words. But we know that if you click one of the rectangles, the program by that name will come to the front. There’s not much intuitive about the Taskbar, but it’s simple and it works. Here’s a sample Taskbar:

The notion of a window coming to the front is another idiom. Realistically, the screen isn’t layered, and you don’t have pixels behind the ones that you see containing the windows that are in back and obscured from view. But we do have an idiom: We all know that the windows have a layered look.

Note

However, Microsoft has made a bit of a mess, because in Windows XP, you can set up your Taskbar to group windows. This is a good thing, because instead of seeing 14 Internet Explorer rectangles all squeezed onto your Taskbar, you see only one, and clicking that one gives you a small menu of all the windows in the group. But the downside is that you have no way of knowing whether the window is minimized or not. If you accidentally click the icon for the window you’re looking at, then the current window will minimize, showing what was behind it. That can be confusing.

Idioms also take the form of icons and symbols. We have all learned what the mouse arrow represents, what the hourglass symbol is, and what a folder icon is, even when it looks a little different between versions and operating systems.

These are by no means intuitive. Consider the blinking caret that sits in the middle of the text in a Word document. Does it represent some magical division line, where text to the left of the caret is important, while text to the right is unimportant? Or maybe it simply signifies the exact center of the document. Yes, I’m being silly, but you get the point: The blinking caret is an idiom, and now you and I both know what it does.

RULE

When you design your software, keep the idioms simple enough so that they don’t get in the way of the real purpose of the program.

If I were to build a word processor, I might consider this idiom:

The speed at which the caret blinks denotes which characters you are allowed to type. If the caret blinks five times a second, you may type any character. If the caret blinks two times a second, you can type only vowels. If the caret blinks once a second, you may type only consonants. And if the caret blinks only once every four seconds, you may type only the letter s. Anything slower, and you may not type at all. Further, you can control the speed of the caret by moving the mouse….

You can see this is getting a bit out of hand. Yes, it’s an idiom. No, it’s not a good idiom. It’s too complicated, and it doesn’t provide a value to the user. What is the goal of the word processor? To type pages of text, not to mess around with some stupid idiom about the speed of the blinking caret. Soon you’d be more involved in trying to understand the blink speed rather than focusing on what you’re trying to type. Remember the Golden Rule of Software: Software should be invisible. The moment the user’s mind leaves the work that the software is serving and begins to focus on the software itself is the moment you’re about to have a frustrated user. And to aid in this Golden Rule, keep your idioms few, and keep them simple.

How do you design good idioms?

RULE

Good idioms are the result of a combination of established idioms mixed with common sense and careful design.

That Stupid Desktop Metaphor

My desk is a mess. Now, if my mother, Pat, were sitting here beside me, she’d use the term she always used to describe my bedroom when I was a child: It’s a disaster. (And trust me, she wasn’t laughing at the time.)

Let me describe my desk for a moment. I have a monitor on it, surrounded by junk—a digital camera, several cards for the camera, two speakers for the computer that are turned off, numerous business cards, two empty glasses, a measuring tape for an item I recently sold on eBay, a digital thermometer from when I was recently sick, a dental appointment card, a pair of fingernail clippers, several pens (half of which don’t work), a pile of papers with notes scribbled on them, a couple of books…and so on. It’s a mess. Trust me; I’m not including a photo.

So why in the world would I want to base my computer organization on this thing that the gurus of the 1980s called the Desktop Metaphor? And tell me, where on my desk is an icon?

The desktop metaphor is a joke. But it was a good attempt. The idea was to give the people of the world something they could relate to: A desktop, nice and simple. And for the most part, it worked early on, because the computer trainer teaching the frightened secretary could say, “Think of this as your desktop.”

Other metaphors have also worked their way into the computing world. The file cabinet is one. (And Microsoft even changed terminology back in 1995, when they deemed directories as folders. Apple, on the other hand, always had folders.)

Here’s the basic problem with the folder metaphor: In my computer, I can put a folder in a folder in a folder in a folder. Try doing that with your real file cabinet, the one of the metallic persuasion. You probably could do it, but it would make for a bit of a mess. And where does the file cabinet itself fit in? Figure 1.2 is an example of a folder containing folders.

Figure 1.2: This window represents an open folder, and you can see that it contains other folders.

Now I admit, the folder metaphor has, for the most part, worked. People seem to understand the metaphor, to a point. However, when a user sits at the computer, and he opens a folder he has never seen before, why does he know what that is? Does he mentally make a connection to the metal file cabinet beside his desk? Of course not. Instead, the reason he understands it is that yesterday he knew what it was. And tomorrow he’ll still remember what it is. In other words, his knowledge and understanding have nothing whatsoever to do with the metaphor of a file cabinet. His knowledge and understanding come from experience and from recognizing the idioms. That is, once he learned what a folder is, he could recognize folders in the future and continue using them. The metaphor portion is gone.

Tip

Metaphors are (sometimes) acceptable in training situations and have little use beyond that. Do not design your software with a metaphor in mind because, frankly, people will no longer need the metaphor once they understand how to use your software. Otherwise you’ll be using a metaphor as a replacement for good idioms. Instead, focus on the idioms: few and simple.

When the newbie learned to use the folder, somebody probably said, “This is called a folder, and think of it like a folder in a file cabinet.” But after that, the trainer had to explain how to double-click the folder and show him that a window would open, and that this window contains icons, and that he can drag them to another folder, and so on. And notice what’s happening? The metaphor is gone! And is the newbie making a mental connection to the metaphor? Doubtful.

Warning

Even in training situations, metaphors can become a problem. If the student is too smart, she might try to relate every process to the metaphor, which will invariably cause confusion. Consider these metaphors: creating a folder in a folder (does that really make sense?), creating a shortcut to a program (I’ve never seen a shortcut in a folder inside a metal file cabinet). And instead of accepting everything at face value, the thinking student will start asking questions the trainer is unable to answer.

REAL WORLD SCENARIO: The Vintage Doorknob That Trapped Them Inside the Room

I had something scary happen. And I mean really scary. I noticed that the doorknob in one of the bedrooms of the old house I live in was loose. It had play on it. If I turned it just a bit, I would feel nothing happen, and only after I turned it just a little bit more would I feel it engage and begin to do its job. And so I decided to fix it. I didn’t think a doorknob could be all that complicated, even though these are vintage doorknobs. I’ve replaced newer doorknobs before, and how different could this one be?

And so I fiddled a bit and figured out how to unscrew the outer mechanism, and soon I had the whole contraption sliding out of the door. The two knobs connected in the middle and had a little bolt attached to one that would tighten up into the other. All I had to do was tighten the bolt. And that’s when it hit me: If this thing ever so much as even thought about loosening up any more than it already had, the inside door handle would be rendered completely useless!

I can see it now. I have my door closed in my office as I’m working hard doing all that computer stuff that we computer people do (like seeing how many web pages it’s humanly possible to read in a single day), while the family is outside enjoying life. And finally at dinnertime I’m ready to emerge and return to the living. I walk up to the doorknob…closer…closer…and I finally grab it…I turn it…and nothing happens!

For years the neighbors would hear the screams of “Help!” emanating from that secret dark room. They would see my silhouette in the window as I peer out at them passing by, frightening them while I try to flag them down. Trapped. Unable to get out, for years upon years.

Now how is that for good design (or not)? Engineers can certainly make mistakes, and you, as a software engineer, can easily put yourself in the consumer’s shoes when you experience objects and items outside the computer. Think about how they work, and if they frustrated you, think about how they could be designed differently. Become the consumer. And then you can relate to the consumers of your products.

Let’s face it, the metaphor of the desktop and the file cabinet are pretty much here to stay, like it or not. But let’s leave good enough alone and keep additional metaphors out of the business.

Besides, I don’t keep my file cabinet on my desktop. I’ve heard horror stories of file cabinets tipping over and crushing innocent 19-year-old administrative assistants.

The Visual Basic Programmer Has Been Let Out of the Cage!

One of my biggest gripes about programming today is that it is unnecessarily difficult. For example, in one language I have to learn how to use standard templates if I want to create a list of strings. Another language has a type called TStringList. One is certainly easier to use than the other. (However, please don’t think that I dislike C++, which is obviously what I’m referring to here. C++ is one of my favorite languages. I’m just always looking for a simpler way to do things.)

And so I was very excited when Visual Basic came along. Visual Basic actually made programming easy. But some people might argue it made programming too easy. Alan Cooper (himself a guru in the useability world) created the original version of a development tool that soon became known as Visual Basic. What Cooper did in his proverbial garage was a breakthrough in the programming world. And today we see his original idea in everything from Borland C++Builder, Borland Delphi, Microsoft C#, various Java designers, and so on.

When Microsoft purchased Visual Basic and introduced version 1.0, they included an amazing feature that let people create their own custom controls. A custom control was basically a specialized control that could perform actions that the standard controls (buttons, listboxes, comboboxes, and so on) were not capable of.

Unfortunately, that’s exactly the major flaw in this thinking. While some useful controls came out (such as various spreadsheet controls), the world was suddenly overcome with the most horrifying sight to the eyeballs. People made controls that were simply buttons but had the most unreadable 3D text that appeared to be carved out of gray rock. Other people made controls that used every single color that the graphics card at the time was capable of. These controls could spin, dance, whirl, sing, change your oil, and cook your dinner. And they were the ugliest things ever to grace a computer screen.

But to add horror to horrors, other programmers were actually using these things in their programs. Users would download these cool new programs and find out that they needed this file and that file to use the program. This file and that file were, of course, extra Visual Basic controls. And then when people would start up the programs, they would be treated to the crayon equivalent of an explosion in a spaghetti factory.

Come on now. This wasn’t necessary, was it? Alan Cooper would be rolling in his grave, except he’s still with us, thankfully.

A friend of mine summed it up well when he said, “There’s nothing worse than a Visual Basic programmer let loose.”

Fortunately, the days of outrageous custom controls have passed. People don’t tolerate such abominations. However, creating user interfaces that look like such abominations is still possible, whether you use custom controls or not. Here, then, are some tips to help you avoid creating screens and dialog boxes that look like an expensive, original Matisse painting sent through a meat grinder:

• Use only the standard controls the operating system provides you. The built-in controls in Windows XP, for example, are rich with features and are well-established idioms. If you think you need a custom control, think again. Yes, it’s true that occasionally people really do need a custom control. But these moments are extremely rare. Go about your work assuming you don’t need one, and only if you get stuck while trying to program with the existing ones should you consider writing a new custom control. Following is a window containing the basic controls on all Windows systems; you can find these controls on other systems, too. Starting with Windows 95, you have at your disposal other controls, too, such as the ListView and the TreeView.

  

• Don’t set any colors. I’m serious. First, simply call into the operating system, and let the operating system assign colors to elements such as buttons and listboxes. The operating system in turn chooses its color based on user preferences, which are set in the Advanced Appearance dialog box shown below (for Windows). But if you must assign colors for whatever reason, pick from the list of colors chosen by the operating system, since these colors come from the user preferences. These colors have names like ButtonFace (depending on the language you’re using) and ActiveWindowColor, and they often match the names in the display preferences. (Of course, you can see the obvious exceptions: If you’re writing a program for manipulating graphics, then you’ll be setting the colors of the image. But I’m talking about the user interface: For the window title bar, the buttons, and so on, don’t set the colors.)

  

• Don’t use 3D and all that other crazy stuff to “enhance” the look of your interface. (The one exception where this seems to be fine is with games. With games, people usually make their own entire user interface.) Okay, I admit, the following is pretty cool and I had fun making it. But I would never dream of releasing this in a software package!

  

• Avoid messing with text. There is a practical reason for this: If you obscure your text in any way whatsoever, you might make reading it difficult for visually impaired people. And a less practical reason is that it will annoy people, whether they are visually impaired or not.