Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 63 of 197

5. a. m. ton "2" means exit voice mail , or delete message. Output can be multiplexed as well. A single LED might indicate power on most of the time, but it can fl ash to indicate low battery at other times. A single numeric display can show tem- pel"ature at one stage, and the time of day at anothe r point. The user should have some hint, such as an AM/ PM indicator, to show which mode it is in . A second display would increase the surface area, making it a better match fo r the available functionali ty. Having twice as many displays would make life easier on the user, not harder, assum- ing that the two displays are properly labeled. Compatibility Three levels of compati bili ty are at play in a n interface. There is compati- bility between what the user expects and what the use r gets. There is also compatibility between diffe rent prod- ucts of the same typ e. Finall y, there is compatibility between the device and its surroundings and the devices with which it has to cooperate. I will deal with each of these in turn. A lever-operated press moves down when the arm is raised and up when the arm is lowered . It works this way because of the levering mechanism used . This is good engineerin g, but bad usability. While the user may learn that the arm moves in a direction opposite to the press, he may revert to the more natural mapping in an emer- gency, thus causing a n accide nt. Making the actual behavior compati- ble with the expected behavior can be easier in software where the engineer- ing issues can be hidden. So UP but- tons sho uld be above DOWN buttons, and LEFT buttons should be on the left of RIGl-IT buttons. Similarly, high and low limi ts should be d isplayed in the appropriate vertical alignment. If a set of controls are near each other, or have similar coloring, the user will expect them to be related in some way. In general, you do not want to sUI"prise the user. Compatibili ty between products is not such a simple issue. The history of products in your market may dictate that certain practices are fo llowed, long afte r a bettel" way of doing dle j ob has been found. Sometimes arbitrary differences exist in the marketplace and you will have to choose which trend to follow. Standards bodies that have been so active on dle desktop have only made minor inroads in to the embedded world. Some attempts have been made to standardize alarm sounds and lights in hospitals, but dlat is a long way from standardizing the whole interface. ISO 9995 has set a standard fo r th e arrangement of letter on the buttons of a telephone or other numeric key- pad, dl0Ugh phones the world over still vary in dle placement of letters. Annoyingly, numel"ic keypads o n com- puters are upside-down when com- pared to the te lephone standard. The symbols on the main buttons ora VCR, shown in Figure 2, have also been stan- dardized, dlo ugh the rest of the con- u"ols on dle VCR may vary gready- even within one product lin e. Some standards are not so quickly accepted. ISO 8601 is a standard for date and time formats. It dictate a ),),),),-mm-dd format fOl" dates. However, Europe currently uses the dd/ mm/ ),), format and the U.S. uses th e mm/ dd/ ),), format. The ISO standal"d is a mOI "e logical format since it starts with the most significant unit and then moves to dle successively smaller units as you read it from left to right. This corresponds to normal numbers and telephone numbers (coun try code fol- lowed by area code followed by phone number ). The ISO standard also has the distin ct advantage that it can be sorted chronologically by simply sort- ing them alphabeticall y, sin ce the most significant unit (year) is to the left. While this standard is common in J apan and a few other counu"ies, it is not used by dle vast maj ori ty of the world-mainly because dle odler for- mats are so well established that it is impossible to dislodge them. 62 DECEMBER 2000 Embedded Systems Programming If no standard is in place to keep dle behavior of competing products in lin e, then at least u)' to ensure that all products in a fam ily, or from the same company, are compatibl e. Compatible mental models and behavior al"e more important than compatible appear- ance. Matching inte ractions con- tributes more to the abili ty to transrer knowledge gained from one product to anodler dlan matching dle color or the company logo. Compatibility with olde r products can some times stand in the way of a consistent orthogonal interface. The competi to rs or predecessors of a par- ticular piece of equipment may have set a precedent for the way certain operations are perrormed. For some common operations you may have to follow the established norm, even if that does not fi t in with the way other operations on your intel"face behave. Engineers often find this frustrat- ing-their elegant design is being soiled by what is seen as an artificial and unfair requirement created by hi story, rather dlan being part of the perfect solution to the problem at hand. Whe n th e interaction has to change, it can be advantageous to deliberately change the physical appearance so dlat the use rs will not be expecting th e same behavior. On an older product we had one red light and one yellow light, which had the words ALARM and CAUTION written on Lhem. For the newer product, the rules for when the lights turned o n and when they fl ash d completely changed because we had to comply with a new regulatory standal"d . Howeve r, the design of the fron t pane l was kept consistent with the old product, keeping the words ALARM and CAUTIO and the same color scheme. This caused confusion when users of the olde r product saw the same alarm names and expected the same meanin g. If the names had changed, there would have bee n a hin t to them to expect d ifferent behavior.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13