Feedback to 'To Err is Human' - Murphy's Law, July 2005
return to Murphy's Law
! 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:
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.
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
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
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,
Great 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
Harold W Graham
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
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
I just got around to
reading your GUI article in the July issue of Embedded Systems
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
Cheers -- Olin Sibert
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
~~Adjunct Faculty, University of Phoenix