
Poor UI Design Can Kill – Air Inter Flight 148, a Harsh Lesson Learned - damian2000
http://blog.martindoms.com/2011/01/24/poor-ui-design-can-kill/
======
dredmorbius
I'd argue that modal behavior _isn 't_ a bad thing _so long as those modes are
very clearly distinguished_.

It doesn't hurt if they're encountered frequently enough that the user /
operator has a clear sense of their distinction.

vi/vim is a modal editor. There are two ways of interacting with it: "insert"
mode, and "normal" (command) mode. In one, you're editing your document, in
the other you're _operating_ on it. While frustrating for new users, with
experience using modes becomes transparent, as they're switched in and out of
_all the time_. Though the _visual_ distinction of modes isn't always clear.

In a non-programming context, most sailboats have two primary operating modes:
under sail, and under power. Here, the contexts are evident from a large
number of cues in the environment, and how the boat is skippered is evident
from these cues.

Other tools have many modes of operation -- the various apps on a
smartphone/tablet effective change the mode of the device. Is it a phone? A
music player? A messaging tool? A web browser? The "mode" is specified by the
application. Usually visual cues of the display indicate which specific mode
is operative.

~~~
MrBuddyCasino
Everyone I've seen has trouble with this in the beginning. I'm not an advanced
vim user, would it really be impossible to make it modeless without losing too
much power?

~~~
ben0x539
You could probably make an equally powerful modeless editor but I don't see
how it could be anywhere near vim-like. Maybe if you had a foot pedal to
indicate what modes to interpret input sequences in.

~~~
robryk
Some built such a foot pedal: [https://github.com/alevchuk/vim-
clutch](https://github.com/alevchuk/vim-clutch)

~~~
MrBuddyCasino
I should have known. Still made my day.

------
bagels
More Airbus deadly UI:

[http://en.wikipedia.org/wiki/Air_France_Flight_447](http://en.wikipedia.org/wiki/Air_France_Flight_447)

The two sticks can be pointed in different directions. The plane does not
complain about this and averages the inputs. One pilot is pulling back, one is
pushing forward, plane crashes. Clearly there are some human factors here, but
from what I've read, on Boeing's aircraft pushing one stick causes the other
to move, much more intuitive.

~~~
idlewords
The Airbus vs Boeing approach to fly-by-wire is a bit of a religious issue,
like type safety or memory management in our world. Many words have been
written on both sides.

I think the UI issue in AF447 is much less clear cut. It's more a lack of any
indicator that pilots are making opposite inputs, rather than a misleading or
confusing display. Airbus did not anticipate that a pilot would stall a plane
and fly it directly into the ocean. There was a whole chain of events
(including some appalling human factors) that led to the tragedy there.

The avionics teams at both companies have put an incredible amount of thought
into how these systems are designed, and how they fail. The differences are
instructive, but we should refrain from being quick to judge which is more or
less intuitive.

~~~
omegant
Sorry but you are wrong, it´s not a religious issue, it´s a clear IU mistake
by Airbus.

I´m currently flying A-320, I´ve also flown B 737(300 and 800), and MD88. It´s
true that at the beginning the new airbus received a lot of heat from pilots.
After all they were trying to reinvent cockpits UI from 0. This led to a
series of design accidents (due to initial design mistakes ) like the one on
the article.

The initial idea it´s not bad: reducing weight (removing all mechanical and
hydraulic controls), inventing the glass cockpit, simplified system
management, etc..

It took over a decade to polish the cockpit (and the whole airplane, that had
tons of electronics related failures all around) to it´s actual safe and
workable state. Those issues, plus the idea that pilots had to readjust your
whole idea of a cockpit, were the ones that created that opposition. The
opossition it's almost gone now, although in general we pilots still prefer
Boeing aircraft (at least in Europe). Airbus airplanes fly very nicely and are
great too.

But now that we are used to the new IU, the concept problems are still there.

Main diference between flying normal fly controls and a moving auto-throttle
and airbus fly-by-wire:

-Airbus throttle levers don´t move while the auto-thrust is changing the power setting. All the other airplanes as far as I know do it.

-Airbus side-sticks don´t move when the autopilot or the other pilot is giving an input. Also as somebody explained above, the inputs are added, you can end with a double (or zero input), if you forget to push the priority button (in stress situations like last second corrections to land it´s easy to forget it).

Why this is a mistake? because when flying a modern airliner you have an
excess of information to process, all at once. A moving auto-throttle let´s
you know what the engines are doing through your hands, without having to look
at a tiny indicator at the instruments. Also it let´s you override the auto-
throttle briefly because you need more power or less power at a given moment,
without having to disconnect it. With airbus auto-thrust either the airplane
or the pilot has the control, and you have to manually takeover. This may be
dangerous at an approach that it´s already hard enough with cross winds or
heavy rain.

The same apply to the side-stick. Normal autopilots move the fly controls at
the cockpit while actuating them. This let´s you know what the autopilot it´s
doing. And of course when a pilot it´s flying manually, the other pilot knows
exactly what he is doing ALL THE TIME. He can slightly correct a maneuver
without having to take over the controls from zero.

Airbus has wiped a layer of fundamental information available to the pilots,
increasing the information overoosd through the vision. It´s the equivalent of
driving a race car with a playstation control. Most of the time this
information it´s not used(like in cruise), but you really, REALLY need it when
things become hairy close to the ground. In fact I routinely disconnect the
auto-thrust to land, with the Boeing and MD88 I kept it engaged.

Airbus knows this, but it´s too late to change 20 years of airplane
development. They´ll need to change too many things (systems, procedures,
certification, instruction), also right now it´s easy to change from flying
let´s say a A320 to a A 330, due to having very similar cockpits and systems
(that´s a great idea). The conversion course it´s short and relatively cheap.
Changing the controls would make this fleet changes much more expensive and
time consuming to Airlines.

Edit: overall small changes to improve clarity.

~~~
userbinator
I think the concept you're referring to is _self-indicating_ , or in this case
the lack thereof. A much more commonplace example that comes to mind is volume
control knobs on things like stereo amps; the "old style" had a knob directly
connected to the potentiometer controlling the volume, so it was self-
indicating and at a glance (or even just by feel if the pointer is tactile)
you could see what position it was set to. Now it seems fashionable to use
knobs that don't have any markings and will spin continuously, meaning that
you have to look at the display to see what the setting is.

To me it sounds like a cost-cutting measure - to have controls that move,
there has to be an actuator in them, which makes it more expensive. My stereo
which has self-indicating volume knobs actually contains a small motor that
rotates them when I use the remote control.

~~~
omegant
In airliners without flight by wire, the levers move because the automatic
system it's engaged directly to them. With fly by wire you have to replicate
that system, at least with the throttle levers. I guess that a servo motor and
a control-indication circuit it's not the cost that concerns Airbus. It's all
the chain of costs related to changing the flight philosophy. In the case of
the sidestick you could link them mechanically, with a disconnect lever to
isolate them.

------
jacquesm
Making mistakes with blender won't kill you but the modes are enough to drive
anybody nuts.

Another instance of a very poor choice that led to people being killed in
aviation was the one where 'take-off power' was interpreted as 'take power
off'.

I can't find a reference to that accident but the essence was that during a
go-around instead of full throttle the pilot reduced power causing the
aircraft to stall and crash.

~~~
WalterBright
That incident happened in the Air Force. It caused "take-off power" to be
renamed "full power".

~~~
VBprogrammer
Interestingly the word 'take-off' is only ever used in conjunction with a
take-off clearance over the radio (e.g. "Speedbird 101, cleared for take-off")
where as any other reference will use the word 'departure' (e.g. "After
departure contact London control on 123.12").

~~~
jorgis
Isn't departure the term for leaving the controller's airspace?

~~~
VBprogrammer
Not that I'm aware (though I'm not an expert). It is certainly used for one of
the many air traffic control units you can encounter at larger airports (e.g
"Contact departure on 123.45").

My understanding is that the word 'take-off' over the radio is (or at least
should be) treated like a loaded gun, you only say it when you mean it.
Departure is used in place of take-off where appropriate (e.g. "Speedbird 101,
holding short of runway 13, ready for departure.")

------
gear54rus
I, for one, fail to realize how can one design any half-complex app (gadget,
whatever) to be stateless. I mean, modes are literally _everywhere_.

So long as you can always tell which mode is the current one, I feel modes are
fine.

That said, the example in the article seems like a pretty severe oversight
(crucial indicator, completely identical modes) by itself.

~~~
dunmalg
>I, for one, fail to realize how can one design any half-complex app (gadget,
whatever) to be stateless.

It's fairly obvious, isn't it? A keyboard with no shift key is going to need
twice as many keys... but of course you'll also never find yourself
accidentally typing with caps lock on. That's the trade off. The UI becomes
more complicated.

~~~
SideburnsOfDoom
The shift mode key is usable, as the position of your finger gives you tactile
feedback of which mode you are in; and it enters a predictable state when you
let go.

The caps lock key does a very similar thing to shift, and is not very useful
on a modern keyboard. In my experience it is more often engaged by accident
than on purpose.

------
userbinator
Something doesn't look quite right... in the study linked to from the article,
the two figures (archived because the site no longer exists) are:

[http://web.archive.org/web/20050914030410/http://web.mit.edu...](http://web.archive.org/web/20050914030410/http://web.mit.edu/aeroastro/www/labs/ASL/MODE_AWARENESS/figure2a.JPG)

[http://web.archive.org/web/20050412110614/http://web.mit.edu...](http://web.archive.org/web/20050412110614/http://web.mit.edu/aeroastro/www/labs/ASL/MODE_AWARENESS/figure2b.JPG)

Notice that the mode indicator is only in the middle, far from the value it's
indicating the mode of, but in the cockpit picture in the article (
[http://blog.martindoms.com/wp-
content/uploads/2011/01/IMG_82...](http://blog.martindoms.com/wp-
content/uploads/2011/01/IMG_8281.jpg) ), you can see that there are actually
_two_ mode indicators, one in the same position as the one in the study and
one right above the value where it should be. A quick Google of other cockpit
images shows that the plane does have two. I wonder if this was an oversight?

~~~
sengstrom
In the first two images you link there are dual mode indicators - one in the
middle and one just by the value itself - in what looks like a manual they are
both shown lit up at the same time which seems more like a problem with the
documentation than what is shown in the actual aircraft picture (your third
link). I'd venture a guess that in "V/S" mode you'd see that indicated next to
the number just as you see "FPA" in the cockpit image.

------
josefresco
Someone closer to the browser development at Mozilla etc. could answer this
better, but wasn't the original implementation of private/incognito or "safe"
modes meant to be subtle?

Before we were all concerned for our privacy these modes were (and prob still
are) mostly used for surfing porn. When one is surfing for porn in "private"
mode it would benefit to have the UI not scream "I'M DOING PRIVATE STUFF".

------
shoyer

        the moral of the story is avoid modes whenever possible
    

We try to avoid using global state (and state in general) in software
engineering for this exact same reason. Humans just aren't good at keeping
track of more than a few things at once, even if they are the ones who
designed the system in the first place.

~~~
damian2000
There's nothing at all wrong with state (i.e. variables) in programs -
relatively few programs don't use state. The issue is with UI modes ...
reusing the same UI which means two different things according to the mode its
in.

~~~
shoyer
By "state in general", I particularly meant mutable or nonlocal state in
general. There is obviously nothing wrong with using variables.

To restate my analogy: the problem is when you can run the same function twice
with the same input and get a different result. Or when the same variable can
mean two totally different things depending on some external context.

------
tboerstad
This same example, along with many others, are covered in Don Norman's classic
"The Design of Everyday Things".

~~~
sehr
He made a course on it over at Udacity as well if you're into videos > text

------
cnvogel
See also this report at the FAA regarding the exact accident being discussed
in this blog post:
[http://lessonslearned.faa.gov/ll_main.cfm?TabID=2&LLID=57&LL...](http://lessonslearned.faa.gov/ll_main.cfm?TabID=2&LLID=57&LLTypeID=2)

This also includes pictures of the displays without (-3.3 and -33) and with
(appending two small zeroes for the latter) the fix employed by Airbus.

(I also commented on the original article, but await moderation.)

------
ExpiredLink
> _but I guess the moral of the story is avoid modes whenever possible._

Not a story for Vim aficionados.

------
camperman
Coincidentally, I watched an episode of Channel 4's Black Box series just last
night that discusses this accident. The whole series is worth watching but
this episode is here:

[https://www.youtube.com/watch?v=0wp-
Dbb2CO4](https://www.youtube.com/watch?v=0wp-Dbb2CO4)

Start at 3:34. Very revealing comments at 5:20 about pilots having to fight
with the "strong but silent partner" in the cockpit.

------
_pmf_
The question is whether a mode-less interface (that necessarily displays more
information at once and is therefore inherently more complex) would have
caused more problems than this single instance of a problem caused by the mode
mechanism.

------
roma1n
As the article points out, there are other factors involved in this accident.
IIRC, Air Inter did not equip its fleet with GPWS, for instance.

------
rbanffy
[http://www.amazon.com/Set-Phasers-Stun-Design-
Technology/dp/...](http://www.amazon.com/Set-Phasers-Stun-Design-
Technology/dp/0963617885) has many stories about user interfaces, bugs and
their occasional lethality.

------
nkozyra
UI/UX in general is extraordinarily complex. I think we can all agree on that.

With something as complex and data-driven as air flight, managing a UI will
always be complex as a result. As any given control needs to be available at
any given moment, you cannot obfuscate too much in the interest of
cleanliness.

With all that said, this issue is still not a UI issue, but a training issue
and perhaps also an issue with a lack of standards (I'm assuming, not in
flight) with jet UI. Even with poor UI, understanding what you're changing and
verifying it should boil down to training.

Based on this article, it seems like there's a lack of continuity between
aircraft in where controls are, and I wonder if there's ever been any push for
standardization. I realize not all craft could be complete mimics, but general
controls and indicators should be in the same general area, right?

~~~
jonahx
> Even with poor UI, understanding what you're changing and verifying it
> should boil down to training.

Absolutely not! Yes, I want the pilots flying my plane to be as well trained
as possible, but there also better damn well be a good UI in place to prevent
human error, because that's the one thing we can count on, no matter how good
training is or how well-intentioned people are.

------
lordnacho1980
Everyone who is typing on a keyboard is using a mode. For instance, my "mode"
is the HN comment box. Now of course that's clear to me because I can see the
text appearing in the correct place.

As for the airplane example, isn't it quite natural to expect the pilots to
have gone through extensive training? I understand consumer websites need to
be intuitive, but highly specialized things can't really be intuitive.

One big problem with complex things like a cockpit is that the guys who build
it are specialists in a different field from the guys who use it. So how are
they going to know if the thing is intuitive? I would imagine a pilot mostly
touches the same few commands each day, leaving most modes out of use most of
the time. By contrast, the developer needs to build the whole thing.

~~~
DanBC
Sure, pilots get trained. A cockpit is going to be complex. But there's a big
difference between complex and confusing, and some examples shown are not
particularly complex but are confusing.

------
SG-
On OSX, Chrome incognito mode is way more obvious since the top of the window
is a dark shade of blue/grey.

