
USS McCain collision ultimately caused by UI confusion - tooba
https://arstechnica.co.uk/information-technology/2017/11/uss-mccain-collision-ultimately-caused-by-ui-confusion/
======
Animats
There was a ferry accident involving a similar transfer of control problem in
New York harbor.[1] Ferries have a lot of maneuvering modes and directional
thrusters, because they do so many dockings, and so they have a more complex
control problem. The pilot put the system into a backup dumb mode while in
cruise, then changed stations to where he could best see the dock while still
in the wrong mode. Rammed the dock at 12 knots. 79 injured, 4 seriously.

This is bad design. All the controls that can steer the ship should be tied
together and move together. How to do that was figured out decades ago.

The Navy still has this thing where they hate to give control of both speed
and steering to the same person. The helmsman and engine room take orders from
the officer that has the conn. But that officer doesn't actually operate the
controls. Some enlisted sailors do. This dates from the age of sail and steam.
Merchant shipping gave this up decades ago.

Back in the 1950s, the U.S. Navy built the USS Albacore. This was an
experimental submarine to test out the teardrop-hull concept. It wasn't
nuclear; it was just a test vehicle to see how such a hull form handled. It
was expected to be more maneuverable than previous designs, so it was set up
with aircraft-like controls. One person sat in the pilot's seat, strapped in
facing forward, looking at aircraft-type instruments, and controlled all the
maneuvering controls. It was a very agile craft.

The brass hated it. The person in the pilot's seat was really the one in
charge. The officers were just back-seat drivers. To this day, the Navy sets
up nuclear submarines so that different people steer, control power, and
control buoyancy.

(The British in WWII tried to control aircraft with multiple people. As
bombers got bigger, they wanted to put a senior officer in charge, but younger
people were better pilots. So they had an "aircraft commander" back-seat
driving, as well as a pilot handling the controls. This did not work out at
all and was rapidly dropped.)

[1] [https://www.ntsb.gov/news/press-
releases/Pages/PR20140408c.a...](https://www.ntsb.gov/news/press-
releases/Pages/PR20140408c.aspx)

~~~
katastic
User interfaces have gone backwards decades in quality.

Look at your car radio in a 90's car. You didn't need to look at it to figure
out how to push the radio button, turn the volume, anything. You could even
adjust the bass on the fly with a bass knob instead of navigating to your "eq"
menu to do it.

Now, you've got to look away from the road, realize what "mode" your in, you
can move the menu around to the "audio" section, then "fm", then select a
channel. And of course, it's a touch screen so there's no tactile feedback.
But at least it's got PRETTY ANIMATIONS!

My Toyota Corolla will blast audio out of the speakers _as it boots_ but the
_volume knob_ doesn't respond till it completely boots up. So you may start
the car and have 5-10 seconds of blasting radio that you can do nothing about.
GREAT JOB GUYS. A volume knob that needs to boot.

This is what was considered not only acceptable, but a "Feature" in a modern
vehicle with hundreds of millions of dollars in investment and NOBODY thought
to see if the radio interface was actually... efficient? It's not like people
interact with the radio/music console in a car on a regular basis...

Or my 2001 Jetta. It was one of the earlier cars with "climate control". What
that actually means is that to set it to heat, you have to tap the "plus temp"
button a literal 20-30 times to get it into "HI" to force heat on. And then
the day warms up and on your drive home you want AC? Tap it 20-30 times on the
"minus temp" button. There was no knob for AC temp. They gave you 1 degree
precision on a car that couldn't guarantee 10 degree temperatures.
Additionally, the volume control for the car had digital buttons. That's
right. Enjoy pressing up/down 50 times. No ability to rapidly change volume.
So when you switch radio stations or to casette/cd and the volume is highly
different you have to sit there pressing the button over and over. But, even
then, at least these were BUTTONS that you didn't have to look away from the
road to use. They had little tactile notches on them so you could feel around
for them.

~~~
foobarian
Don't get me started about TVs. When I grew up our family TV turned on in
seconds, and pressing channel up/down reacted in tens of milliseconds.

~~~
Cyph0n
To be fair, you weren't getting near-instantaneous full HD quality
broadcasting with DVR support on your TV back then.

~~~
dreamcompiler
The problem is that there's no reason one couldn't design a TV that had both
full HD and zero boot time with instantaneous channel switching. The reason
such TVs don't exist is simply engineering laziness.

~~~
Cyph0n
> The reason such TVs don't exist is simply engineering laziness.

If your answer to the question "why can't a billion dollar industry provide me
with instantaneous channel switching?" is "because they are lazy", you are
severely misguided (at the very least!). There are hundreds of extremely
talented engineers working full-time on these problems. If the solution were
as easy as you propose, the issues would be solved.

> zero boot time

That's not going to happen, ever, but I'll assume you meant "faster" boot
times.

Probably. Keep in mind that your average set-top box likely goes through a
more complex secure boot process than most electronic devices you would ever
interact with. Why? Because if people can run arbitrary firmware on a set-top
box, your cable company would lose a shit ton of money.

> instantaneous channel switching

You are bound by the latency required to demodulate a signal being broadcast
from some satellite ~30,000 km away from the receiver, decrypt the resulting
stream, and finally decode it, all _on the fly_ so you get a nice, continuous,
stutter-free full HD broadcast.

I am no expert, so there is probably way more stuff happening behind the scene
that someone else could probably shed light on. The point of my comment was to
demonstrate that things can sometimes be more complicated than they seem at
first glance.

~~~
averagewall
The distance to the satellite has nothing to do with it. You're using big
numbers to exaggerate the problem.

Decrypting and demodulating have be as fast as the data is coming, otherwise
the delay would grow until you never saw the end of the show. So that's not
the reason either.

~~~
oasisbob
Yes, the MPEG-2 decoder in your TV needs to be fast enough to keep up with the
transmitted data rate, but that doesn't mean that it has instantaneous stream
startup times.

Your TV doesn't have the information it needs to start displaying MPEG-2+ATSC
A/53 video for as long as 700ms. It needs to buffer quite a bit of timing
information and at least an I-picture frame before it can start displaying
anything:
[http://www.bretl.com/mpeghtml/startbuf.HTM](http://www.bretl.com/mpeghtml/startbuf.HTM)

Not only that - the overall standard has tight timing tolerances to keep video
arriving at the encoder/transmitter in-sync with audio/video leaving the
decoder in your TV. It's not like MP3 streaming where every client has its own
buffer size and time to start playing depending on network conditions,
bitrate, etc.

Having a reliable buffering process to keep receivers in-sync is a feature,
not a bug.

~~~
dreamcompiler
And the way to solve this -- at least for the case of consecutive channel
surfing -- is to have multiple decoders and multiple buffers. It's simply
precaching.

~~~
oasisbob
Eventually you're going to run into RF limits, especially if the signal is
coming in over the air.

You're sure this is engineering laziness? How much extra would you pay for a
TV with faster channel changing?

~~~
dreamcompiler
I'd pay extra for it. I'd pay even more for a TV that didn't spy on me and
that couldn't update its firmware without my consent. But I'm probably not the
target consumer.

------
jordanb
The _real_ cause of the collision was poor seamanship and failure to follow
the COLREGS on the part of the bridge crew of the destroyer. Most specifically
they were seriously in violation of Rule 6: the Safe Speed Rule

[http://navruleshandbook.com/Rule6.html](http://navruleshandbook.com/Rule6.html)

    
    
      Every vessel shall at all times proceed at a safe speed so 
      that she can take proper and effective action to avoid 
      collision and be stopped within a distance appropriate to 
      the prevailing circumstances and conditions.
    

The USS McCain was traveling at over 20 knots at the time of the collision,
through a very crowded area at the entrance of a traffic separation scheme. If
they hadn't been traveling at this obviously excessive speed they would have
had the time to think, and to work through little UI issues like the one
described here.

~~~
csours
The path to a disaster has been compared to a tunnel [0]. You can escape from
the tunnel at many points, but you may not realize it.

Trying to find the 'real cause' is a fool's errand, because there are many
places and ways to avoid the outcome.

I do take your meaning, reducing speed and following well established rules
would have almost certainly have saved them.

0\. PDF: [http://www.leonardo-in-
flight.nl/PDF/FieldGuide%20to%20Human...](http://www.leonardo-in-
flight.nl/PDF/FieldGuide%20to%20Human%20Error.PDF)

Amazon: [https://www.amazon.com/Field-Guide-Understanding-Human-
Error...](https://www.amazon.com/Field-Guide-Understanding-Human-
Error/dp/0754648257)

~~~
JshWright
I've never heard the tunnel analogy. Seems odd, since tunnels generally only
have one entrance and one exit...

In a lot of fields where the stakes are high and mistakes are costly (aviation
and emergency services are the two I'm most familiar with) the analogy used is
a chain. Break any link in the chain and you prevent the event.

[https://www.aopa.org/asf/publications/inst_reports2.cfm?arti...](https://www.aopa.org/asf/publications/inst_reports2.cfm?article=4401)

~~~
csours
It's the perception tunnel. There are many branches, but only one route is
followed. In hindsight, you can see all the branches and call out everything
that went wrong.

~~~
tantalor
Normally that is called "tunnel vision".

[https://en.wiktionary.org/wiki/tunnel_vision](https://en.wiktionary.org/wiki/tunnel_vision)

 _(figuratively) The tendency to focus one 's attention on one specific idea
or viewpoint, to the exclusion of everything else; a one-track mind._

------
lisper
It's not just boats that have safety-critical UI design problems. The avionics
in airplanes are becoming so complicated that managing the avionics is almost
more difficult than flying the plane.

I'm a private pilot who has been flying a Cirrus SR22 for twelve years. In
that time it has gone through two major glass cockpit avionics revisions. In
the first revision, called the Avidyne, the autopilot was either on or off. In
the current revision, called the G-1000, the autopilot can operate in two
modes: AP mode, where the autopilot is actually flying the plane, and FD or
flight-director mode, where the autopilot does all of the calculations to
figure out where the plane should be flying and displays a target on the
primary flight display, but the actual control of the plane is still in the
hands of the pilot.

If the plane is stable, it is _very_ easy to get fooled into thinking the
autopilot is flying the plane when in fact it is not. There are only two
visual indicators that tell you if the autopilot is actually flying the plane:
a small green LED on the autopilot console, which is down near your right
knee, and another small annunciator on the primary flight display. It looks
like this:

[http://is3.mzstatic.com/image/thumb/Purple71/v4/9a/36/ad/9a3...](http://is3.mzstatic.com/image/thumb/Purple71/v4/9a/36/ad/9a36ad6e-3ab6-a48c-3f67-d5318ba1f66b/source/552x414bb.jpg)

The autopilot indicator is indicating AP mode in that image. See if you can
spot it.

It has happened to me more than once that I thought I had the autopilot
engaged when in fact I had only turned on the flight director. I predict that
one of these days someone will die because they made this mistake in
instrument conditions.

~~~
rangibaby
Is there a purpose to the display being so colorful? If AP were the only green
thing and the others were monochrome it would stand out more.

~~~
btgeekboy
Most of the colors on that display have a rationale. For example, on the speed
tape on the left, the white, green, and yellow colors all map to colors of a
standard airspeed indicator. That the course (CRS) is green instantly tells me
I'm navigating by a ground-based VOR, not GPS (which would be magenta). Same
with the green diamond on the right by the altitude indicator. The waypoints
at the top are all GPS-calculated, therefore also magenta. At the top, the
green radio frequency is the one you'll transmit on. The blue airport icons in
the Nearest page (bottom left) indicate towered airports (matching those found
on standard aeronautical charts).

(In case it's not obvious, I've got a few hundred hours behind the G1000.
AMA.)

~~~
FabHK
Do you have any opinion on the G1000 (and subsequent Garmin flight decks) vs
competitors, such as Avidyne Entegra?

My feeling has always been that the Garmin UI was somewhat clunky and
suboptimal, possibly because they tried to keep it similar to the UI of
previous smaller devices (such as the GNS 430); a bit like if the iPhone
hadn't come along and we'd still scroll by putting our finger on a little
arrow in a scroll bar on mobile devices.

My impression was that other manufacturers had a better UI, but somehow didn't
make it in the marketplace.

~~~
abaillargeon
I think there's some truth to your GNS 530 theory... Pilots are not typically
that interested in stylish/modern UIs, and they're not thrilled when a
familiar UI changes. There are so many features now that it's a challenge to
find room on the PFD. I'm curious, which other UIs do you prefer? What do you
think of the G1000 NXi?

~~~
FabHK
> which other UIs do you prefer

Well, I haven't flown other glass cockpits. I just find the G1000 clunky and a
bit unintuitive, that's why I was wondering whether there are still viable and
possibly better competitors out there.

------
thunderplot
Militaries are good at making horrible UI. :-) I used to work at early warning
radar, that should notify our tops about incoming ICBMs. When there's a
target, classified as "suspicious" or "something that's going to fall onto
{our, neighbour} territory", the following happens: \- very loud sine 1200Hz
tone starts sounding \- the only output device, "fast-printing device", starts
dumping hexdumps of internal structures to long 10cm wide paper (like toilet
paper). \- the whole chain of command start yelling to each other (downwards),
demanding data and info about the target.

So as the last person in that food chain, you're in the middle of panic,
1200Hz are drilling into your brain, damned thing prints hexdumps, and you
need to apply binary shifts and ANDs, convert from floating point hex to
decimals and pray that there's enough paper in damned FPD.

I could never imagine worse UI, it's strange that we didn't start WW3 in those
conditions.

~~~
wmeredith
"Militaries are good at making horrible UI."

This is extremely applicable: [https://hackernoon.com/why-the-dmv-website-
sucks-2f27a367baa...](https://hackernoon.com/why-the-dmv-website-
sucks-2f27a367baa9)

Disclaimer: it's an article I wrote about why government software contractors
suck at their jobs.

------
cocoablazing
A key occurrence during this mishap:

0127 The Officer of the Deck ordered course to the right to course 240T, but
rescinded the order within a minute. Instead, the Officer of the Deck ordered
an increase to full speed and a rapid turn to the left (port). These orders
were not carried out.

0129 The Bosun Mate of the Watch, a more senior supervisor on the bridge, took
over the helm and executed the orders.

I've witnessed multiple similar situations on a warship (imminent loss of
extremely critical systems), and had to forcibly push the watchstanders out of
the way to do their job for them. Many people are going to freeze when the
SHTF, and there may be no prior indication.

Major attaboy to the BMOW who saved many of his shipmates. Given the incident
angle of collision, many more would have died from a perpendicular collision.

~~~
carterehsmith
I don't know which one is more bizzare here - the story itself, or the barrage
of "this is due to bad UX" comments in this thread.

So I guess if this warship fired all its rockets away, "due to bad UX", and
destroyed a small nation, I guess the comments would also be about a bad UX.
Oh crumbs, the "check status" button was so close to the "start armageddon"
button. Perhaps we should submit a meek complaint to Microsoft or something.

"Commander Alfredo J. Sanchez, "noticed the Helmsman (the watchstander
steering the ship) having difficulty maintaining course while also adjusting
the throttles for speed control.""

So... we gave the control of a warship to some guy that... has some difficulty
navigating through the straits that like 1M of ships go through every day,
without problems. Mind you, this is the navy that is supposed to be highly
trained to deal with real-world issues such as naval blockades, pirates, and
even wars.

It does not make sense at all. Allegedly there were some cuts to funding for
navy. Maybe someone is trying to make a point. I do not know, this is just
unexplainable. Certainly nothing to do with just "bad UX"

~~~
FabHK
The problem is that you can't "fix" humans. They'll make mistakes. Aviation is
as safe as it is precisely because it moved past the "pilot error! that guy
just made a mistake, how can one be so stupid" attitude evinced in your
comment.

You have to look at the entire accident chain, and at the entire system,
including training, supervision, redundancy, and, indeed, UX.

~~~
mjevans
Good UI makes the effort of doing the 'right thing' very little, and the
effort of doing the 'bad thing' as costly as possible.

Design (in my opinion) is planning out what good and bad things are for a
given tool and determining how to express that through the UI.

~~~
PuffinBlue
> Design (in my opinion) is planning out what good and bad things are for a
> given tool and determining how to express that through the UI.

I disagree with the premise you have that the designer deciding what is good
and bad is the whole or even the right story. I think I might agree with the
implication that a system should make doing cognitively difficult/safety
critical things easy but there is no possible way to plan for all
eventualities, that's why we have 'intelligent' controllers in ultimate
charge.

One day we might have artificial intelligence in charge but we're not there
yet.

So instead of the goal of good UX being the designer planning out what is good
and bad, it is much better to design a system that reduces cognitive load but
presents information about the current state of the system in the most obvious
and intuitive way possible. It should do everything it can to make sure the
operator understands the current state of the system.

In terms of operating complex physical systems like ships and aircraft the
ultimate goal of designing control systems is to simultaneously take as much
of the burden off the operator as possible but present all information needed
in order to bring the system back to an _understood_ state as rapidly as
possible following deviation from that state. This is the only way to maintain
_control_.

It's reasonable to try and make it difficult to get to a state that is
'uncontrolled'. But it's imperative that more credence is given to getting a
system back to an understood state once the controller finds them self in one
that's not understood. It may get to this state in a way the designer didn't
plan for, so getting out of it has to be incredibly quick and easy.

Personally, I put more stock in getting the system in an understood state than
a controlled one as from there it's easier to return to control. Without
understanding the state of the system it's easy to make further mistakes.

------
tlb
Amazing that someone would design in multiple steering wheels, only one of
which is active, and no big indicator to make it super-obvious which one it
is.

Also amazing that there's a mode where moving a control sometimes controls all
engines, sometimes just one.

~~~
mschuster91
> Also amazing that there's a mode where moving a control sometimes controls
> all engines, sometimes just one.

This is a fallback in case the primary rudder fails. You can still shift left
or right, but you will take more time and it will be far less precise than
using the rudder.

This is also valid for aircraft, where not only the rudder can be compensated
but also the elevator (aka up/down) by simultaneously modifying the power of
all engines. You can see a list at
[https://en.wikipedia.org/wiki/Flight_with_disabled_controls](https://en.wikipedia.org/wiki/Flight_with_disabled_controls).

~~~
azernik
The UI issue being that ganged control should have been the default, but
separate control was instead.

------
rdl
Everyone in the chain of command in 7th fleet (from ADM Smith on down through
the captains and those standing watch) should have been separated and
potentially prosecuted for negligence. UI confusion would be an excuse for an
untrained civilian being put on the bridge and told to run the ship, but not
for professionals, and obviously many systems failed for this to happen. When
the military runs well, it runs on accountability -- there's been a serious
shortage of that, especially above O-6, for a long time.

"Retiring" without losing rank doesn't cut it.

~~~
tormeh
From what I hear the Navy has been very diligent about accountability. There
are problems you can't really hard-ass yourself out of.

~~~
jessaustin
Multiple crewman have died from multiple preventable errors in multiple
incidents. I haven't heard about any firing squads for COs? Normally we
Americans are so enthusiastic about severe penalties? Watch-keeping and safe
navigation are _boring_ , so officers need extra incentive to pay attention to
them!

~~~
azernik
"Preventable" doesn't mean "preventable by harsher discipline".

~~~
jessaustin
Haha this has got to be a reference to theWarOnDrugs...

~~~
azernik
Not _intentionally_. But now that you mention it...

------
hliyan
Actual naval experts in HN notwithstanding, I think it's worth remembering
that a little knowledge, at times, can be a dangerous thing. This is true of
many topics on HN that are only obliquely related to software engineering.
Silicon Valley has earned a great deal of confidence by disrupting other
industries by out-thinking their experts, but perhaps we should temper that
confidence a little, least it becomes hubris...

Bottom line, if we're going to dismiss experts, I think we should be armed
with a little more than the knowledge we garnered from an internet article.

------
Zak
Aside from the lack of clarity about which station has control over what,
which should be made _really_ obvious, with additional warnings when someone
sets a control input on an inactive station, this seems bizarre to me:

 _While the Ship 's Control Console has a wheel for manual steering, both
steering and throttle can be controlled with trackballs, with the adjustments
showing up on the screens for each station._

I've never been on the bridge of a ship, but I've operated a lot of vehicles
including boats, ATVs, snowmobiles, cars, bulldozers and once, an army
Blackhawk helicopter simulator. These very disparate vehicles had one thing in
common: there's a relationship between the position of any movement-related
control and the movement commanded, and there are stops at the limits of
control input.

Trackballs do not have either property, and I'm having trouble thinking of
advantages they might offer in this application.

~~~
mjlee
I have been on the bridge of a ship, as an Officer of the Watch in the Royal
Navy.

Ships have both open loop and closed loop control systems. Closed loop is the
normal mode of operation, but there are open loop systems to fall back to. The
procedure tends to involve sending someone down to the rudder to communicate
back the actual angle of the rudder.

The difference between a warship and a most other vehicles is that you can't
simply stop a warship and get out. You need to be able to fight even if you've
lost the feedback loop from the bridge to the rudder. For the comparison to
the blackhawk, in a ship you can at least do something about mechanical
failures in control systems.

------
CamperBob2
_The Navy 's investigation found that both collisions were avoidable
accidents. And in the case of the USS McCain, the accident was in part caused
by an error made in switching which control console on the ship's bridge had
steering control_

So, basically this was a reprise of the AF 447 crash at sea, where lack of
clear command authority combined with a maddeningly poorly-thought-out UI
resulted in a serious accident with loss of life.

At least they didn't have genuine malfunctioning hardware on top of everything
else, the way the Air France crew did. They just thought they had a
malfunction.

~~~
foldr
>So, basically this was a reprise of the AF 447 crash at sea, where lack of
clear command authority combined with a maddeningly poorly-thought-out UI
resulted in a serious accident with loss of life.

I don't want to take this off on a tangent, but this theory of the AF 447
crash keeps getting repeated online despite the fact that the accident report
did not conclude that the UI was a factor.

If it's got to the point where the pilots have lost track of who's flying the
plane, are ignoring the (audible) "dual control" warning, and are making
conflicting control inputs, the plane is probably going to crash anyway.
Linking the sticks physically has potential safety downsides in addition to
safety upsides (e.g. in the case where one stick gets stuck, or a
incapacitated pilot holds it in a particular position).

See e.g. here for further info on sidesticks and safety:

[https://aviation.stackexchange.com/questions/14027/sidestick...](https://aviation.stackexchange.com/questions/14027/sidestick-
safety-concern)

~~~
NoPiece
I'd call it an interpretation, not a theory. But clearly the conflicting
inputs was a UI problem, and while there may be tradeoffs, a better UI could
have prevented the AF 447 crash.

~~~
inferiorhuman
Basic airmanship could've prevented the crash too. The pilot-in-command got a
stall warning and pulled back on the stick, climbing to 38,000 feet.

That's not a UI issue, it's a forgetting one of the most fundamental rules of
flying issue.

[https://aviation.stackexchange.com/questions/1418/what-
happe...](https://aviation.stackexchange.com/questions/1418/what-happens-when-
an-airplane-stalls-and-why-do-pilots-practice-it)

~~~
avar
You normally can't stall an Airbus aircraft, except in cases where the flight
mode changes as it did in this situation. This was a huge part of the problem,
an emergency occurred and the pilots were effectively flying an aircraft they
hadn't flown before.

Fully pulling back the stick is what you'd normally do in an Airbus to gain
altitude. It's guaranteed not to stall the plane.

~~~
inferiorhuman
> Fully pulling back the stick is what you'd normally do in an Airbus to gain
> altitude. It's guaranteed not to stall the plane.

I'd love to see some documentation on "pull back in a stall". In fact, this is
all I could find:

[http://www.pprune.org/tech-log/415373-new-airbus-stall-
recov...](http://www.pprune.org/tech-log/415373-new-airbus-stall-recovery-
procedure.html)

------
trhway
>At this point, everyone on the bridge thought there had been a loss of
steering. In the commotion that ensued, the commanding officer and bridge crew
lost track of what was going on around them.

now add to that picture (according to your historical preferences) a salvo of
the 10 inch battery from an enemy battlecruiser 10 miles away or 2 Moskits
rushing at 2.5x Mach ... blaming UI is just so childish and lame. Like our Sun
executives blaming market conditions back then 10 years ago when everybody
else had already been enjoying the boom for a few years.

------
wruza
Maybe I’m too late or too simplistic, but why do ships and aircrafts have so
complex control systems in normal functioning modes at all?

Why can’t layman ship commander like me just tell the system to be “there” in
specific time via hand-drawn or standard route? If my engines malfunctioning,
or steering lost it is one thing, but if everything is okay, can’t a simple
swipe-to-sail iphone app just coordinate all ship controls to “be there in
3m08s” in most effective way according to the safety rules?

Now it seems like all the precise counters and sensors are passed to slow,
biased, narrow-focused and error-prone device that is my mind to get goal-
related feedback. And this device happens to be proud of being it. As a
programmer, I just can’t understand it. Do commanders quickly solve unsolvable
differential equations in realtime or what?

~~~
Zeebrommer
Although I think ship control can definitely be made more user-friendly, what
you are asking for is of similar complexity as a self-driving car.

~~~
marcosdumay
Looks more like an aircraft's auto-pilot. It's not something that would look
for obstacles, read signs, or take any kind of input from the environment
besides current position.

------
tomohawk
Sometimes having too much money is worse than not having enough. With a
tighter budget, you have to wonder if such an extravagantly over functional
interface would be created.

~~~
theyregreat
I’ve seen hundreds of millions (!!) wasted at a university on a program of
software projects that failed miserably.

Having too much money allows for unproven, complicated or arbitrarily selected
solutions and more bureaucracy that introduces Tragedy of the Commons
mediocrity and diffusion of responsbility to address higher-level risks.

------
exabrial
My friend's boat is a dual engine diesel, 78ft, two stories. It has a
controller where you set a course and a computer controls the throttles and
rudder. On the very choppy lake of the Ozarks, this is a handy feature.

You're telling me a million dollar guided missle destroyer _can 't_ do this?

~~~
jessaustin
Everybody come to the beautiful Lake of the Ozarks, where you too can be
menaced on narrow inland waterways by giant overpowered wave-making
monstrosities like that of 'exabrial's friend!

At least you won't have to worry about uncontrolled USN vessels...

~~~
exabrial
HAHA :D

I took a 5mi trip up the channel on jet skis on memorial day weekend. Holy
smokes, I thought I was going to die. The channel chop is no joke!

------
Camillo
The headline is clickbait, and directly contradicts the report's conclusions.
The article says as much ("While the report lays the blame on training"), but
by that point you've already clicked.

But look at that bridge schematic. There were TEN PEOPLE in that room, and
they couldn't keep an eye on the radar, raise a collision alert, radio the
other ship, etc. They just completely lost it.

The John McCain was put in a state of complete confusion by a simple control
error they themselves made, while cruising along a commercial shipping lane,
at peace. How would they have handled an enemy attack?

------
robbrown451
There were multiple causes. The article makes this clear, but the title to the
HN post implies there was only one main cause.

The UI should be fixed. There should be a process for helmsmen to report
problem UIs.

And of course training. But you can't really train for situations that you
don't fully understand, and the people designing the UI are really the ones
who need to put the hard work into understanding all these possibilities.

------
ericb
On a related note, it occurs to me that UI/UX for car navigation systems and
cell phones is an actual life-and-death matter.

Maybe we should treat it differently.

------
lordnacho
Even specialised UIs need to be intuitive. You should need to know the domain
(navigation), but not the specifics of everything the UI can show.

The problem with this kind of thing is people are sent on a course, which
gives everyone a false sense of control and understanding. Clearly the crew
didn't understand it, leading to a panic and wasted time.

------
Johnny555
A billion dollar ship seems like the kind of place it's worth having real
physical controls and indicator lights for functions like this.

I get why auto makers love touchscreens, because buttons, knobs and lights are
comparatively more expensive than adding another menu entry to the
touchscreen, but that's not the case in an expensive ship.

------
polynomial
Alan Cooper observes in his book Inmates are Running the Asylum than the
majority of non-terrorist related airline disasters are caused by bad UI.

Not instrumentation as such, but the modern version of it which is the
"interface."

One example he cites is a pilot selecting a destination beacon using a
"simple" drop down menu. 2 possible options, similar in name and adjacent on
the alphabetized list are deadly in difference. One is the correct
orientation, the other takes the plane directly into the side of a mountain.

Given the state of confusion that is modern UI design, this revelation is not
too surprising.

------
pbh101
UI flaws have hit the Navy before, with even worse consequences [1].

[1]
[https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air...](https://en.wikipedia.org/wiki/USS_Vincennes_\(CG-49\)#Iran_Air_Flight_655)

~~~
dragonwriter
Nothing I see in that article (or anything else I've seen about the incident)
attributes it to a UI issue.

Not all errors made by users are the fault of the UI.

~~~
pbh101
You're right: nothing in that article mentions the UI.

I learned about the incident in my computer ethics class in college (along
with Therac-25, etc).

Quickly-skimming, it looks like Cracked has a decent writeup of the UI issue
specifically [1].

[1] [http://www.cracked.com/article_19776_6-disasters-caused-
by-p...](http://www.cracked.com/article_19776_6-disasters-caused-by-poorly-
designed-user-interfaces.html)

~~~
LeifCarrotson
Because that website is cancer if you don't have an ad-blocker, I'll quote the
relevant text:

> The screen showed the operator what objects were detected on radar, and if
> he clicked on an object, it would track it. But if the operator wanted to
> get more information about the object (in this case, by listening in on its
> radio signals) to find out what it actually was, he had to move a separate
> cursor and click on the object again.

> It's clumsy and unintuitive, and it made it really easy to forget which
> thing they were highlighting at any given moment -- the operator can be
> tracking one object and have it display the information for a completely
> different one because he forgot to move the other cursor. It's the kind of
> user interface that wouldn't make it out of the testing phase of a cheap
> browser game. And it cost the passengers of the plane their lives.

> That's because the operator in the USS Vincennes thought he was listening to
> the incoming aircraft (the Airbus full of innocent people), because that's
> the thing he selected, when he was actually receiving signals from a parked
> F-14 several miles away, because that's where his other cursor was.

> Granted, the transmissions alone wouldn't be reason enough to shoot down a
> plane: They'd also have to think that it was moving like an enemy aircraft.
> Unfortunately, the stupid system made that mistake pretty easy, too. Instead
> of telling the operators at the Vincennes if the approaching plane was
> ascending or descending, the system just showed them the present altitude on
> a smaller monitor. The operator had to write down or memorize the altitude,
> wait a few seconds, then ask again and mentally compare the two results to
> see if the aircraft was going up or going down.

> Because of this, a calculation error led an operator to report that the
> Airbus was descending toward the USS Vincennes, like a combat aircraft
> would, when it was probably getting the hell away from them as fast as
> possible.

------
hinkley
> The report found that the McCain did not have the right type of watch on
> duty for navigation in congested waters and that watchstanders' training was
> insufficient. But there was never a warning signal from the Alnic of
> impending collision or a change of course by the merchant in an effort to
> avoid the collision. "Despite their close proximity, neither JOHN S MCCAIN
> nor ALNIC sounded the five short blasts of whistle required by the
> International Rules of the Nautical Road for warning one another of danger,"
> investigators found, "and neither attempted to make contact through Bridge
> to Bridge communications."

What a comedy of errors.

------
greedo
The headline is inaccurate. While the design of the bridge leaves a lot to be
desired (in the eyes of laymen), the real issue is an incredible dereliction
of duty by 7th Fleet and the USN in general in terms of training and staffing.

------
matt_the_bass
I've been on the bridge of many commercial ships including giant yachts and
cruise ships during trafficked maneuvering. They never have that many
personnel involved on the bridge. Maybe that is part of it?

------
PythonicAlpha
Alan Cooper wrote some books about User Interface design and this really
reminds me of his books and talks.

When you cross a car with a computer, what does happen?

When you cross a ship with a computer, what does happen?

Ship steering and management was developed in hundreds of years, than comes
the computer and changes everything in some decades ... no wonder, that some
friction happens.

I am not anti computer, because I am a developer myself, but you must be very
carefully in designing these things. I even see it in our modern cars and cell
phones ...

------
jonsen
"His theoretical insights are grounded in an extended analysis of ship
navigation—its computational basis, its historical roots, its social
organization, and the details of its implementation in actual practice aboard
large ships.":

[https://mitpress.mit.edu/books/cognition-
wild](https://mitpress.mit.edu/books/cognition-wild)

------
ilaksh
Shouldn't it have some kind of automated collision avoidance that would have
at least given an optional course correction?

~~~
jzwinck
I sail regularly in the waters where this occurred. They are extremely crowded
with large ships, small fishing boats, and more.

The Navy ship was moving at 12 knots which is relatively fast in the local
context. Not only does this open them to a violation of the Safe Speed Rule
discussed in another comment, it means that any automated course correction
would have a decent chance of putting them on a new collision course with a
different boat. Perhaps even a small one their radar will not see.

The solution is to slow down. This is well known in nautical practice: if
things are not going your way, slow down. If you are not sure what to do, slow
down. If you are unable to control your vessel, slow down.

------
mikerathbun
I would be interested to see how much liberty the contractors who develop
these systems are given. Are they given a rigid spec by the Navy and expected
to implement it exactly or are they given a general proposal which allows them
to iterate on UI from lessons learned from previous accidents caused by
confusion.

------
matt_the_bass
Good maritime discussion on gcaptain

[http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-
wa...](http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-was-the-
navees-fault-twice/46496/2)

------
bluetwo
I'm sure we've all read "The Inmates are Running the Asylum" by Alan Cooper.

------
kepano
Reminds me of the book "Set Phasers on Stun" which details stories of poor
designs that caused deadly disasters. An essential read for anyone designing
these types of systems.

------
_pmf_
It's not necessarily the UI that must have been confusing, it might have been
that these modes of operation are inherently confusing.

------
trisimix
Pretty sure all collisions are avoidable.

------
tacotornado
There was a big ferry accident involving a similar transfer of control problem
in the New York harbor.

------
jrochkind1
not surprised

------
ineedasername
Nope; No, just not at all:

UI Confusion is never "ultimately" the cause for accidentally killing people
through poor operation of a $2 billion piece of military equipment. A UI may
suck, many do, in or out of the military. So, training. and then more
training.

I don't have a high stakes job, but if I allowed code-completion to drop
tables, commit the change, delete the backups, and then burn down the
building... well, that's not on the UI, that's on me.

So unless we're talking MS Word Clippy-- and I think the article would have
mentioned that-- UI can't take the fall on this.

Besides: It began with the Helmsman sending all control instead of just
throttle control to the Lee Helm station. That mistake isn't explained as a UI
issue, it's glossed over, but everything came from that initial screw-up.
Sure, afterwards there was confusion, but even then, "OMG WE LOST ALL STEERING
INCREMENT THE IDIOTIC PANIC OPTION VARIABLES!" isn't really an acceptable
response. How about, calmly, "Helmsman double check that control assignment if
you please <insert navy jargon cliche />"

~~~
josephwegner
Interestingly, this is the opposite of the direction much of the tech industry
has been moving with post-mortems.

\- [http://firstround.com/review/this-is-how-effective-
leaders-m...](http://firstround.com/review/this-is-how-effective-leaders-move-
beyond-blame/)

\- [http://code.hootsuite.com/blameless-post-
mortems/](http://code.hootsuite.com/blameless-post-mortems/)

\- [https://codeascraft.com/2012/05/22/blameless-
postmortems/](https://codeascraft.com/2012/05/22/blameless-postmortems/)

