[HN Gopher] The U.S. Navy's $100M checkbox (2019)
___________________________________________________________________
The U.S. Navy's $100M checkbox (2019)
Author : davidbarker
Score : 99 points
Date : 2024-08-20 07:09 UTC (15 hours ago)
(HTM) web link (adrian3.com)
(TXT) w3m dump (adrian3.com)
| figassis wrote:
| 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?
| actionfromafar wrote:
| Training is good, but it's not like design (I mean in how it
| should be used, not looks) is something which should be
| ignored. If you have a bad design, you need an awful lot of
| training to compensate for that.
|
| The incident report almost didn't mention design at all, so
| what are the chances of the problems ever getting addressed?
| stackskipton wrote:
| >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.
| account42 wrote:
| If making the primary propulsion some ad-hoc touchscreen
| control instead of a physical lever is only something you can
| get to with hindsight then you shouldn't even be anywhere near
| to a position where you can make that mistake.
| figassis wrote:
| The point is that this was likely only one of many poor
| design decisions that were and will keep being made. I get
| touch screens are universally bad for operating vehicles or
| any other machine that requires attention, muscle memory and
| quick response times, but, if another disaster happens
| tomorrow for some other design issue not related to touch
| screens, will he then write another post about how that was
| the main issue?
|
| 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.
| pdonis wrote:
| _> Having 2 physical levers positioned differently would
| not make it more obvious to someone already unaware of
| this._
|
| 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.
| pta2002 wrote:
| This website is completely unreadable on an ultrawide monitor, it
| seems to make the font size dependent on the window's width,
| which makes it absolutely massive (I can maybe fit half a
| paragraph on the screen?), and the browser zoom does not seem to
| change the font size because of it...
| alt227 wrote:
| > the browser zoom does not seem to change the font size
| because of it
|
| This is one of the worst cases of this I have seen. It is
| literally unreadable for me. Normally I can use browser zoom to
| sort it out, but this beauty even defeats that workaround.
| tapland wrote:
| Yup, but while making the window smaller to write this I
| noticed I can make it a small window, about the size of my
| phone, to get text that is reasonable.
|
| The site, giving UI advice, is written assuming your display
| is always ~7" ?
| alt227 wrote:
| I thought that the site must be designed for mainly mobile,
| so I switched mobile mode on in the dev tools in firefox.
| However then there is some menu header text overlapping the
| main body.
|
| It seems the design of this site is very much style over
| function.
| Traubenfuchs wrote:
| Text on safari mobile is too small for my bad eyes and
| increasing font size does... not increase font size.
| rmarques7 wrote:
| The irony of this happening on an article talking about bad
| design...
| hgomersall wrote:
| It's not ironic; it just demonstrates that design is hard
| to get right.
| SirMittens wrote:
| One solution you could use to get around this weird design
| decision, is to use the reader mode in Firefox (I'm not sure
| what is the alternative for other browsers).
| alt227 wrote:
| This worked for me, thanks :)
| pjc50 wrote:
| "Reader mode" is the ultimate weapon against designer
| unreadability. It feels like it should have ADA-mandate level
| importance.
| DrScientist wrote:
| Ironic
| Brajeshwar wrote:
| Someone while designing for the mobile, forgot about desktops.
| ``` :root { font-size: calc(1vw + 1vh + .5vmin);
| } html { max-width: 100%; }
| body { color: #444; font-family: "Vollkorn",
| georgia, serif; margin: 0 auto; max-width:
| 100%; } ```
|
| They can remove the width on the HTML and replace the body's
| `max-width: 100%` with something like; ```
| width: 100%; max-width: 1200px; ```
| zo1 wrote:
| All they have to do is remove "p {max-width: 28rem;}" and the
| website becomes beautiful. The text fills the entire width of
| the screen, and the font scales with the screen size (though
| they should dial it back a bit, or have a different scaling
| ramp). It's like reading an actual document, and how the web
| should be. Bonus points, it's ridiculously "responsive" for
| small screen sizes.
|
| Yes, I know they got it kinda "wrong", but they're arguably
| going in the right direction here. I'd give the author points
| for trying something out of the box, and also for "sticking it"
| to the monstrosity that Bootstrap started many years ago.
| pjc50 wrote:
| > the font scales with the screen size
|
| 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?
| junaru wrote:
| > Two years ago a Navy destroyer was ripped open by the nose of a
| Liberian tanker. Ten sailors were crushed or drowned as their
| sleeping quarters filled with water after the collision. At the
| heart of the tragedy is a single checkbox on a touchscreen.
|
| 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.
| Prickle wrote:
| Not to forget, the same problem has happened before with
| aircraft pilots.
|
| Someone doesn't notice that the the wrong engines are running,
| or someone forgot to power down one of the engines.
|
| Or there was an engine failure. And in the confusion, someone
| powers down the wrong engines.
|
| Usually in these cases, fatigue or information overload is a
| major factor.
|
| The pilots were fully qualified. They were simply overworked,
| and too tired to realize their mistake.
|
| I wouldn't assign all the blame to lack of training. The navy
| is very famously overworked and understaffed, and not just in
| the USA.
| actionfromafar wrote:
| The air industry is very good at blame-less post-mortems and
| finding root causes. I think the Navy could benefit from some
| things from their playbook. I think one major contributing
| factor is that Navy ships are so bespoke compared to
| airliners.
| sgarland wrote:
| The Nuclear Navy is also excellent at post-mortems (though
| they're called critiques - it is still quite possible and
| reasonable to blame someone if indeed it was personnel
| failure) and finding root causes. It wouldn't surprise me
| to learn that the conventional fleet did things completely
| differently.
| ovi256 wrote:
| You are both right and wrong. A competent crew wouldn't have
| failed.
|
| But given the operating conditions (lack of sleep) and
| recruiting (lack of personnel) a competent crew couldn't be
| assembled on the McCain.
|
| The crew did their best under the conditions, and failed.
| namibj wrote:
| Sounds like they shouldn't have left port, then.
| killerstorm wrote:
| Did you read the part where control over each propeller is
| passed separately to different station?
|
| This does look like a very error-prone design to me
| krisoft wrote:
| I'm very curious about that. It sounds like the kind of thing
| which is done just because it can be done. But in doing so
| adds a wast amount of complications and makes everything very
| error-prone (as you say).
|
| What is the purpose of passing separate parts of the control
| to separate stations? When is that useful?
| RedShift1 wrote:
| An engine order telegraph wouldn't have this problem. So IMO it
| is very much a design problem, a problem that was already
| solved but needed to be created again so we can learn those
| lessons again.
| VBprogrammer wrote:
| > Let that sink in (no pun intended) - the crew is not aware
| the propellors can spin at different speeds
|
| This isn't a very good take. Every mariner is aware of using
| differential throttle to manoeuvre. It is a primary means of
| control below the speed where the rudder is effective.
|
| You've completely missed the human factors element. When what
| you are seeing doesn't match your expectation then it can
| quickly lead to issues. It's practically the exact same as
| AF447. The urgency of being about to crash into something can
| make it very hard to step back and understand what is actually
| happening.
| hgomersall wrote:
| This is nonsense. It's the same argument that people use
| against memory safe languages "it's possible to write memory
| safe code in C, you just have to not be incompetent". The truth
| is, all people are various levels of incompetence, and varies
| according to many different parameters that are all perfectly
| expected (like sleep deprivation).
|
| You design a system to be as robust as possible to all
| operating conditions, which includes human fallibility.
| maxglute wrote:
| >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.
|
| https://news.usni.org/2017/09/18/admiral-captain-removed-par...
| moconnor wrote:
| Ignorance is not a "dick move", it's having something to learn.
|
| The extreme sleep deprivation doesn't really conflict with the
| author's point that better UI could have avoided this. Better
| sleep could have too.
| DSingularity wrote:
| Certainly true but I think he is saying that the author
| should have indicated his limited knowledge of the context of
| the collision early on in the article.
| maxglute wrote:
| Yes, I'm being overly uncharitable, but it takes very inept
| research to study Mccain accident and not be exposed to the
| other 3 accidents, or be generally aware of the state of
| 7th fleet / condition of sailors from any of the reports. 4
| major accidents do not happen in that specific fleet (out
| of 7) because of UXUI, when the other 6 fleets operate the
| same ships. Extra side eye of commentary/conclusion
| reducing cripplingly bad culture around sleep to
| "drowsiness" because elevating UXUI / blaming checkbox
| works less well when operators are mentally not there. You
| don't UXUI truckers so they can drive safely on a few hours
| of sleep, you regulate how long they can drive to make sure
| they get enough sleep.
| InsomniacL wrote:
| > UXUI truckers so they can drive safely on a few hours
| of sleep
|
| 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"
| davisoneee wrote:
| In the 3rd paragraph (of which the preceding 2 were very
| short) ...
|
| "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."
| actionfromafar wrote:
| 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.
| pjc50 wrote:
| 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.
| maxglute wrote:
| Bingo. Problem is USnavy has large + increasing at sea
| staff/billet shortages, but at the same time has to (or
| insist on) on doing more missions with less sailors. You can
| build a better checkbox, but can you build a good enough
| checkbox to allow a lorry driver to drive 20 hours a day?
| Kamq wrote:
| > 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.
| cameldrv wrote:
| 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.
| pdonis wrote:
| _> For officers, much of their training is done on the ship
| via self study in their spare time instead of in a classroom_
|
| 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.
| mensetmanusman wrote:
| The fitness of American youth is also not what it once was.
| pc86 wrote:
| 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._
| maxglute wrote:
| 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.
| Xen9 wrote:
| 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.
| firesteelrain wrote:
| 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.
| iforgotpassword wrote:
| 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?
| firesteelrain wrote:
| From what I was able to infer this is the use case of
| "Splitting Thrust Control During Station Transfer"
|
| (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.
| willyt wrote:
| I've experience of steering a twin prop 50 tonne SAR vessel
| so quite a bit smaller than this but still same principles.
| We also have strict procedures for transferring command of
| the helm between different stations. There is _never_ a
| situation where you would want the throttles for each prop
| split between command stations. There is almost never a
| situation where you would want the throttle controls at a
| different station than the helm (the person steering). The
| throttles and the rudder interact a lot and in any close
| quarters manoeuvring situation you want helm and throttles
| all under the control of one person.
| netsharc wrote:
| Meta: irony is talking about bad UI, on a webpage where the
| typeface is just too damn big for a 1080p desktop screen, and
| using the browser's zoom out function doesn't do anything because
| of some "clever" CSS for the font-size.
| f1shy wrote:
| I was going to say the same. Have seen similar comments
| below... Real irony!
| netsharc wrote:
| Ah, I skimmed through the comments and didn't see anything
| mentioning it. I must've skimmed way too fast!
| pjc50 wrote:
| HN _always_ comments on bad web page design, to the extent
| of detracting from the content.
| teddyh wrote:
| Bad web page design _already_ detracts from the content.
| Complaints about bad web design are attempts to
| _resurrect_ the content.
| bheadmaster wrote:
| For anyone reading this, if you want to remove this "clever"
| CSS font-size, here's the option you need to disable in Inspect
| Element screen: :root { font-
| size: calc(1vw + 1vh + .5vmin); }
|
| It is bound to the <html> tag itself, so there's no need for
| element hunting.
| mdavid626 wrote:
| Why the hell would you do that? Makes no sense at all.
| coremoff wrote:
| FYI Reader mode solves most of these problems (not that it
| should be needed)
| zweifuss wrote:
| 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.
| pjc50 wrote:
| 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.
| VBprogrammer wrote:
| 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.
| sgarland wrote:
| 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.
| jmyeet wrote:
| That's a really good write-up.
|
| 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...
| Gnarl wrote:
| Next episode: nuke control systems UI
| hypeatei wrote:
| Hopefully there isn't dark patterns with the confirm button on
| that one :D
| sgarland wrote:
| Virginia-class has lots of screens, but they aren't
| touchscreens. The control panels have physical buttons and
| switches which are clearly labeled, logically laid out, and are
| extremely tactile. There is no confirmation for anything,
| because it's assumed that you received verbal confirmation of
| your intended action before performing it.
|
| Conversely, they also have computers for some maintenance
| items, and those (intelligently) have confirmation screens
| everywhere, because it's just bog-standard Windows UI. The
| software UI team really should talk to the control panel UI
| team.
| arethuza wrote:
| Write instructions for use of your countries nukes on
| handwritten letters in sealed envelopes and put one copy in
| each submarine!
| ghufran_syed wrote:
| 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?
| VBprogrammer wrote:
| I'm not a mariner but from what I've seen on boats and
| motoryachts the controls are typically transferred with the
| engines in neutral. This step ensures that the person who takes
| control positively knows the state of the engines and avoids
| having to do some kind of synchronisation with the current
| state. Perhaps this is problem on a destroyer or they imagined
| the controls being routinely moved around the bridge. On most
| vessels it's in the same place for the whole passage and for
| docking or departure you chose which station to use.
|
| Idling the engines for a minute while you have isn't an
| imposition as anyone prudent would be doing propulsion and
| steering tests before entering a confined area at that point
| anyway.
|
| I can only think the imagined the controls being passed about
| on a regular basis and because they didn't need to synchronise
| the physical position with the current state they skipped that
| step.
|
| Why transferring one engine at a time made sense I have no
| idea.
| titannet wrote:
| Having rudder and propeller on different stations can be useful
| to organize work on the bridge, especially on a warship. The
| possibility of having the two propellers on different stations
| is imho insane. The only reason that I can think of is a
| runaway "safety" requirement ~"if one prop control fails you
| still must be able to take control of the other prop on a
| different station". That would fit what the article says about
| them essentially running in manual backup mode all the time and
| not in the intended mode of operation.
| stackskipton wrote:
| Battle Damage or Engineering Casualty (Engine Troubles).
| Arleigh Burke speed is controlled by two factors, the RPM of
| propellers AND the pitch of propeller blades.
| https://en.wikipedia.org/wiki/Variable-pitch_propeller_(mari...
| Obviously this controls steering as well if system isn't
| functioning properly.
|
| In normal situations, computer mostly handles this and single
| station (Helm) has control over all 3. If computer fails, the
| pitch control fails or propeller engine fails, this will need
| to be controlled manually by the crew and workload is too much
| for single person. Also, in certain situations, like underway
| replenishment, all 3 control stations may be manned because if
| there is sudden failure, you need to be quickly able to
| respond.
|
| Also, the problem is touch screen period. This is case where
| putting iPad instead of levers/switches/buttons is NOT an
| upgrade. See your car climate control as good example everyone
| can relate to.
| moring wrote:
| 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?
|
| Related: CAST handbook, http://sunnyday.mit.edu/CAST-Handbook.pdf
| stackskipton wrote:
| NTSB has zero jurisdiction here. This happened in International
| Waters between US Military and Liberian Flagged ship.
| pdonis wrote:
| Hm. Someone whose entire article is about bad UI design makes it
| impossible for me to make the way-too-large fonts on the page
| smaller by using the controls my browser has specifically for
| that purpose.
|
| I haven't even read the article yet and I'm already skeptical
| about this author.
| knodi123 wrote:
| Anybody have a non-paywalled link? I'm not making a monthly
| membership so I can keep reading past the 2nd paragraph...
| renewiltord wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-20 23:00 UTC)