So This Button Must...

October 01, 2001

MurphysLaw-October 01, 2001

So This Button Must...

Ever stared blankly at a panel of buttons and dials, wondering what controls which function? Apparently, so has Niall, and he's tired of it. This month, a laundry list of user interface design failures.

For the past few months I have been knocking browsers and objects. But make no mistake, I am a big fan of both. Sometimes, though, I feel it's useful to address their weak points. This month I am going to continue in a critical vein and point out some awful things I have seen in user interfaces over the years. Some I have come across doing professional reviews; others have driven me nuts while driving my car.

In my previous writing about user interfaces, I have usually started with a basic principle, and then shown examples that illustrate the point.[1],[2] In this column, I will leave the principles aside and simply point out the things that annoy me.

Wired for sound

I recently set out to buy a stereo for use in the bedroom, something to play soothing music at the end of a hard day, and to add some melody to my morning ritual of struggling out of bed.

A remote control was vital since I didn't want to get out of bed to change channels while looking for sleep-time lullabies. The stereo I chose had a remote all right, but a few mistakes rendered it almost useless. The first was a penny-pinching measure. The LCD had no back light-so it could not be read in the dark, or even in the half light. Wanting to use the stereo in the dark is reasonable. It should have been on the designer's list of user-task scenarios.

So my nighttime use of the remote had to be blind. That should have been manageable with a little practice, once I got used to the positions for the buttons used most often. This did not prove to be so easy. One of the buttons was labeled "function." This button switched through three modes: radio, CD player, and tape deck. The function you get when you press the button depends on what mode you start off from. If you're on the CD player and want the radio, you have to press the button twice-once to move to tape deck, and once more to get to radio. Seems quite simple. But what if you don't know the current state? If you hear nothing, the system could be on CD or tape deck with nothing playing, or in radio mode with the volume turned down. If you think it's on radio with the volume turned down you could turn the volume up, but, if your theory is wrong, a major blast of sound could result when you do finally hear something. If each function has its own button, pressing the radio button indicates for certain what mode you're in, regardless of where you were before.

It's also useful to consider whether two presses of a button should be different from one. Many designs avoid buttons in which the number of presses (without intervening presses of other buttons) changes the button's meaning. That prevents confusion caused by accidental double-presses. This would be especially true of a remote control, which might not always be pointed in the right direction. Some button presses might be lost if they are not detected by the receiver.

Words, not icons

Manufacturers in international markets love icons. If they put icons on the housing of the product, and no words, they can sell an identical device to all markets. This way, they don't have to break down the various national markets before doing a production run. They simply make them all the same and then decide afterwards where to ship them. This is a big issue in Europe, for example.

While icons have advantages for planning and manufacturing, they have some chronic usability problems. Computer applications can leverage icons more than consumer appliances because the desktop GUI can take advantage of bubble help, and users tend to have long-term relationships with an application, and hence a longer learning period.

Two years ago I moved house and bought a new set of appliances, including a double-oven. After ten minutes of fiddling with it and failing to get any heat out of either oven or the grill, I decided it was faulty. As a desperate, final gesture, I read the user's manual. You might say that I should have read it in the first place, but think about it. I'm not trying to set up a timed program, or recalibrate the thermostat. I'm trying to get an oven to provide some heat. That shouldn't require instructions.

The oven had four modes of operation. It had "on" and "off" as we would normally understand them. The other two were "light-only," to be used while cleaning the over (guess how often that gets used), and "fan-only" mode, which, I am informed, is used to defrost food at room temperature.

One of the dials had three icons. One of these was a lightbulb that pretty clearly meant the "light only" mode. "Fan-only" and "on" are shown in Figure 1. "On" is really being stated as "fan and oven on." The icon on the right represents "fan and oven on," but I see no reason why any user should be able to figure this out. The fan is always on when the oven is on, so the "fan and oven on" icon did not need to contain a likeness of a fan. Thus, the icon should have been designed to say "oven on." In any case the distinction between the icons was lost on me.

We could claim that the lesson here is that Whirlpool chose bad icons. But consider how easy it would have been if they used the text alternatives.

For the moment, let's assume that the manufacturer had no choice but to use icons. They should then have acknowledged that using icons led to a less usable system and tried to improve on it a bit. The first thing you do is take the most common choice, "fan and oven on" and make it very distinct from the other lesser used modes. This could easily be done with the size, style, or color of the icon.

However, if we look at the other controls we find a much more basic problem. The oven has a separate dial for temperature. If you turn this to 200 degrees, and set the first dial to "fan only," the fan blows, but no heat is generated. To make matters worse, the thermostat light comes on, implying, falsely, that the oven is being heated. The design sin here is that the user is allowed to enter a setting which is not being used. When I am in any mode other than "fan and oven on," the temperature dial has no effect. The common user error is to dial in 200 degrees and think he's going to get 200 degrees. Allowing the user to enter something that is ignored by the device is never a good idea.

The best thing to do is make the most common mistakes impossible. Replace both dials with a single dial that has three fixed positions (positions the user clicks into), and then a variable range for the temperature (where the dial turns smoothly). Such a dial is shown in Figure 2. The dial can be set to "Off," "Light only," "Fan only" or moved into the variable portion. Once you are in the variable portion the dial has the temperature marked on the scale, in the same way the original temperature dial did. If you turn the dial to a temperature, you get that temperature. If you do not understand the "Light only" or "Fan only" icons, you at least know you're not getting any heat, since there is no temperature setting.

I am not sure whether this solution is more or less expensive. It saves one dial, but the dial with fixed and variable positions is probably more expensive to manufacture. Of course, in this month's column, I am not trying to solve problems-my agenda is to complain, an activity I will return to presently.

Speak the user's language

I bought a secondhand car a couple of years ago. Since it was second hand, I didn't get a manual for the radio/tape player. I had to return to the dealer two weeks later for assistance. Why? Because I could not turn the radio off. The salesman immediately pressed the button labeled "TUN" to turn it off. "TUN" is no doubt short for tuner, but my assumption was that the button was related to the function of tuning a new station, something I did not attempt to do, since all of the local channels were already preset.

The designers used the word "tuner" because, within the industry and for hi-fi fanatics, the tuner is the radio part of a stereo system. In a top-of-the-line home stereo, this might be forgivable, but all sorts of people drive cars, and most of them call the radio a radio. Had the button looked distinct, one might have guessed its on/off role. Or if it was next to a "tape" button, it would have been more easily recognized as one of the alternative parts of the stereo. There was no tape button because the tape is started merely by inserting the tape, which is reasonable.

The lesson is to use your industry's language in internal documentation, but make sure that the consumer's language is used in all text that may be seen by the customer, whether it is on the product or in the user manual.

The other lesson here is that the on/off button should not be one of a row of similar looking black buttons. Make it look different. I may be trying to press it while driving. The second thing to do is physically move it out of the way so that it does not get accidentally hit when manipulating other buttons.

Dials, not buttons

Another pet peeve of mine is using a pair of up/down buttons where a dial is more appropriate. Turning a dial is a natural mechanism for adjusting a property that varies gradually. Also, the listener is likely to overshoot, and reverse back to the ideal setting. Dials give good tactile feedback in a situation like this. Buttons that change volume may be pressed often compared to other buttons and this means that they can be the first component on the device to reach end of life. Unfortunately, buttons are cheaper than dials. Also, I fear, it is easier to make buttons look orderly and symmetric, and some designers will seek form, not function, and opt for buttons on aesthetic grounds. The problem is that while the device might look good, it won't feel good.

My car stereo failed on this count, as well. I should point out that the stereo described so far is now sitting at the back of my shed, and has been replaced by a new model that has a bright blue on/off button (it doesn't need an icon or a label; it just looks like an on/off button) and a dial for the volume. The dial is not just a potentiometer either, but a rotary encoder, so the changes are fed to software and the absolute position does not really matter. This means that the stereo always turns on at the same volume, regardless of what fiddling may have been done with the dial while the stereo was turned off.

Using a rotary encoder dial, rather than a potentiometer, also has huge advantages if you want to use the same dial to control different parameters.

Buttons, say what you do

If your embedded system has a full GUI then you may fall victim to a problem that affects the majority of desktop applications. How often do we see a pop-up which contains two buttons: "Yes" and "Cancel"? After reading the description in the pop-up, you realize that the "Yes" button means "Save and Overwrite" and the "Cancel" button means "Do not save." If the buttons have these simple meanings, why do they say "Yes" and "Cancel"? The only reason is that many GUI APIs make it easier to program popups with these canned buttons. The lazy programmer then constructs a question that will allow the answers "Yes" and "Cancel" to make some sense.

This is awful design. You are forcing the user to figure out the question to which the answer is "Yes" in order to know what to do. I tremble to think how much human effort has been lost because users have clicked the wrong answer to one of these insidious little dialogs.

If your API encourages this repulsive practice, try to discourage its use, especially where the actions cannot easily be undone. Instead, label the buttons with the action that they perform.

Allow output capture

I will end with a desktop issue that rarely arises in embedded systems. I mention it because I am sure you have all hit the same problem at some point. Consider a desktop GUI application which outputs error messages to a dialog window. I am often in a situation where I want to contact my system administrator by e-mail to inform them of the message. So how do I insert the error into the e-mail? Well, I type it in. No one should have to take text output from a computer and then type it back in. Yet most dialogs will not let you cut and paste the message text.

Equal opportunity is the name of a property in which all output is reusable as input. An on-line tutorial on my Web site describes equal oppportunity in greater detail.[3]

The cost of penny pinching

I am not sure if a common theme unites my various gripes, but some of these problems stem from cutting component cost, and some from programmers saving their own time, which is another form of cost. I would not quibble with a designer saying he is trying to make a low-cost product, but the designer should try to measure the cost to the customer when compromising features such as those I have described this month.

So we come to the end of another of my whining columns, and most readers have probably decided that I prefer complaining to actually solving problems. I promise you something much more optimistic next month.

For those of you who enjoy all this complaining, many more examples of bad design are available at www.baddesigns.com. While many of the products described do not fall into the embedded category, they still make for interesting reading. If any of you decide to contribute your own examples, let me know.

Niall Murphy has been writing software for user interfaces and medical systems for ten years. He is the author of Front Panel: Designing Software for Embedded User Interfaces. Murphy's training and consulting business is based in Galway, Ireland. He welcomes feedback and can be reached at nmurphy@panelsoft.com. Reader feedback to this column can be found at www.panelsoft.com/murphyslaw.

References

1. Murphy, Niall. Front Panel: Designing Software for Embedded User Interfaces, Lawrence, KS: R&D Books, 1998.
Back

2. Niall Murphy's list of ESP articles is available at www.panelsoft.com/articles.htm.
Back

3. Niall Murphy's Equal Opportunity Tutorial is available at www.panelsoft.com/tut_equal.
Back

Return to October 2001 Table of Contents

Loading comments...

Most Commented