The U.S. Navy's $100M checkbox (2019)
adrian3.com
adrian3.com
>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...
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 think truckers have significant UXUI AND regulation on how long they can drive.
The Author does a good job oh highlighting the issues around UXUI that have not been analysed enough anywhere else and also raises the other issues which have been reported on.
> "first and only public source of real design criticism"
> "Add inexperience, insufficient training, and lack of sleep to the situation and you have a recipe for disaster"
"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."
But then I read few comments on navy systemic sleep depravation...
And how air force solved this 60-70 years ago.
And how some peoples says UX problem is not a problem becouse sleep is a problem (and there are contemposomething evidences of other problems) and obviously two or more of them can't compound simultaneously ! /s
Just want to add: if there is so basic problem with working conditions then there obviously are much more human (and not only) problems in that navy force. Seems quite identical to what Russia is demonstrating in last years and in case of conflict results will be identical - a lot of lost american lives for stupid reasons. Just pointing obviousness.
7th Fleet's issues are well known, but not necessarily outside the community of those of us who lived them.
In a sudden life-and-death situation combined with information overload, a bad interface can be what tips the scale into disaster.
Now there's no such concept as a ganged/unganged state. You move the middle (which has the larger area, since it's the most common tool) to move them together, and the side sliders if you want to control thrust individually.
The only real solutions would be for Congress to either significantly increase personnel funding, or trim back the mission set to make it sustainable at current personnel levels. There is no political support for either solution and so the problem will persist.
That sounds like a management issue. Congress doesn't manage how ships run. The Navy makes all those choices itself.
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 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 problem here isn't "instead of in a classroom", it's "self study in their spare time" instead of "learning by doing the job under the supervision of more experienced people". The way I learned to drive ships was by driving ships under the supervision of more experienced ship drivers. Sure, there was some classroom preparation before that, but the biggest value add was the supervised hands-on time.
> > 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.
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.
Design matters.
I'm surprised that in the description of the incident there is no mention of a checklist like pilots use?
---
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.
And this is why aviators mock nukes. Because we actually understand what gets people killed and avoid it.
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.
So what if there were Chinese naval operations in a place where American operations occurred?
When I worked for a DoD contractor I worked on a system that was designed to tighten one such feedback loop. The publicly-available copy regarding this unclassified effort [1] says that it was
> [a] framework for an end-to-end Change Request (CR) workflow system that will improve turn-around time and speed to the fleet. We are leading the innovation of a paperless cockpit through the design and development of an eFC mobile application that will provide responsive, reliable information for our aircrews on mobile devices at the touch of a button.
I thought that it was a pretty novel idea - it was certainly the most technically-progressive project I worked on when in defense contracting by a country mile. When I attended a program picnic at the Captain's house, however, I found no shortage of people who were skeptical of what we were building. When I pressed them for reasons why it basically amounted to "I learned what we have years ago and I don't want to change". Institutional rot is very real.
[1] https://web.archive.org/web/20240821032432/https://webdev.am...
Indeed. The checkbox, the lack of sleep, the insufficient training and the cryptic instructions are all symptoms.
Lack of sleep is one thing I would think about deliberately employing to get a notion of what is the safe margins of individual crew members. For instance, I work very well under stress, but fail early on sleep deprivation.
We adopted it in the mid-20th century post-WWII because we were literally killing people for dumb reasons. I don't know if it's the well-known aviator hate among a significant minority of blackshoes that's the roadblock, or what.
See also: medicine.
1-1 is clearly absurd. So is 2-2. And 3-3. I'm convinced 6-6 is also biologically unsustainable for most people, although 6 hours is long enough that 1) some people are perfectly fine with it, and 2) most other people can hack it for at least a while before incipient mental breakdown.
Some people function best with several shorter sleep periods. Other people function best with 1 longer one. The former can work just fine with a 12-12 schedule. The latter cannot maintain performance with a 6-6 schedule.
The aviation communities had this suitcased 40+ years ago with mandatory crew rest requirements that can only be broken in legitimate combat.
In the case of the Navy, I can guarantee that 6+6 shifts didn't come about because of advanced sleep research, but because "it was good enough for me and now it's good enough for them".
It's not that the US navy should operate by forcing sailors to forgo sleep, but their systems should be able to be operated by someone who has had very little sleep during actual combat. Touch screens seems counter to that. Two physical throttles, which can be moved either individually or together would be a much clearer indication of the current mode. Humans can feel extremely small misalignments, but trying to line up two lines on a monitor and we need to hold up a piece a paper to check if they are 100% aligned.
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.
> 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?
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...
"In 1983, just such a moment was jarringly interrupted when the USS Enterprise ran aground a mere 1,000 yards out from the shoreline. In a photograph released by the Naval Institute, the massive carrier tilts slightly to its side, with its crew positioned on the deck."
https://nationalinterest.org/blog/buzz/uss-enterprise-navy-n...
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.
--------
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:
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.
There's been plenty of research for decades showing that 250ms response time in UX is a noticeable slowdown.
Except that there was a bug where if you go too quickly, some of the software safety interlocks didn't work right, and they had removed the hardware safeties in the update from Therac-20.
Most premium Android phones in 2016 were 120-30ms motion-photon response time (low to midrange probably hit 250), while iPhones were ~80ms. Haptics add another ~30ms delay. There have been massive improvements since 2016, as it has been a competitive metric, but even with >120Hz screens sub 60ms max true latency is uncommon.
As (actually my long term memory of) the MS video shows faster refresh and lower latency greatly improve smoothness and are useful for moving objects, especially scrolling (though tearing is a real issue). The problem is much more pronounced in VR/MR as eye tracking of diagonal motion is VERY discriminating. That's why they shoot for >240Hz refresh rates. Over 1kHz there doesn't seem to be a lot of improvement (2ms latency) due to a combination of cone/rod/neural filtering.
If you want a very generic worst case latency calculation based on the touch acquisition rate and display refresh rate assuming no position calculation delay it is:
Latency = 2/Ftouch + 2/Fdispl = 2/16Hz + 2/16Hz = 250ms
Please provide a link to your data and analysis.
Seriously, I hope you don't work for a major touchscreen supplier. A good UI can deal with relatively high latency input, a bad UI can make any latency unusable. Finger motion before/after contact and rapid high force contact bounces are common problems. Many high performance interfaces "gracefully" degrade report latency to similar levels under high interference conditions.
I'd also note that under video review people are notoriously bad at actually knowing how they interact with a touchscreen. Interestingly, fast response rates (and tactile response) reduce user complaints about proper operation even when UI errors remain constant. The users often assume they made the error rather than the machine. There are also interesting cognitive load effects.
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.
That is the worst way to debounce, because it adds 10ms latency for no good reason. The better way is to act immediately but ignore further inputs for 10ms. You might also want a little bit of analog filtering to improve EMI tolerance, but that shouldn't add more than 1ms latency.
If you have exceptional resources you may choose to not debounce at all, but for applications with latency behind it, it can make more sense to just wait for the user to signal they are done.
I believe the general concept is called hysteresis(1). Many systems require some prior state knowledge before acting to avoid cycling near the setpoint. As you said, the simplest solution is often a deadband around the setpoint so that action can never result in a state requiring action.
Hysteresis is what you add to the sensor in order to debounce. The bouncing effect itself is not called hysterisis, and does not require the system to have any memory - you get it as soon as there's noise in the measurement, which there always is.
Denouncing user input in UIs is indeed something you should do. Especially if it would be bad if the user input ends up triggering something twice.
The reason is that these systems all require realtime design techniques, and realtime design techniques are rarely taught in school and the overwhelming majority of software engineers don't know them, and the vast majority of software engineering managers are unaware that realtime design techniques even exist.
All computers that manage user interfaces today -- all of them -- are by many orders of magnitude fast enough to provide near-instantaneous responses to user inputs if programmed with realtime techniques.
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.
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".
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.
Absolutely. But in practice, cognitive overload rears its head in many ways.
When most people think of an intuitive system, they think of a simple system as measured in the density of information on screen ("just show me what I need to know, nothing else") and the paucity of options you have to select from (Hick's law and so forth). But if you have to perform complex activities with such a system, the seeming simplicity results in actual complexity, since you have to do things like (for example) diving into a dozen nested layers of menus and screens to reach an option that was hidden there in order to (try to) reduce cognitive burden.
A different, equally valid measurement of simplicity (and cognitive burden) is how few transitions or state changes you have to suffer through to get to the state you want to be in. That is to say: how many steps you have to take to do what you want. And since there's a chance to make an error at each step, it's not even just a question of saving clicks, it can actually be more error prone.
I say these measurements are equally valid, but not that either of them are sufficiently robust ways of thinking about good design. I'm also not trying to downplay the impact of clear, intuitive design. The point I'm trying to make is that there is no formula for making designs clear and intuitive; it's actually quite complicated. In fact, in most cases, you can't even do it, you can only find a tradeoff between imperfect solutions.
Anecdotally, I have designed dense, complex systems for quantum computing experimentalists—people much smarter than me—and had them tell me "make it simpler!". I've also tried to make simple systems for biomedical researchers, and had them tell me, in so many words, to make the UI denser and more complex. There's no correct level of simplicity you can arrive at a priori, it's different for every case, and you have to reach the right balance through testing. If you don't do enough testing, your users become your testers. The consequences are not usually this grave.
If the behavior of a sleep-deprived sailor is an unknown variable, then the obvious solution is to get a sleep-deprived sailor involved in the design process. This is not particularly complex, and while _some_ money is involved, preventing this accident would basically give you a budget of $223 million, human lives not even taken into account.
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.
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.
Why is it a good idea to use a full human to turn a wheel? The way I understand what you are saying is that the conning officer shouts “5 degrees right rudder” and some dude listens to that and puts the rudder 5 degrees right. I understand that this makes sense if turning the wheel takes physical force. There is someone who provides the smarts which way to turn it, and someone who provides the raw power to do it. But if it requires no excertion to do it, didn’t we just made a shitty voice interface for the conning officer? With all the associated manning requirement and potential for mishearing orders, and potential for confusion? Wouldn’t it make more sense for the conning officer to tap in their desired rudder on the interface themselves?
This is a practice which I think made sense with older tech where one had to put some thinking into the execution of the steering. (How much to twist the control to achieve 5 degree? Oops a bit overshot, twisting back. Now hold it steady! That kind of thing.) but now that you just peck at a touch screen the actual task is taken over by a servo motor from the sailor. But because the servo doesn’t have ears to hear the command we keep a whole human employed to do the “hear command, shout, peck, shout” loop. That and institutional inertia. If we were designing navy ships for the first time today we would surely not do it like this.
That loop is pretty valuable on the bridge, because it's not just one person driving in a bubble. Having those orders vocalized so everyone hears them and everyone knows what's happening is pretty valuable. UNREP is a very difficult and stressful kind of evolution, and so is driving during flight operations. Things need to be done perfectly and there are a LOT of variables.
We design new ships all the time, and they still generally stick to these ways. CRM isn't a thing only in aircraft.
When my family drives places we have not been before, the driver focuses on the road and the passenger seat is navigating, planning stops, etc. Sure, the driver could read them off of a GPS unit and improvise stops, but it is safer and (in our experience) better to have a separate person focusing on thinking and planning.
But also it provides a secondary check on the sensibility of the order. If my wife says "take the first right in this roundabout" and the first right does not seem like the way to go, I will do another lap and ask her to double-check. I can do that because I've been surveying the alternatives well ahead of time, which I could do only because I was not focusing on navigating.
I don't even listen to music when I'm driving. I mentally make note of my path before I drive and might have the GPS up just to be able to glance at my arrival time or traffic info here and there, but largely I don't even touch the fancy touch screen display while in motion.
For much the same reason, whenever there is an outage, I like to ensure my teams are running at least two people on the problem. When things are broken and you're trying to un-break them, having one person whose entire concentration is on doing the physical acts requires to un-break things and one person whose concentration is on monitoring things, looking up data, or reading through the SOP helps ensure things are done safely, that you have secondary checks on actions being taken and it also slows things down a little in the "slow is smooth, smooth is fast" sense.
Another thing not always obvious is the conning officer is in training to be the Officer of the Deck. He/She is learning the exact characteristics of the ship while qualifying for the next higher position.
Yes, you are absolutely correct that this can be fully automated -- and it is in merchant ships. Warships are a bit different, you want instant responses, you want people who can think and issue the right orders and people who can evaluate those orders. SN Timmy isn't stupid -- if conning officer is in the middle of an unrep (alongside another ship) and says right instead of left, SN Timmy will repeat back the order, and ten other people heard that order and there's room to stop the disaster before it happens.
You've absolutely got it where merchant shipping is concerned. Warships are different.
But i assume you don’t have to keep your finger on the touch screen to keep the rudder from moving?
But yes, a UI should be designed for the end-user, and power-user UI/UX design is a rare skill.
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.
> 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?
(btw I made that up just based on my reading of it. I don’t design Navy ship subsystems for a living - I work on specialized subsystems like these)
The temporarily assigning control of each propeller to different stations would require the automatic deselection of a synchronization (or "Gang") function during the transfer.
Why weren’t they properly trained on this? How did they get into this situation unknowingly?
I would assume a provided manual by the manufacturer would have trained the Sailors on how to properly perform this function.
This sounds like a more exceptional than routine use case.
I could definitely see value in war-time, if perhaps one was degraded or damaged, and required special attention that might justify having a person focused on it and communicating with the helm.
(as a default)
Steering via the rudder, via controlling the different throttles, or some combination has different characteristics. And which one is best would depend on the ocean and weather conditions, overall speed of the ship, as well as many other factors I don't know about.
A computer is unlikely to be able to properly account for all of this. And if it did, it would affect how the ship controls, something that you really don't want to do on a large ship.
Combining multiple controls into one computer managed control can be a good design. But I think it's the wrong design for large ships.
If it went through an HMI review it wasn't by anyone qualified to do it.
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.
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.
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.
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.
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.
My armchair assessment is that these ships should be controlled 99% by computer, which decides the best combination of thrust, rudder, etc. to move the ship where the navigator directs it (whether by joystick to indicate direction, or touch-screen to indicate where on the map you want the ship to go, as well as what speed), and the individual controls (engines, rudder, etc.) should only be overridden in the most dire of circumstances.
I'm sure there's much more to it than that, but the general idea remains the same: this is too complicated to be left to humans, whose time is better spent thinking about other parts of the mission.
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.
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.
> 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...
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.
Stop. Just... stop.
[1]: https://www.marineinsight.com/wp-content/uploads/2020/05/eng...
"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
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.
The incident report almost didn't mention design at all, so what are the chances of the problems ever getting addressed?
The fact the Touch Screen shouldn't have been there? Almost zero. EDIT: Apparently the Navy is going to put all mechanical controls back. I was totally wrong.
My guess is a bunch of retired flag officers at some defense contractor pitched it and close to retirement flag officers approved it. Maybe in 10 years, they will quietly change it behind closed doors but more than likely, someone has great idea of using Vision Pro to control everything because Heads Up Display or some insane thing they can sell to Navy for big money.
Because it's not the main issue. The crew where unaware of the physics of the controls. Would this not have happened with physical controls?
It seems it is not immediately obvious at any time how much steering is being caused by the propellers or the rudder. Having 2 physical levers positioned differently would not make it more obvious to someone already unaware of this. They woud likely not look for the Gang button even if it were a giant red button.
Now if the gang feature were designed (physically or digitally) to always snap back to locked unless some constant pressure is applied (like a spring), maybe this would be imprinted into every crew member.
Yes, it would, because it's so much easier to see. Remember that everybody on that bridge, which includes the Captain and the Officer of the Deck, was unaware of how the throttles were set. Two physical levers would have made it obvious to those people, and they could then have issued the right commands to fix it.
Airplanes have crashed because pilots misinterpreted physical levers, switches, displays, and lights. There have been accidents where a (co)pilot was confused by the lack of power they themselves were physically applying with their hands.
You can add synchronised force-feedback levers to every station, but that doesn't matter if your crew is too sleep-deprived to understand what those levers mean anyway. Not understanding the UI was only a small part in a huge shit show of problems that plagued the ship, and it was hardly the first time this sort of thing happened on that particular ship either.
If you did the same to me, I assure you I would be even stupider and my performance even more lacking.
No, this is just what non-idiots do. Any non-idiot would look at this UI and think: this is terrible.
But I generally agree with you, I think the world would be better if everyone was more thoughtful about this sort of thing.
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.
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?
Yes, the UI was obviously terrible before the accident happened. My first thought when I saw the picture was, wow, that's terrible.
You seem to be one of those people who doesn't believe that things can have inherent quality, or that anyone can perceive that quality. It's a sort of nihilism about the idea of excellence. But people do this everyday. It's easy. It's a natural impulse that most humans have when you interact with anything: this is shitty, this isn't shitty. So bad design is when something is made that's shitty and doesn't have to be.
And if a large well-funded corporation makes something shitty, that's pathetic. But it happens all the time because organisations and leaders are incompetent.
As I said, that turns your argument around: They did not make a bad UI because they are idiots, but rather they are idiots because they made a bad UI. This gives you zero insight to prevent future accidents.
> Yes, the UI was obviously terrible before the accident happened. My first thought when I saw the picture was, wow, that's terrible.
You saw that picture after you already knew that an accident happened. The interesting question is whether your conclusion would have been the same if you saw it without knowing about the accident.
I really suggest that you have a look at the CAST handbook, because every single of your arguments gets taken apart there: http://sunnyday.mit.edu/CAST-Handbook.pdf (also posted in another sub-thread, but this whole HN discussion shows that still too few people know about it)
No I thought it was shit instantly because I've played video games my whole life and if I played a game that had that UI for steering I'd uninstall it.
You could at least assume other people are intelligent when you're talking to them.
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.
i can not zoom in or out, makes me go crazy
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.
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
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.
Unfortunately, the standard in question is quite expensive and probably most of it will not be useful for web design. Is there an equivalent document/standard for websites?
[1] https://tse2.mm.bing.net/th?id=OIP.y8DdQsqhqkM_iA1f8k-qcAHaE...
Crazy to hear that such an expensive boat is basically driven by rate only controllers.
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.
Take a person at the end of their shift, sit then in front of a 'steering a ship' game with this UI: "with the controls set this way, which way will the ship move?" "we showed you a UI for 1s, were the props ganged? What was the differential in engine output?".
Presumably the US Navy has the user testing sessions recorded and archived somewhere?
The Navy could look to aircraft for some design guidance. There are significant market competitive forces pushing for user centric design when it comes to the interfaces of modern aircraft. They also have to deal with making new things look and work kind of like older systems, and provide interfaces that simplify information.
When the throttles are ganged, there should be only one slider.
When they are not ganged, there should be a visual indication of the propeller speed differential. Perhaps a horizontal bar above the throttle sliders that grows left or right according to the consequent turning moment.
For me the astounding part here is the complete lack of visual feedback of the end result. Sure I have limited nautical experience, but from sailing I know ships are a lot about force vectors. I would have imagined a ship of that class has a clever and intuitive way of displaying the forces acting on it (and the forces applied by its various parts).
This could literally be 3 horizontal bars with a 0 in the center. If the bar is filled to the left that bar makes you go left, if your bar is filled to the right, that is where it makes you go and if it is centered, you go to the center.
One bar describes the resulting turning direction of both engines, one the turning direction as indicated by the rudder and one the sum of both.
Sure there is then some ambiguity about what that means when you go backwards etc, but hey, one look at that would have told you "engine makes us go left".
Fun fact: on some airplanes if you pull on the captain's yoke and push on the first officer's, the elevator will split, the left part doing the nose up, the right one doing nose down.
>> In older ships, speed is basically controlled by a forward/backward joystick. Push it forward and the ship accelerates. Pull it back and the boat slows or goes in reverse.
>> Most of the flaws of the touchscreens could be just one software update away.
Sorry, they lost me with this. Dont lecture professionals about interfaces if you clearly do not understand the systems controlled by those interfaces. Ships are not cars. Rudders are not steering wheels. This is not a video game.
why stop me from making text smaller on your site while coming up with headlines like this? smh
:root {
font-size: calc(1vw + 1vh + .5vmin);
}
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.
The site, giving UI advice, is written assuming your display is always ~7" ?
It seems the design of this site is very much style over function.
```
: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;
```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.
The font somehow re-scales if you zoom the web page, at least with mousewheel zoom on a desktop browser. Instant accessibility failure. I've also never seen this before and couldn't work out how it had been achieved?
I haven't even read the article yet and I'm already skeptical about this author.
Or, for that matter, never considered that maybe trying to dynamically calculate font size--instead of just using standard CSS sizes like, oh, I dunno, "100%" or "medium", which are specifically intended to present the best font size for the user taking into account their device's configuration--wasn't a good idea?
The eyestrain from the font size nearly immediately gave me a headache.
No, this is crew incompetence, the checkbox is just covering the fact the crew has no idea how the vehicle works or how to operate it.
> The crew believed they had lost control of the ship because they were relying on the main steering controls, the rudder, without realizing that the ship was turning because of the secondary steering method, propellors set at different speeds
Let that sink in (no pun intended) - the crew is not aware the propellors can spin at different speeds... for three minutes... with what appears to be two giant sliders on the screen.
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.
They have very consistently used scapegoats to hide systematic issues, or problems caused by people higher up the chain.
Someone needs to polish their brass before that happens.
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.
This does look like a very error-prone design to me
What is the purpose of passing separate parts of the control to separate stations? When is that useful?
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.
You design a system to be as robust as possible to all operating conditions, which includes human fallibility.
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.