Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 69 of 197

visible to th e user. The user may believe that the new device is doing a worse j ob of controlling the process, when in fact it is just doing a far bette r j o b of re po rting th e sta te of th e process. Having software in the loop will greaLly increase the amount and types of information that can be presented to the user. Engineers are inclined towards a more-information-is-always- be tte r philosophy because of the nature of their wo rk. This <;Ioes not always lead to belter interfaces. Users want enough information to solve the problem at hand. They may not be as skilled as a typical engineer at filtering out detailed information that is only of periphe ral in terest. When a display is conve rted from Theirs Most microcontrollers need external components to support in-system programming. a mechanical indicator to a software- con trolled displ ay, it may be tempt- ing to change the type, as well as the quantilY, of in formation presented . Consider the fu el leve l indicator on a car dashboard . If this is replaced by a small liquid crystal display (LCD) dis- play, a variety of information can be presented to the user in a number of possible approaches, such as express- ing remaining fu el as a percentage, or in gallons, o r in number of mil es remaining befo re the fuel runs o ut. In each ca e we allow the user to form a conceptual model of the fuel tank. Each of these models is differ- ent, but once we choose one we must be sure that we can fill in all of the information that the model requires. To conver t from gallons to miles remainin g, we need a conversion fac- to r. Using the average fu el consump- tion of th e car may not be suffi cie nt if the drive r has been sitting in a traf- fi c j am fo r 45 minutes. What seemed ini tially a ve ry simple requiremen t now demands tha t the fuel mo nitor also moni tor consumption. Now the user has a new rule to lea rn. The numbe r of miles that he reads from the mo nitor is o nly valid if he contin- ues in his curre nt driving pattern . Yo u may think that this is a trivial rule to unde rstand, but it is impo r- tant to realize that every rul e that is created by th e interface designer must eventually be learned by the user if he is to make the most effec- tive use of the inte rface. The rul e may be learn ed from the user manu- al, if he is o ne of the few people who wo uld read that section of the car 's manua l. Othe rwise, it is glean ed from observation, since the in terface does not explicitly tell him. Such hid- den rules can be dangero us. If the re are too many of them, the usel- will conslantly fin d himself surprised by the device 's actions and this will lead to mistrust. 68 DECEMBER 2000 Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13