Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 57 of 197

5. ~ = In general, asking for confirmation of an action is a clumsy way to add robustness. Using an embedded interface should be as natural as using a tool from your toolbox. FlGURl1 A hypothetical microwave oven front panel ~. - -. -: ':-".~ Door Open can have the disadvantage that the user may believe that the belt is mov- ing at the entered speed, instead of at tlle limiting speed. For example, if the belt is physically limited by its motor to a top speed of four feet-per-second, but the user can enter five feet-per-sec- ond, the user may make other deci- sions based on the assumption that the belt is actually moving at five feet-per- second. By limiting the use r at the time of input it is possible to give more accurate and meaningful feedback. If you have error messages or warn- Back in 1982 the Sinclair ZX Spectrum home computer 's use r man- ual stated: "Nothing typed at the key- board can damage this computer." This showed good insight on the wri ter's part. They realized that they could reduce users' anxiety by reassur- ing them that they would not destroy their purchase no matter how many silly mistakes they made. It was also a sign of good design of the computer- they made it robust. Many program- mers wro te their fi rs t programs on that system, without having to worry about any damage a buggy program might cause. In the desktop world if you req uest that a fi le be deleted and the system deletes the fi le, you would expect nothing else. But what if the in itial request was a mistake? A robust inter- face should not allow an accident like that to occur easily. So the system now prompts users "Do you really want to delete MyLife'sWork. txt?" This has made the system more robust, but less usable because now it takes more key strokes to delete a file . A be tte r approach is to allow an undelete com- mand. Now the system is more robust because the fil e cannot be lost so easi- ly, but the ease of use has not been compromised. In general, asking for confirmation of an action is a clumsy way to add robustness. Using an embedded inter- face should be as nantral as using a tool from your toolbox. Your hammer does not ask you if you want to hit something, just before impact. If it could, I do not think that many people would consider it a more usable tool. Confirming actions often becomes so automatic that it adds little protection in any case; the user will kit the OK button without fully considering the question asked . Similarly, error messages, or a beep to indicate an illegal action, may seem like an appropriate response to an invalid action. An au tomatic teller machine that has been asked for too much money will display a polite mes- sage tell ing you that you are not rich enough. The system is protecting the user from becoming overdrawn. Sometimes you will need to put limits on the user to prevent them setting illegal values. These li mi ts protect the device and the user from user errors. Sometimes the mechanical system will have intrinsic limits that cannot be vio- lated-tlle top speed of a motor for a conveyer belt may be limited by the circuit d,;ving it. However using an internal mechanical or electrical limit 56 DECEMBER 2000 Embedded Systems Programming ings, be careful how you word them. Putting up a message that says "Illegal action" not only gives the user very lit- tle info rmation, it also suggests that he is a criminal! With a little extra effort on the developer 's part it is usually possible to provide a context-sensitive message that suggests what is actually wrong, such as "Can 't record: no tape inserted." Now that we have established a pro- tocol for telling the user what he has done wrong, we have improved the product but the interface is becoming less user friendly. Devices that tell you what you can and cannot do are unpleasant to use. In many cases you can get the best of both worlds. On a TV set a user can press an up or down button to change channels. What hap- pens when they reach the highest channel. The TV could beep and flash if the user tries to go any higher, and they will probably realize their mis- take. It is much more satisfactory to wrap around to the lowest channel, avoiding the necessity of pointing out a supposed error to the user. Users find it unpleasant to be told they have made a mistake, so design fewer paths that end in error messages. Think of the error message as an airbag-it minimizes damage once the accident has happened. You are far better off supplying the user with an anti-lock braking system, which might avoid the accident in the first place. If a device takes numerical input from a keypad, it may be necessary to reject

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13