Reading
|
PanelSoft User Interfaces and Usability for Embedded Systems |
Feedback to 'To Err is Human' - Murphy's Law, July 2005Excellent article ! Your examples are what set Embedded System Programming articles above the rest. One nitpick - you include a reference to ejection seats "... The lever to activate the ejection seat is placed over the pilot's shoulder ..." Not quite accurate. Three standard ejection methods are used in US aircraft. Pull up on twin levers on either side of the seat and squeeze the trigger, or pull a D-handle between your legs, or pull a D-handle/face curtain from the head rest above your head. For the accidental ejection, consider this article from the USN safety center: http://www.safetycenter.navy.mil/media/approach/issues/marapr04/pdf/IveLostMyRIO.pdf That is the tale of someone who was in the back seat of an F-14. When they rolled inverted, he probably flinched and pulled the D-handle between his legs. You don't have to haul it far to initiate the ejection sequence. I've also heard about accidental ejections caused by many factors: one was a very large pilot in an F-4. When the pen in the pocket on the upper left arm snagged a cable under the canopy rail, it initiated an ejection sequence. Surprise! Another was an F-4 on take off in Oklahoma. It departed the runway and collapsed the nose gear. The wreckage pushing up caused the seats to fire. Also, search the web for 'partial ejection' - the story of an uncommanded ejection from an A-6. The seat didn't leave the rails and the canopy didn't depart, so the crewmember was forced through the canopy, then left hanging in the breeze. His parachute fouled the controls and he was getting beat to pieces. But his pilot recovered on a carrier deck. The fouled parachute kept our man from slamming forward into the canopy shards and being shredded. A good ending to a bad day. Many seats have a 'canopy piercer' on top of the seat, so if the canopy doesn't blow off then the piercer shatters it before your head has to. After a successful ejection, the seat and the crew must be separated. An inertia reel pulls a strap tight - you used to be sitting on that strap. When it is tightened, you no longer are sitting there. Officially called the man-seat separator, it is more widely known as the butt-snapper. In training, it will toss you several feet across the room. Please continue to produce your excellent articles.Regards, Niall, I have been reading your user interface articles for some time now and apparently as a result, somewhere along the way, I have started to become more aware of the nuances of some of the everyday items I use around my house. I have recently noticed an annoying trait of the oven in my kitchen and every time I encounter this "feature" I think about how the programmer could have done things better. The problem is with the timer function that gets set to presumably to indicate that whatever has been placed in the oven is ready to come out. The process is begun with the press of a button labeled obviously enough, 'Kitchen timer' to which the user receives a response of three flashing zeros (0:00) with the word 'set'. The desired count down time is then entered through the numeric keypad followed by a press of the 'start' button to activate it. Now most people over the age of four are probably intuitively aware of the fact that there are 60 minutes in an hour, and as has becomes all too apparent, so is the oven. I have found that if you enter a time value of 60 minutes (or more) that the oven proceeds to beep obnoxiously at you, flashing the word ERROR and then proceeds to correct the entry by changing it to a value of hours and minutes (between 0 and 59). Every time I encounter this feature I wonder if it wouldn't have been far preferable for the system to silently ignore the "stupid user" error by simply adjusting the time format to hours and minutes without the visual and audible "Error" message. I find myself wondering if the programmer simply didn't know any better or if they thought it were necessary to imply that the user couldn't possibly know what they were doing? In this case, I was simply entering the suggested bake time on a box of lasagna which indicated it should bake at 325 for 70 minutes. Of course, the oven had to rudely point out that 70 minutes was an Error and that I must have meant 1 hour 10 minutes. I might find this type of appliance reaction acceptable if it weren't for the fact the Microwave that costs 1/10th as much is apparently smart enough to accept the value as entered and run with it This leads me to the idea for a user interface discussion topic: how to appropriately handle (stupid) user input, and I was wondering what your thoughts on this subject were? Best Regards, Niall's Response: Matt, That is a good example. It is kinda' related to the 'Designing out errors' section in my 'To Err is Human' article. If you can take a likely user action and redefine it from being an error, to something that is expected then the user has an easier time. In the case of your oven, even changing the word 'Error' to the word 'Converting' would make it friendlier, since it would suggest that the interface was doing you a favour, rather than correcting a mistake. I am not sure if I would like the oven to display 1:10 after I enter 70, or if I would prefer it to display 70 and count down from there, but I think the later seems nicer - though these kind of mappings can get messy if there is, for example, a + button that increases the time, and someone presses it after the counter has gone down as far as 59 - now do we use the hours/minutes model or the minutes only model. Thanks for the feedback -which will shortly appear on my articles feedback page for the article mentioned above, Niall MurphyGreat article, and I wish more GUI designers would take these types of things into consideration. Unfortunately, many people designing GUIs have no training whatsoever in user interface design principles. They're doing the best they can but are just not equipped. Another tip is to have someone who is not familiar with the product test drive your GUI. Developers are often too close to the product to realize that their interface is not clear. Several times at my previous company, I went through the GUI's as a "naive user" (since I wan't involved in the product development), and found many things that were non-intuitive, misleading, or just plain confusing. Customer feedback after tweaking these things was always overwhelmingly positive. And here's another twist on your vending machine example... Our vending machine uses a letter-number combination to make choices. I don't know how many times I have tried to select A10 by pressing the 'A' button followed by the '1' button and the '0' button, only to get whatever is in slot A1. (which is always something I don't like, of course!) To get A10, I should have pressed the 'A' button followed by the '10' button. I keep forgetting that the number buttons go up to 12, even though they are right there in front of me. Those darn users, will they ever learn?!Harold W Graham
Niall's Response: Harold, I completely agree with you on the point of developers being too close to the project. Often as the interface evolves, the developers accept something less and less intuitive, and the final product only makes sense if you were aware of that evolution - of course the real users were never exposed to the first few versions of the interface and find the final one baffling. On the buttons going above 9, I have seen similar things on TV remotes - they try to make it easier by avoiding the need to press the 1 followed by 0, but in fact ad to the confusion. On the vending machine, it seems that adding more letters, instead of adding numbers beyond 9, would allow the same number of combinations without causing the problem you describe. I post a lot of my feedback on http://www.panelsoft.com/murphyslaw, so your comments will appear there soon (I am a bit behind on web updates at the moment!). regards,Niall Murphy I just got around to reading your GUI article in the July issue of Embedded Systems Programming. I thought it was great! You gave lots of practical advice and examples that are easy to understand. I'm in the security business, and I find that a lot of security products have GUIs that translate, roughly, as: "To continue operating securely, you must now answer an incomprehensible question for which you probably have neither the expertise to understand nor the information necessary to determine the correct answer. Proceed or Continue?" Punting hard questions to the user is almost always a bad strategy, but it happens all the time.Cheers -- Olin Sibert Mr. Murphy: I just came across your article via an ACM newsfeed. Right on! I am passionate about good, clean software design as well (so much so that I have put together a modest website to espouse the idea). One example that you might enjoy is the elevator panel outside the State Library of Tasmania. You can see my description of it along with a terrible photograph of it here (http://cleancode.sourceforge.net/wwwdoc/gallery/TasLibElevator.html), but basically the numbers on the board go from top to bottom whereas the floors are numbered--like all other elevators--from bottom to top. Thanks,~~Michael Sorens
|
|
|