The U.S. Navy's $100M checkbox (2019)

The Navy has the stupidest possible ideas of sleep hygiene, boiling down to "it sucked for me so it should suck for the next guy, too". I had friends in departments who worked 6 hours on, 6 hours off, 6 hours on, 6 hours off repeatedly. In that pattern you never get a solid 8 hours of uninterrupted sleep, ever. Yeah, it's possible that emergencies will arise where you have to work 24-48-more hours straight without relief because the ship is under attack, or on fire, or barely afloat. That's not a reason to try to kill sailors with sleep deprivation the rest of the time.

Having spent 10 years as a Navy Nuclear Propulsion Operator on two different submarines operating the reactor plant, I can tell you I am not surprised by incidents like these. In order of importance: 1) Lack of sleep (it wasn't unusual to operate on no sleep over a 36-48 hour period) 2) Poor or insufficient training. Just because you are "trained or qualified" doesn't mean you know how to operate. 3) Poor or missing procedures (let's call it UI/UX for today's lingo). Many procedures were vague, and drawings were hard to understand. The Navy has a feedback system for this, but it often takes months/years to resolve.

Having said all that, the issues pointed out in the comments and the article, including my comments, have existed for decades in the Navy. At some point, it comes down to the command's leadership and superiors to ensure these issues don't happen. A poorly designed checkbox is the last thing that caused this issue.

This is also very important for lorry drivers, to the extent that there's all sorts of tracking and enforcement for how long they're driving. But in this case it sounds like poor staff management: this isn't a convenience store running on zero-hour contracts, they should have a shift plan in place that provides adequate cover before even leaving port.

Ignorance is not a “dick move”, it’s having something to learn.

The extreme sleep deprivation doesn’t really conflict with the author’s point that better UI could have avoided this. Better sleep could have too.

I ran the nuclear power plant on the USS La Jolla (SSN-701) for five years. Per the Engineering Department Organization Manual, you're not allowed to do any operations in the power plant if you haven't gotten a certain number of hours of sleep in the past however many hours. This is the most laughably ignored rule on the ship. It's very normal to have people operating the power plant after being awake for 40 hours straight. (I still remember getting yelled at for falling asleep during training because I'd been awake for >24 hours, and the training was about the importance of being well rested and how the Department of Transportation developed its sleep requirements by studying railroad operations. Maximum irony.) Naval Reactors, the organization that supervises the whole navy nuclear program, knows this is the norm and helps hide it. I remember, during the briefing prior to every reactor startup, the engineering officer would say loud and proud "If you don't think you can perform your duties for whatever reason, any reason at all, if you're too tired, raise your hand." One time I had been awake for more than a day straight and I was suicidal, I had been scheduled for 12 hours on watch, 6 hours off watch for several days, so I said fuck it, and I raised my hand. "Per the EDOM, I am not allowed to stand watch because I've been awake for far too long." The engineer recommended me for Non-Judicial Punishment for 1) not being ready to stand watch and 2) having stood watch previously already too sleep deprived to stand watch. I wasn't actually punished because I threatened to call the DoD Inspector General. The whole system is rotten as fuck.

E: since many are quoting authors preface about not knowing much, but doing their own research

My beef is, given disclaimer, I read piece to end thinking author made good faith effort at research, only to see author characterize, near conclusion, sailor/operator severe lack of sleep hygiene as "drowsiness" which can be designed around. That expecting enforcement of better operational conditions is "stupid", which may feel true in military context. But 7th fleet went from 4 accidents in one year to none after brief operational pause for a month, I dont think the result is because USN bureaucracy figured out a way to improve UXUI on Arleigh Burkes software. Also note the other 6 fleets with... more relaxed tasking relative to west pac weren't suffering from same level of dysfunction. UXUI is important yes, but sometimes operations are ran so badly that you should prioritize improving the way it's run instead of pretending it can be bandaid over with a better checkbox.

On the other hand, in a time of war, it's likely the exact same conditions of sleep depravation and poor training could exist. UX is the element that could be fixed permanently. The Navy absolutely should fix all of the issues in the NTSB report, and all the UX issues discussed in this blog post.

Yes I’ve heard from multiple sources that the Navy’s training is not what it once was. For officers, much of their training is done on the ship via self study in their spare time instead of in a classroom.

I think that in this case probably the UI could have been better, but it was functional, and with a well trained helmsman, it shouldn’t have presented a safety issue.

The thing that bothers me most about the navy sleep deficit is that this is a peacetime sleep deficit. If sailors are at the ragged edge of capacity in peacetime, how are we possibly setting them up to function in a real war, when things will be 3x more chaotic and stressful?

USN Ships are crowded, and unworkable.

https://en.wikipedia.org/wiki/Ehime_Maru_and_USS_Greeneville...

Note: Japanese ships do not get into collisions. Why? Their trains run on time.

You have 4 control surfaces? And a steering command? Why not have all 5 people looking at each other and communicating. Add two people who are Looking each direction to know where the ship is GOING?

When you fix the organizational attitude, that its supposed to be hard...

I mean it only takes five sentences for the author to make it clear he has absolutely no idea what he's talking about:

> Before going any further, I want to make it clear that I am just a civilian piecing together this story from whatever information I can glean from the internet.

I mean the real thrust here is that the controls were extremely confusing even when you weren't sleep deprived so sleep hygene is never going to be a fix for something that is frankly bewildering even when fully rested.

There is a Chapter in “Turn the Ship Around”[1] where the author mentions a case of a navy officer (I think) that practically abandoned post because of all the unorganized ways and routines made him actually have sleep deprivation.

There are other tidbits of information in the book, of course from one point of view, that are mentioned in other comments here that are still happening and it’s baffling to me, not because I believe 100% of the book, but because you’d think at some point they would get fixed or partially mitigated with a migration plan.

I hate it such malpractices are still acceptable and even encouraged by an institution as important as the Navy.

--------

[1]: https://davidmarquet.com/turn-the-ship-around-book/

I didn't read it necessarily like that. It can also mean that even with fully rested sailors, the same confusion can still happen again, because the interface is inherently confusing.

In a sudden life-and-death situation combined with information overload, a bad interface can be what tips the scale into disaster.

A factor to note: Proportion of humans who know how to use touch UI but not the other UI.

---

I wonder if there exist systems that measure response times, error presses etc. consistently over time for different mediums. There is huge amout of underlying behaviour to model from fact that one mistake may cause more risk in different types of ship-environment-task scenarios to the fact that probably certain variables need mapping to others, which complicates analysis little bit.

---

Empirical data from use is actually not sufficient for testing. For the designs, one essentially wants to subject then to high voltages, acid, sea water, high pressures, coffee et cetera in extreme amount systematically in a lab.

For complex systems like ships, it may be reasonable to even simulate what'd happen if your good component was in a ship and someone put a shit replacement part there.

---

Extreme non-seen-in-field testing includes extrems of the human condition. Labeling buttons with icons instead of text makes things more understandable to those who don't speak English, but what if your crew spends one and half year underwater waiting for nuclear launch command, staring at those icons? One should design interfaces such that even extreme delusions, depressive tendencies, anxiety will not reduce the crew members ability to do their job. Or if someone loses a hand, they will still be able to work.

Dick move by author to reveal his level of ignorance of USN operation tempo around McCain collision until the last few paragraphs. There were lol 4 fucking surface ship collisions and a grounding in westpac in 2017 because sailors were ran ragged

I read it as "mandatory sleep requirements don't actually mean people don't show up to a shift without enough sleep".

Basically acknowledging the difference between how the world is on paper and how the world is in reality. Even if there's rules about people getting enough sleep, designing a system that assumes everyone who works it will get enough will get people killed.

The normalization of deviance around lack of sleep and experience if definitely the number 1 issue, but come on. That design to maneuver the ship was fucked up at too many levels.

Thrust transfer during which different people can operate on each propeller.

Thrust transfer that automatically disable gang.

The steering rudder that gets reset when transferred.

The steering taking the current state of the steering wheel when transferred.

The manual mode that became the default mode, allowing the transfer of controls to empty stations.

The problem with touchscreens is not the touchscreen, it's the abstraction that makes possibles things that would make no sense with real controls. Why would, at any point, the current position of controls be different depending on the station you're looking at?

You're putting a lot of weight on the distinction between drowsy and sleep deprived in a casual comment at the end. How many people really know the distinction and use the correct word in the correct situation? He's clearly looking at it from a UI design perspective and other issues like you mentioned aren't the point of the article.

Accidents have multiple causes. Somebody else might blame sleep deprivation and stimulants then a smart-ass would complain that they just waved away "confusing controls" without understanding how they worked.

permits up to 250ms latency for touch screen response. That is ridiculously high. It practically guarantees people will think it's not working and tap again

You're saying people evaluate and react to checkbox feedback faster than 4 times/sec? I'm not a UX person so this claim seems laughable. I might believe twice that as beyond reasonable, but there is no way the average person waits less than a quarter of a second before assuming their input failed and duplicate the effort. One can hardly even observe and process that quickly - even when paying attention.

In electrical engineering there is the concept of "bounce" where IO, i.e. switches sensors whatever, are in a state of close to change, they can bounce back and forth between on and off. When writing controls for them you have to debounce, that is wait for the signal to switch from off to on for say 10ms before you act on the transition.

When dealing with users, and slow processes (that you can't make faster for some reason), it is often necessary to "debounce" user input. Whether that is graying out a button, displaying a loading popup, or something else is entirely situation dependent. Whatever you choose, you should be preventing people from annoyance clicking their way into trouble.

The amount of software that doesn't seem to get that is rather surprising.

User-input speed vs system-interpretation speed is a decades-long problem with a history of incidents and warning signs.

https://en.wikipedia.org/wiki/Therac-25

I have a Hario coffee scale that is absolutely maddening. It works just fine, but gives absolutely no feedback (no flash, no beep, nothing) when you press the 'tare' button, and it also waits about a second before updating its display. The button itself doesn't have any tactile feedback either - one of those membrane-type buttons that seems to have a pressure sensor, but no 'click'.

I work in industrial automation, and the amount of polling and high-latency touchscreen issues I encounter is embarrassing.

The default latency of a Rockwell Panelview Plus screen with their FactoryTalk software (the dominant HMI system in North America for custom automation) is 1000 ms. Fixing that solves 80% of the complaints I encounter.

https://i.imgur.com/gEBAA28.png

(Unfortunately, it's a dropdown selection list with a limited set of values of 0.05, 0.1, 0.25, 0.5, 1, 2, 5, 10, 60, and a whopping 120 seconds).

Maximum Tag Update Rate: Specify the maximum rate at which data servers will send data to the tags used in the display, including tags used in expressions and embedded variables. The default update rate is 1.0 second`.[sic] If the update rate is changed, the new rate will not take effect until the display is closed and re-opened.

And it's worse than that - often, response time is on the order of 3 seconds, as described here:

https://theautomationblog.com/when-factorytalk-view-displays...

Well, if you press the button just after the update occurs, you’ll have nearly a whole second go by until it’s read. And once it’s read and sent to the PLC, you’ll then have close to another second until the screen updates again to indicate its on.

I set most of my displays to 0.25 seconds or 0.1 seconds if I can, 50ms is not achievable because Rockwell's Ethernet/IP fieldbus protocol is terribly inefficient and the update rate is a polled refresh of every tag on the screen, you can't have fast buttons and slow production history string arrays.

I don't agree, from the perspective of someone who has driven ships, stood console watches on complex combat direction systems, and regularly flies flight simulators for fun.

The UI for driving a vehicle needs to be simple and intuitive. Full Stop.

There is absolutely a place for complex displays. There were 14 people on the bridge the day the McCain had its collision. Any number of them can monitor complex screens with tons of information.

The young Sailor driving the ship needs to know where his rudder sits and what RPM his engines are turning. In fact, there are two of them, and the traditional method is that one drives and monitors the rudder, and one runs the engines. They don't need to worry about complex situations, the helm needs to know the conning officer ordered 5 degrees right rudder, they ordered 5 degrees right rudder with the wheel in front of them, and the screen or indicator in front of them indicates the rudder is right 5 degrees. Similarly, Lee Helm needs to know the conning officer ordered turns for all ahead full, they shifted the great big throttle handles to the all ahead full position, and both engines indicate all head full.

They don't need to know about engine temperatures, synchro and servo status, set and drift, winds, etc. They need to drive the damn ship in the manner they are directed to drive the ship. There were 12 other people on that bridge who could handle all of those things that matter to them. Helm and Lee Helm need to drive the ship.

This is a really interesting counter-argument.

The idea that the design should be dumbed down so, what, a lay-person who has never encountered the system can take over and drive the ship accurately? is an appealing one: it makes the case that, all else being equal, simplicity should win out.

I would argue that there's an in-between: good design is not orthogonal to intuitive design. And I would also argue that the human factor component shouldn't be missed here, both in terms of sleep deprivation, but also in terms of being able to easily and quickly identify error states or misconfigurations at a glance, without too much cognitive overload.

Cognitive overload and complex interfaces are solved with training and repetition: we do this regularly in aviation, pilotage, and all sorts of complex interfaces. But I guess it's worth asking aloud, if you can reduce some of the cognitive overload, aren't you effectively defending in depth?

Sure, every complex system could be distilled to a memorized green screen incantation, and peak performance can be reached by fusing the human brain to a well-mapped, ultra-dense information-fest. But the reality of the situation is that, when training and tiredness failed these sailors, the interface further piled on _unnecessarily_. It could have been designed to be a bit more intuitive, and that might very well have saved the lives of 10 people and $223 million dollars of taxpayer money.

"This is a hard problem that you can't get around by just saying 'just design it better'" sure downplays that amount of impact intuitive, clear design can have on, say, preventing the swiss cheese holes from aligning in this particular case.

The overall design of "controls" for something as complicated as a ship (or submarine) is of course going to be complex, and would not be expected to cater to the intuitions of a naive user.

But if you're talking about the basic ship handling controls--rudder and throttles--which were the controls involved in this case, those should be as simple and intuitive as possible, and should be designed in a way that makes it obvious what the rudder and engines are doing, obvious to the point that even a naive user would have a good shot at being able to figure it out. That's because those controls are not only the most basic ones, but the most important ones for ship safety. You don't want them to be complicated or hard to learn.

This incident was a good example of what happens when this basic principle is not followed. Of course that wasn't the only factor involved, crew training and proficiency comes into play too, but since even the Captain and the Officer of the Deck couldn't tell what the rudder and throttles were doing, there was obviously a huge problem with the way those controls were designed.

It's an important distinction to make tbh. However, "intuitive" doesn't necessarily mean "intuitive to a lay person", but it should be intuitive to someone in that domain. The "gang" checkbox is not intuitive to me, but to a sailor it probably has a lot of meaning, just like "commit no-verify and push force" is intuitive to me, but gobbledygook for a layperson.

But yes, a UI should be designed for the end-user, and power-user UI/UX design is a rare skill.

the browser zoom does not seem to change the font size because of it

This is one of the worst cases of this I have seen. It is literally unreadable for me. Normally I can use browser zoom to sort it out, but this beauty even defeats that workaround.

One solution you could use to get around this weird design decision, is to use the reader mode in Firefox (I'm not sure what is the alternative for other browsers).

All they have to do is remove "p {max-width: 28rem;}" and the website becomes beautiful. The text fills the entire width of the screen, and the font scales with the screen size (though they should dial it back a bit, or have a different scaling ramp). It's like reading an actual document, and how the web should be. Bonus points, it's ridiculously "responsive" for small screen sizes.

Yes, I know they got it kinda "wrong", but they're arguably going in the right direction here. I'd give the author points for trying something out of the box, and also for "sticking it" to the monstrosity that Bootstrap started many years ago.

Ironic

Someone while designing for the mobile, forgot about desktops.

  ```
  :root {
    font-size: calc(1vw + 1vh + .5vmin);
  }

  html {
    max-width: 100%;
  }

  body {
    color: #444;
    font-family: "Vollkorn", georgia, serif;
    margin: 0 auto;
    max-width: 100%;
  }
  ```

  ```
  width: 100%;
  max-width: 1200px;
  ```

Not to forget, the same problem has happened before with aircraft pilots.

Someone doesn't notice that the the wrong engines are running, or someone forgot to power down one of the engines.

Or there was an engine failure. And in the confusion, someone powers down the wrong engines.

Usually in these cases, fatigue or information overload is a major factor.

The pilots were fully qualified. They were simply overworked, and too tired to realize their mistake.

I wouldn't assign all the blame to lack of training. The navy is very famously overworked and understaffed, and not just in the USA.

You are both right and wrong. A competent crew wouldn't have failed.

But given the operating conditions (lack of sleep) and recruiting (lack of personnel) a competent crew couldn't be assembled on the McCain.

The crew did their best under the conditions, and failed.

Did you read the part where control over each propeller is passed separately to different station?

This does look like a very error-prone design to me

This is nonsense. It's the same argument that people use against memory safe languages "it's possible to write memory safe code in C, you just have to not be incompetent". The truth is, all people are various levels of incompetence, and varies according to many different parameters that are all perfectly expected (like sleep deprivation).

You design a system to be as robust as possible to all operating conditions, which includes human fallibility.

Let that sink in (no pun intended) - the crew is not aware the propellors can spin at different speeds

This isn't a very good take. Every mariner is aware of using differential throttle to manoeuvre. It is a primary means of control below the speed where the rudder is effective.

You've completely missed the human factors element. When what you are seeing doesn't match your expectation then it can quickly lead to issues. It's practically the exact same as AF447. The urgency of being about to crash into something can make it very hard to step back and understand what is actually happening.

An engine order telegraph wouldn't have this problem. So IMO it is very much a design problem, a problem that was already solved but needed to be created again so we can learn those lessons again.

The design looks pretty terrible. If the same UI can do very different things based on checkboxes and controls can be spread out over multiple stations non-obviously, that's about recipe for causing the problems above.

It sounds like they had a button for reverting all controls to a single station, if that wasn't used to recover obvious control that's on the sailors, imo. The fact that such a button is necessary to recover from a run of the mill situation is however a serious design failure.

I think this is the actual wtf, along with the transfer ui:

The transfer of thrust comes with an additional level of complexity because the propellors must be transferred one at a time. Half way through a transfer the boat is in a situation where one propellor is controlled by one station and the other is controlled by someone else. At this moment the checkbox labeled “Gang” is automatically unchecked.

Absolutely no surprise that in a moment of panic, the thrust controls end up spread across multiple stations. Why is this even a feature? Not a sailor so just armchair commenting, but in what situation would that be beneficial?

This design dates to the 90s at least. I went to school on this system in 1997 and it wasn't new then, it was new to our class of ships but had been in service for a number of years prior.

If it went through an HMI review it wasn't by anyone qualified to do it.

That just suggests the review process isn’t fit for purpose either

I was going to say the same. Have seen similar comments below… Real irony!

Why the hell would you do that? Makes no sense at all.

FYI Reader mode solves most of these problems (not that it should be needed)

For anyone reading this, if you want to remove this "clever" CSS font-size, here's the option you need to disable in Inspect Element screen:

    :root {
        font-size: calc(1vw + 1vh + .5vmin);
    }

I'm not a mariner but from what I've seen on boats and motoryachts the controls are typically transferred with the engines in neutral. This step ensures that the person who takes control positively knows the state of the engines and avoids having to do some kind of synchronisation with the current state. Perhaps this is problem on a destroyer or they imagined the controls being routinely moved around the bridge. On most vessels it's in the same place for the whole passage and for docking or departure you chose which station to use.

Idling the engines for a minute while you have isn't an imposition as anyone prudent would be doing propulsion and steering tests before entering a confined area at that point anyway.

I can only think the imagined the controls being passed about on a regular basis and because they didn't need to synchronise the physical position with the current state they skipped that step.

Why transferring one engine at a time made sense I have no idea.

Having rudder and propeller on different stations can be useful to organize work on the bridge, especially on a warship. The possibility of having the two propellers on different stations is imho insane. The only reason that I can think of is a runaway "safety" requirement ~"if one prop control fails you still must be able to take control of the other prop on a different station". That would fit what the article says about them essentially running in manual backup mode all the time and not in the intended mode of operation.

Battle Damage or Engineering Casualty (Engine Troubles). Arleigh Burke speed is controlled by two factors, the RPM of propellers AND the pitch of propeller blades. https://en.wikipedia.org/wiki/Variable-pitch_propeller_(mari... Obviously this controls steering as well if system isn't functioning properly.

In normal situations, computer mostly handles this and single station (Helm) has control over all 3. If computer fails, the pitch control fails or propeller engine fails, this will need to be controlled manually by the crew and workload is too much for single person. Also, in certain situations, like underway replenishment, all 3 control stations may be manned because if there is sudden failure, you need to be quickly able to respond.

Also, the problem is touch screen period. This is case where putting iPad instead of levers/switches/buttons is NOT an upgrade. See your car climate control as good example everyone can relate to.

The traditional method of control splits helm(rudder control) and lee helm(throttle control). Both are under the direct command of the conning officer, who is responsible for all orders to the helm and lee helm and setting and maintaining the course ordered by the officer of the deck.

You need to be able to shift control of steering to aft steering in case of battle damage or steering failure on the bridge, and you need to be able to shift throttle control to the engine room for the same reason.

The concept of splitting throttle control of engine 1 and engine 2 between stations as a part of the normal transfer of control is absurd and I have no idea why that was even a thing. I never heard of it when I worked on this system.

I like this other article on the topic, here's what it says about splitting rudder from speed:

Sanchez quickly noticed that his new helmsman seemed flustered by the difficulty of having to control the ship’s steering and speed at the same time. He decided to split the helm, giving Bordeaux control over the ship’s wheel. While Bordeaux remained at his station, Dontrius Mitchell, a second sailor on the bridge, was assigned to take control of the speed of the McCain at a neighboring station known as the lee helm.

Sanchez’s order was unexpected — he had not discussed the possibility in meetings with the crew before entering the straits. Nor had the crew practiced the maneuver much. Bordeaux could only remember doing it once or twice before.

https://features.propublica.org/navy-uss-mccain-crash/navy-i...

If making the primary propulsion some ad-hoc touchscreen control instead of a physical lever is only something you can get to with hindsight then you shouldn't even be anywhere near to a position where you can make that mistake.

Training is good, but it's not like design (I mean in how it should be used, not looks) is something which should be ignored. If you have a bad design, you need an awful lot of training to compensate for that.

The incident report almost didn't mention design at all, so what are the chances of the problems ever getting addressed?

Are the people who designed this UI idiots?

If no, then that contradicts your argument. Non-designers obviously do get it wrong.

If yes, your argument has become a "no true scotsman" -- it no longer makes a statement about the capability of anyone, but simply defines "idiot" as people who get the UI wrong.

Besides that, hindsight is 20/20. Was the UI obviously terrible before the accident happened?

One nice thing about designers is their tie-breaking ability for non-designers. Design, being something we all think we’re right about, is easy to lose lots of time going back and forth on with non-specialists, while it’s much faster to send to a pro.

But I generally agree with you, I think the world would be better if everyone was more thoughtful about this sort of thing.

Looking at the UI, I see consistently applied patterns in a pretty normalised layout. I don't know how to use any of the controls, but that's because I don't know how to steer a warship, not because the UI is bad. Had I known what "gang" means in this context, the problem would've been clear from the very first screenshot. Yes, the UI is ugly as sin, but it doesn't need to be pretty.

A barely trained 18 year old on months of sleep deprivation couldn't figure this out, but that's an impossible standard to design for. The entire ship was designed to use computer aided navigation anyway, but apparently that's being disabled by default.

As Wikipedia states, nuclear vessels still have EOTs, though they’ve evolved.

On Virginia-class subs, the EOT has been made into a linear button array. It’s arranged in logical order (All Ahead Flank at top, descending to All Stop, then down to All Back Emergency; there are small gaps in between Ahead, Stop, and Back groups), and the button flashes when an order is received. There’s also an audible alert, of course.

The throttles themselves are small hand wheels, with the astern wheel being smaller and offset from the ahead wheel. These send redundant signals to the main engine controllers (which also redundant), which ultimately control the main engines. In the event of an emergency, there is a manual override station between the main engines – this is outside of maneuvering, and would require a different watchstander to man, since the propulsion plant operator is also running the reactor.

To your main point though, yes, a checkbox is inadequate. Physical controls are generally superior, which is why car manufacturers who moved away from them are starting to move back.

Similar controls are used on modern ships. They usually though have an option to control both engines with one throttle to avoid having to manually synchronise the speed of both. Not sure if they have a reversion to separate control if someone grabs the currently redundant lever.

It looks like this is a known issue with his handcrafted CMS: https://github.com/adrian3/whisper/issues/5

I literally gave up on trying to read the article because of this.

The eyestrain from the font size nearly immediately gave me a headache.

Finding something or someone to blame -- whether it is an operator, the UI, training, whatever -- typically halts all insight-gaining processes, and is therefore not recommended. Especially if that something is "100% to blame".

100% not at fault When something significant goes wrong, it’s almost never due to a single cause; multiple factors and confounding elements are usually at play. We build better-performing systems when we examine various contributing factors and proximal causes.

The OP's argument is that the interface does not "clearly" indicate that one engine input is higher than the other. After reading the article and reviewing the interfaces, I have to say: the OP’s argument is quite compelling. While training is undoubtedly important and should be included in the safety recommendations, the OP makes a strong case that design improvements should also be considered as part of the safety recommendations.

The box is only unchecked because of the curious decision to allow transferring of a single prop / engine which I'm not convinced has any real value.

One thing that isn't stated is what the state of the redundant thrust slider is when the inputs are ganged together. In the physical implementations I've seen the redundant lever is usually moved to neutral and it's not inconceivable that this was carried into the digital UI. In that case failing to spot the fact that there was a differential thrust involved because of the lack of a checkbox might be much more understandable.

Virginia-class has lots of screens, but they aren’t touchscreens. The control panels have physical buttons and switches which are clearly labeled, logically laid out, and are extremely tactile. There is no confirmation for anything, because it’s assumed that you received verbal confirmation of your intended action before performing it.

Conversely, they also have computers for some maintenance items, and those (intelligently) have confirmation screens everywhere, because it’s just bog-standard Windows UI. The software UI team really should talk to the control panel UI team.

Hopefully there isn't dark patterns with the confirm button on that one :D

Write instructions for use of your countries nukes on handwritten letters in sealed envelopes and put one copy in each submarine!

I know there is a HN guideline about not commenting on stuff like this, but in this case the text was so large it prevented me from wanting to read the article at all. Just uncomfortably large.

I was on that ship but left before the accident, I'm pretty positive it was sleep deprivation. The schedule changed at sea frequently so you couldn't get used to what little sleep pattern you were getting. We also had surprise drills that can happen literally any time of day or night. Longest I stayed awake was 72 hours straight.

If they were independent levers capable of being physically locked together, you'd probably notice when they aren't moving together. Of course, you could easily have similar visual feedback on a touch screen. Seems like the real issue is described later in the article; throttle control can be split between control stations, which is actually insane, I can't imagine a scenario where you'd want that.

NTSB has zero jurisdiction here. This happened in International Waters between US Military and Liberian Flagged ship.

I don't understand the difference. With a touch-screen, if the propellers aren't synchronized, you would see it immediately on the green bars: if you slide one and the other doesn't slide similarly, they aren't synchronized.