>We create rules enforcing mandatory sleep requirements stupidly believing that we can eliminate the potential for a user of the system to be drowsy while at the controls.
>stupidly believing
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, leading to operation pause. UX wasn't the primary problem. Sailors weren't "drowsy", they were sleep deprived, hopped up on stimulants etc due to manning shortages and long deployments, and likely lax training (due to shortages), which caused USS Connecticut accident a few years later. I'm sure you can improve UI for audience subsisting on 3-5 hours of sleep, but maybe the more pressing thing to try is to get them more sleep. IIRC there was study on navy sleep hyigene and like 100% of sailors in bottom quartile experienced bewilderment/confusion.
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.
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.
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.
> 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.
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.
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.
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.
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?
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...
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.
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?
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.
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.
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.
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.
The F1166 standard 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, undoing any toggle function they might have activated. They won't necessarily notice their mistake.
I once accidentally ran a washing machine at 90C temperature because of high-latency touch controls. I instinctively double-pressed the touch surface to reduce temperature because I thought the first touch hadn't registered, causing it to wrap around back to maximum. It did some minor damage to the clothes before I noticed. And that was with more like 200ms latency, not 250ms.
Latency on touchscreens is more important than with physical controls because there's no tactile feedback. Even 10ms is obviously imperfect for drag controls. Microsoft Research published a demonstration video:
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.
> When a physical control is replaced by a digital interface, it is the job of a designer to translate the functions of the controls into pixels. If designed well the UI is intuitive. When designed poorly, the interface is difficult to understand and causes users to make mistakes.
Ugh. I don't want to quote all 25 of the things I disagree with about this article, so here's the first one that came up.
A well-designed UI is not necessarily intuitive. Think about vi, or the command line, or Blender, or Figma, or pretty much any UI designed for experts who spend every day using the system. These UIs trade intuitiveness and simplicity for power and speed. They do so knowingly.
It's not actually desirable to make a UI intuitive—which is to say, to make it behave the way a naive user would expect the first time they use it. Not if you can instead make it more powerful, and train the users how to use it instead.
An intuitive submarine control might have buttons to go up and down, left and right, and turn, and then a big red button that says "launch torpedo", like in video games. But I bet that's a bad UI for a real submarine. Instead you want it to have a lot of information on the screen, and hundreds of different functions it can perform if only you've gone through an intense training program to learn how to operate it, which is what the Navy does.
I don't think that being difficult to understand and prone to making mistakes is the opposite of intuitive, either. I think those are orthogonal.
None of this is to excuse the design of that system, which I've never used, and can't defend or attack. It's just I know that this is a hard problem that you can't get around by saying "just design it better".
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.
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 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 checkbox isn’t the “smoking gun” but rather part of a broader range of system issues in design and usability that likely contributed the USS John McCain accident.
Having developed these types of systems though, the UX goes through heavy HMI reviews by real users and engineers. Likely whomever built this ship had those reviews.
I would like to understand if this checkbox and its related design ever came up in those reviews and whether engineers were directed by their Navy customer to change it.
It’s possible it was just a small footnote on a PowerPoint slide and they moved on.
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.
The traditional engine order telegraph https://en.wikipedia.org/wiki/Engine_order_telegraph is a beautiful piece of mechanical design. A more modern version would be aircraft-style throttle handles, which are also placed close together so that you naturally move two or four of them together with one hand movement. Reducing that to a checkbox just seems .. inadequate.
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.
"Conspicuously absent from their recommendations was any discussion about user interface design. Of their seven safety recommendations, six involve training."
Yes. That's because if your ship is going left and you can't figure out why when there's an interface clearly showing why (ie one engine input is higher then the other), it is a training and/or procedure issue.
The author then goes on to state that during steering control transfer, the checkbox is automatically unchecked. So the engine input UI is 100% not at fault here.
I have no experience in ship-handling, but my naive question for this who do is: What is the rationale for being able to independently transfer control of different aspects of ‘steering’ (prop1, prop2, rudder) to different stations? . The coordination required between two or more stations inherently makes the task (control of heading and thrust) more difficult than if a single station was coordinating the process inside one brain. Is there some benefit I am not seeing that justifies the increased complexity?
I tried for a long time to use this keyboard effectively. https://en.wikipedia.org/wiki/FingerWorks but I never really could. I like the touchscreen idea, your user interface is the user interface you were trained on, Star Trek style.
I think light and sound engineers probably have the best setup. everything's hooked up to a big board with sliders. you can physically move the sliders, and the position of the slider represents what's actually happening. But you can also set up a scene on an attached computer. Click the button, or tap the touch screen, all the sliders move to the predesignated state.
I don't know a damn thing about battleships, or destroyers. But a big ass console, with physical knobs and sliders that represent the current state seems like a really good idea. Sure, you can adjust whatever from whatever glass station you want. But everyone can tell at a glance, the state of the world. You can walk over and turn the knob, overriding everything else. And everybody can see you do it, and hopefully understand what that action means.
The closest I get to that sort of stuff is my car. The hazard lights are one big dedicated button. There may be a way to turn them on with the touchscreen, I don't know. Volume has a physical dial on the console. There are buttons on the steering wheel, but I find myself reaching for the dial when I really need to turn the volume down.
Physical controls are expensive. I imagine there's stuff that's common and essential, that, it's probably a good idea to spend the money and have the control. I have strong feelings about this. There are little fiddly settings that you can tuck away under five layers of menus. But there's other stuff That you touch all the time, or you need in an emergency, that IMHO, you should be allowed to build up muscle memory to accomplish.
To summarize, the checkbox in question was designed such that it's lit up when checked and not when it isn't. I'm surprised they did this because it's terrible design. You see this all over the place. It confuses the user who thinks there should be a check there and can't tell if it's checked or not checked merely by glancing at it.
I was happy to see this:
> The Navy recently announced they are abandoning touchscreens in their fleet in favor of physical controls.
The author defends touch controls and the decision being based on really old standards and one survey (apparently). I'm going to respectfully disagree. I'm no ship captain but I believe the propeller controls on a ship are traditionally like the levers on the right of this image [1]. This is from a multi-propeller cruise ship, I believe.
Now if you had those controls, anyone could tell at a glance that the propellers weren't synchronized.
Touchscreens allow for UI updates more easily. This leads to designers being lazy. "We can fix it in an update". It necessitates training on checkboxes.
It is not only the ship's UI that lacks review in the post-mortem analysis, but also the process that lead to it.
"Conspicuously absent from their recommendations was any discussion about user interface design."
_Why_ did the NTSB not review the user interface? What is their motivation, and the forces that influence their actions? Is the NTSB sufficiently staffed with experts on user interfaces? If not, why not?
> These specifications come from a document written in 1988.
Is the process to update Standard F1166 sufficient? (Probably not.) Why? Why is a document that is clearly outdated used to guide UI design in a newly designed ship? What are the incentives and forces that lead to this outdated standard being used, and no update fixing it?
This looks like an article written by a designer obsessed by how important design is, and how anyone could pilot a warship without training if designers made something perfect.
It's a good reminder for software people sometimes overemphasizing the importance of software in a given situation, and how the processes encompassing it interact with it and control its outcomes.
This seems to me like. a case of "hindsight is 20/20". There were thousands of design decisions made in the ship's controls, and likely multiple of them can in certain, yet untested scenarios, cause a disaster. Has he identified those as well? And isn't more training and experience also an effective way to handle more of these possible scenarios?
The problem was that these guys didn't have any sleep. Lots of people think like they're against Sicilians When Death Is On The Line and that if they just slow poison their folks they'll become immune to poison. Well, just like giving your children small amounts of mercury every day doesn't turn them into a mercury-immune kid, not letting people sleep doesn't lead to sleep immune people. It just transforms people into idiots. So they transformed all their people into idiots. And then the idiots crashed the boat.
If you did the same to me, I assure you I would be even stupider and my performance even more lacking.
One thing that bums me out about this is the idea that figuring this kind of thing out is what "designers" do. As if there is some special skillset and art to design that a special group of people, designers, do, which we should take seriously.
No, this is just what non-idiots do. Any non-idiot would look at this UI and think: this is terrible.
While I agree with most of the assessment, I think that checkbox is fine. Removing the set of motorized haptic control levers and the motorized steering wheel at the brigde is a problem. Had the designers needed to integrate the feedback forces, they could have visualized them on the gui only stations too.
It's not that touchscreens didn't exist when F1166 was written. At that time it was widely understood a touch in a touchscreen would be a click and a drag would be a mouse-down + move + mouse-up sequence. The sliders seem to be designed to be both draggable and the two buttons for precise incremental adjustments.
What I find disturbing is that there doesn't seem to be a single The-Most-Important-Thing screen visible to everyone. I'd expect things like heading, steering, and engine power would be immediately available and readily visible, most important when a possible collision is identified.
And I hope people realise emergency manual control is for resolving emergencies rather than creating them.
The article says "If you don’t have the vocabulary to describe a problem it is unlikely that you will be able to fix it."
I fundamentally disagree with this. You don't need to know design jargon to identify bad design or to make good design. What you need is to understand what the user is likely to know and what you need to tell them. This is different than just providing controls, which is what most design by engineers looks like.
For example, I would characterize the overall design problems with the UX as:
1. Users need to understand at a glance how each control input is currently influencing the course of the ship. Separately the users need to understand at a glance what the resultant course and position of the ship will be given the current control inputs and external factors like wind and current.
2. Users need to understand at a glance which station is controlling the ship, with intuitive controls to offer to pass control to, or accepting control from, a different station.
So I can describe the problem without using any UI jargon. Similarly I can refer to these to indicate why the current UI is broken, again without UI jargon, simply by saying "it doesn't solve problem 2 because the state is unclear" or whatever.
Supposedly the control system has been fixed by adding physical levers, with retrofits to existing ships.[1] Unclear if they're all coupled together, so that moving a lever at one location moves all the other levers. That's a standard feature available for commercial ships.
For two stations, it can be done with mechanical cables. Beyond that, there are electrical systems.
This is a known cause of accidents with ship controls with multiple control stations. There was a New York City Seastreak ferry crash in 2013 due to that.
It seems that the operator is expected to sometimes make very small adjustments to the throttle level, going by what looks like clickable arrows. I wonder why they didn't locate the UI elements corresponding to throttle indicators butting right up against each other, with a Vernier scale on them, to make misalignments quantifiable and more obvious.
Not that it would have helped in this case, but maybe the scale can be magnified and change colour when there is misalignment, which would have been possibly slightly more obvious? I don't know.
[+] [-] maxglute|1 year ago|reply
>stupidly believing
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, leading to operation pause. UX wasn't the primary problem. Sailors weren't "drowsy", they were sleep deprived, hopped up on stimulants etc due to manning shortages and long deployments, and likely lax training (due to shortages), which caused USS Connecticut accident a few years later. I'm sure you can improve UI for audience subsisting on 3-5 hours of sleep, but maybe the more pressing thing to try is to get them more sleep. IIRC there was study on navy sleep hyigene and like 100% of sailors in bottom quartile experienced bewilderment/confusion.
https://news.usni.org/2017/09/18/admiral-captain-removed-par...
[+] [-] gwbennett|1 year ago|reply
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.
[+] [-] maxglute|1 year ago|reply
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.
[+] [-] kstrauser|1 year ago|reply
[+] [-] Kamq|1 year ago|reply
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.
[+] [-] actionfromafar|1 year ago|reply
In a sudden life-and-death situation combined with information overload, a bad interface can be what tips the scale into disaster.
[+] [-] moconnor|1 year ago|reply
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.
[+] [-] qo34j52o84j5|1 year ago|reply
[+] [-] pjc50|1 year ago|reply
[+] [-] oatmeal1|1 year ago|reply
[+] [-] cameldrv|1 year ago|reply
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.
[+] [-] bpodgursky|1 year ago|reply
[+] [-] ForOldHack|1 year ago|reply
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...
[+] [-] anbotero|1 year ago|reply
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/
[+] [-] HenriTEL|1 year ago|reply
> 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?
[+] [-] Xen9|1 year ago|reply
---
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.
[+] [-] EnigmaFlare|1 year ago|reply
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.
[+] [-] cwmma|1 year ago|reply
[+] [-] aaron695|1 year ago|reply
[deleted]
[+] [-] Drunkfoowl|1 year ago|reply
[deleted]
[+] [-] pc86|1 year ago|reply
> > 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.
[+] [-] mrob|1 year ago|reply
I once accidentally ran a washing machine at 90C temperature because of high-latency touch controls. I instinctively double-pressed the touch surface to reduce temperature because I thought the first touch hadn't registered, causing it to wrap around back to maximum. It did some minor damage to the clothes before I noticed. And that was with more like 200ms latency, not 250ms.
Latency on touchscreens is more important than with physical controls because there's no tactile feedback. Even 10ms is obviously imperfect for drag controls. Microsoft Research published a demonstration video:
https://youtube.com/watch?v=vOvQCPLkPt4
[+] [-] stonemetal12|1 year ago|reply
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.
[+] [-] karaterobot|1 year ago|reply
Ugh. I don't want to quote all 25 of the things I disagree with about this article, so here's the first one that came up.
A well-designed UI is not necessarily intuitive. Think about vi, or the command line, or Blender, or Figma, or pretty much any UI designed for experts who spend every day using the system. These UIs trade intuitiveness and simplicity for power and speed. They do so knowingly.
It's not actually desirable to make a UI intuitive—which is to say, to make it behave the way a naive user would expect the first time they use it. Not if you can instead make it more powerful, and train the users how to use it instead.
An intuitive submarine control might have buttons to go up and down, left and right, and turn, and then a big red button that says "launch torpedo", like in video games. But I bet that's a bad UI for a real submarine. Instead you want it to have a lot of information on the screen, and hundreds of different functions it can perform if only you've gone through an intense training program to learn how to operate it, which is what the Navy does.
I don't think that being difficult to understand and prone to making mistakes is the opposite of intuitive, either. I think those are orthogonal.
None of this is to excuse the design of that system, which I've never used, and can't defend or attack. It's just I know that this is a hard problem that you can't get around by saying "just design it better".
[+] [-] jki275|1 year ago|reply
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.
[+] [-] pdonis|1 year ago|reply
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.
[+] [-] Cthulhu_|1 year ago|reply
But yes, a UI should be designed for the end-user, and power-user UI/UX design is a rare skill.
[+] [-] disillusioned|1 year ago|reply
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.
[+] [-] firesteelrain|1 year ago|reply
Having developed these types of systems though, the UX goes through heavy HMI reviews by real users and engineers. Likely whomever built this ship had those reviews.
I would like to understand if this checkbox and its related design ever came up in those reviews and whether engineers were directed by their Navy customer to change it.
It’s possible it was just a small footnote on a PowerPoint slide and they moved on.
[+] [-] iforgotpassword|1 year ago|reply
> 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?
[+] [-] jki275|1 year ago|reply
If it went through an HMI review it wasn't by anyone qualified to do it.
[+] [-] Havoc|1 year ago|reply
[+] [-] pjc50|1 year ago|reply
[+] [-] sgarland|1 year ago|reply
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.
[+] [-] VBprogrammer|1 year ago|reply
[+] [-] Jean-Papoulos|1 year ago|reply
Yes. That's because if your ship is going left and you can't figure out why when there's an interface clearly showing why (ie one engine input is higher then the other), it is a training and/or procedure issue.
The author then goes on to state that during steering control transfer, the checkbox is automatically unchecked. So the engine input UI is 100% not at fault here.
[+] [-] ghufran_syed|1 year ago|reply
[+] [-] jfoutz|1 year ago|reply
I think light and sound engineers probably have the best setup. everything's hooked up to a big board with sliders. you can physically move the sliders, and the position of the slider represents what's actually happening. But you can also set up a scene on an attached computer. Click the button, or tap the touch screen, all the sliders move to the predesignated state.
I don't know a damn thing about battleships, or destroyers. But a big ass console, with physical knobs and sliders that represent the current state seems like a really good idea. Sure, you can adjust whatever from whatever glass station you want. But everyone can tell at a glance, the state of the world. You can walk over and turn the knob, overriding everything else. And everybody can see you do it, and hopefully understand what that action means.
The closest I get to that sort of stuff is my car. The hazard lights are one big dedicated button. There may be a way to turn them on with the touchscreen, I don't know. Volume has a physical dial on the console. There are buttons on the steering wheel, but I find myself reaching for the dial when I really need to turn the volume down.
Physical controls are expensive. I imagine there's stuff that's common and essential, that, it's probably a good idea to spend the money and have the control. I have strong feelings about this. There are little fiddly settings that you can tuck away under five layers of menus. But there's other stuff That you touch all the time, or you need in an emergency, that IMHO, you should be allowed to build up muscle memory to accomplish.
[+] [-] jmyeet|1 year ago|reply
To summarize, the checkbox in question was designed such that it's lit up when checked and not when it isn't. I'm surprised they did this because it's terrible design. You see this all over the place. It confuses the user who thinks there should be a check there and can't tell if it's checked or not checked merely by glancing at it.
I was happy to see this:
> The Navy recently announced they are abandoning touchscreens in their fleet in favor of physical controls.
The author defends touch controls and the decision being based on really old standards and one survey (apparently). I'm going to respectfully disagree. I'm no ship captain but I believe the propeller controls on a ship are traditionally like the levers on the right of this image [1]. This is from a multi-propeller cruise ship, I believe.
Now if you had those controls, anyone could tell at a glance that the propellers weren't synchronized.
Touchscreens allow for UI updates more easily. This leads to designers being lazy. "We can fix it in an update". It necessitates training on checkboxes.
Stop. Just... stop.
[1]: https://www.marineinsight.com/wp-content/uploads/2020/05/eng...
[+] [-] moring|1 year ago|reply
"Conspicuously absent from their recommendations was any discussion about user interface design."
_Why_ did the NTSB not review the user interface? What is their motivation, and the forces that influence their actions? Is the NTSB sufficiently staffed with experts on user interfaces? If not, why not?
> These specifications come from a document written in 1988.
Is the process to update Standard F1166 sufficient? (Probably not.) Why? Why is a document that is clearly outdated used to guide UI design in a newly designed ship? What are the incentives and forces that lead to this outdated standard being used, and no update fixing it?
Related: CAST handbook, http://sunnyday.mit.edu/CAST-Handbook.pdf
[+] [-] pyrale|1 year ago|reply
It's a good reminder for software people sometimes overemphasizing the importance of software in a given situation, and how the processes encompassing it interact with it and control its outcomes.
[+] [-] figassis|1 year ago|reply
[+] [-] renewiltord|1 year ago|reply
If you did the same to me, I assure you I would be even stupider and my performance even more lacking.
[+] [-] ajkjk|1 year ago|reply
No, this is just what non-idiots do. Any non-idiot would look at this UI and think: this is terrible.
[+] [-] zweifuss|1 year ago|reply
[+] [-] rbanffy|1 year ago|reply
What I find disturbing is that there doesn't seem to be a single The-Most-Important-Thing screen visible to everyone. I'd expect things like heading, steering, and engine power would be immediately available and readily visible, most important when a possible collision is identified.
And I hope people realise emergency manual control is for resolving emergencies rather than creating them.
[+] [-] AmazingTurtle|1 year ago|reply
i can not zoom in or out, makes me go crazy
[+] [-] efitz|1 year ago|reply
I fundamentally disagree with this. You don't need to know design jargon to identify bad design or to make good design. What you need is to understand what the user is likely to know and what you need to tell them. This is different than just providing controls, which is what most design by engineers looks like.
For example, I would characterize the overall design problems with the UX as:
1. Users need to understand at a glance how each control input is currently influencing the course of the ship. Separately the users need to understand at a glance what the resultant course and position of the ship will be given the current control inputs and external factors like wind and current.
2. Users need to understand at a glance which station is controlling the ship, with intuitive controls to offer to pass control to, or accepting control from, a different station.
So I can describe the problem without using any UI jargon. Similarly I can refer to these to indicate why the current UI is broken, again without UI jargon, simply by saying "it doesn't solve problem 2 because the state is unclear" or whatever.
[+] [-] Animats|1 year ago|reply
This is a known cause of accidents with ship controls with multiple control stations. There was a New York City Seastreak ferry crash in 2013 due to that.
[1] https://www.theverge.com/2019/8/11/20800111/us-navy-uss-john...
[2] https://www.ntsb.gov/investigations/pages/DCA13MM005.aspx
[+] [-] kqr|1 year ago|reply
Not that it would have helped in this case, but maybe the scale can be magnified and change colour when there is misalignment, which would have been possibly slightly more obvious? I don't know.