Subject: Seeking pointers on switch design.

From: [email-masked] (Robert Dorsett)
Date: Tue, 24 Nov 92 05:15:42 CST

I'm looking for pointers to articles on the human-factors ramifications of
switch design.  I've noticed an interesting difference between Airbus and 
Boeing switch philosophy.

Boeing seems to build the "on" state into the switch.  It might be a white
bar, indicating a closed circuit or open valve on a placarded systems 
a subdued "on" function description, with an "engage" bar, etc.  But the 
philosophy seems to be: "default" state == off (dark indicator), pilot action 
to turn it on (white indicator), operational state = on (white indicator)
until pilot turns it off again or an abnormal state occurs (colored indicator,
annunciator).  This doesn't violate the "dark cockpit" philosophy, since only 
one color (white) is used for selects, and abnormal states are clearly 
detectable.

Airbus (in the A320, and presumably the A340 and A330), on the other hand,
seems to use smart-logic to default to an "on" state which is completely 
dark.  The switches, when pressed, then show an *abnormal* state, like turning 
a fuel pump off.  Nearly all of the switches also have a "failure" state-flag, 
showing an amber or red fault message.  There are also systems with "mixed"
switch formats.  For instance, since a fuel pump state is normally on, a 
switch, when pressed, turns it off and indicates an off state.  But crossfeed 
valve switches, when pressed, show an "ON," followed by "OPEN," state, which 
seems more "positive."  So the Airbus philosophy seems to be: initialize
switch states at boot time (on, no indicator), pilot action to turn it off 
(illuminated, abnormal state), operational state = dark until pilot triggers 
a disconnect.

Seems to me that Boeing's the correct approach: a thou-shalt-not, drilled
into me at an early point, was never to use double-negatives to prompt user
actions ("Do you not want to save the file? Y/N") .  An action should ideally 
be expressed in *positive* terms.  And the interface should be consistent 
across all systems and within systems.

On the other hand, Airbus' design can be rationalized in that if the computers 
do *all* routine management, as they do, then bringing the pilots in the loop
at initial start-up is an invitation for error: in this model, pilot involve-
ment is an *abnormal* event, and signs of that involvement should be 
highlighted.  This raises interesting implications of the pilots being out of 
the loop TOO long, perhaps never dealing with a system or mentally "reviewing" 
that system for several flights, as would be the case with more "hands-on"
initialization and management.  This could be the reason behind Airbus's 
pre-flight "walk-through," in which each switch illuminates in sequence, 
requiring the pilot to depress it to extinguish the light.

Comments?  References?

---
Robert Dorsett
[email-masked]
...cs.utexas.edu!cactus.org!rdd

---

From: [email-masked] (Terrell D. Drinkard)
Date: 01 Dec 92 02:10:47 PST

>Boeing switch philosophy.
[Much interesting material deleted]
>requiring the pilot to depress it to extinguish the light.

I'd just like to address one small part of your message, the part dealing
with pilots being out of the loop too long.  I've read not to long ago that
there is research being performed on a tweak of the flight management
systems paradigm.  Instead of the FMCS just flying the programmed course,
the new thought is to have it tell the pilot the next step and have the
pilot initiate the maneuver.  This keeps the flight crew mentally engaged,
one hopes.  Apparently there is a history of incidents where the pilot was
too far behind the airplane.

I just love this industry!  :-)

-- 
Terry
[email-masked]
"Anyone who thinks they can hold the company responsible for what I say has
more lawyers than sense."