Hacker News Reader

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.

It sounds like you are knowledgeable about this stuff so if I don’t mind you asking:

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?

It's not just about turning the wheel, though, is it? I would assume that much like when driving a car, it's a longer process of being a human PID controller and making small adjustments to angular acceleration based on feedback from the system. It might be useful to remove this mental load from the decision-maker.

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.

>But also it provides a secondary check on the sensibility of the order.

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.

two sets of eyes are always better than one.

I am totally with you here. It's amazing to me how as cars have gotten easier to drive with technology, we've continued to add distractions to the driver as "features".

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.

All of this, exactly.

Part of it is everybody knows exactly what's happening, but one dude has one job, and that is to put the rudder exactly where it's supposed to be and hold it there. It isn't actually like there's something that holds the rudder in position -- it is manual, like driving a car, and the rudder will move if not held in place. Also, the order might not be rudder left 5, it might be steer course xxx. Then they use their training to hold the ship on that course.

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.

> It isn't actually like there's something that holds the rudder in position -- it is manual, like driving a car, and the rudder will move if not held in place.

But i assume you don’t have to keep your finger on the touch screen to keep the rudder from moving?

As I recall, you still input rudder orders with a wheel on these. Maybe you can enter a rudder setting? The system actually can fully automatically drive the ship. You can just enter a navigation plan and it will do the whole thing. The Navy doesn't use that capability though.

Thank you for the answers!

the conning officer often has tons of other stuff to deal with that require them not to be distracted by having to change course themselves.

So do airplane pilots and you don’t see them shouting yoke orders to a sub-pilot.

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.

I think you will definitely hear the pilot and copilot communicating, and they split up tasking between them -- one flies and one monitors equipment and makes system entries. They're also way way more qualified and educated than SN Timmy who got a few hours of training on how to do his job.

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.

most complex and/or commercial aircraft do share the workload between a pilot-flying, and a pilot-non-flying—in addition to the captain & FO hierarchy you are probably aware of.

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.

Also, given the possible context of wartime, the most basic "make the ship go" controls absolutely need to be understandable and usable by a concussed one-armed half-blind ensign who just got on board yesterday... because, sometimes, that's what happens.

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.

This is a really interesting counter-argument.

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

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

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

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

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

> if you can reduce some of the cognitive overload, aren't you effectively defending in depth?

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.

It seems to me that an unspoken assumption in this thread is that "design" is purely theoretical work, performed by a designer.

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.