Seeking pointers on switch design.

From: (Robert Dorsett)
Date:         Tue, 24 Nov 92 05:15:42 CST
Followups:    1
Next article
View raw article
  or MIME structure

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 

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!!rdd