SoylentNews is people
SoylentNews
The US Navy will replace the touchscreen throttle and helm controls currently installed in its destroyers with mechanical ones starting in 2020, says USNI News. The move comes after the National Transportation Safety Board released an accident report from a 2017 collision, which cites the design of the ship’s controls as a factor in the accident.
On August 21st, 2017, the USS John S. McCain collided with the Alnic MC, a Liberian oil tanker, off the coast of Singapore. The report provides a detailed overview of the actions that led to the collision: when crew members tried to split throttle and steering control between consoles, they lost control of the ship, putting it into the path of the tanker. The crash killed 10 sailors and injured 48 aboard the McCain.
The report says that while fatigue and lack of training played a role in the accident, the design of the ship’s control console were also contributing factors. Located in the middle of the McCain’s bridge, the Ship’s Control Console (SCC) features a pair of touch-screens on both the Helm and Lee Helm stations, through which the crew could steer and propel the ship. Investigators found that the crew had placed it in “backup manual mode,” which removed computer-assisted help, because it allowed for “more direct form of communication between steering and the SSC.” That setting meant that any crew member at another station could take over steering operations, and when the crew tried to regain control of the ship from multiple stations, control “shifted from the lee helm, to aft steering, to the helm, and back to aft steering.”
The NTSB report calls out the configuration of the bridge’s systems, pointing out that the decision to transfer controls while in the strait helped lead to the accident, and that the procedures for transferring the controls from one station to another were complicated, further contributing to the confusion. Specifically, the board points to the touchscreens on the bridge, noting that mechanical throttles are generally preferred because “they provide both immediate and tactile feedback to the operator.” The report notes that had mechanical controls been present, the helmsmen would have likely been alerted that there was an issue early on, and recommends that the Navy better adhere to better design standards.
[...] Touchscreens weren’t the only issue in the collision: the report calls out that several crew members on the bridge at the time weren’t familiar with the systems that they were overseeing and were inexperienced in their roles, and that many were fatigued, with an average of 4.9 hours of sleep between the 14 crew members present. The report recommended that the Navy conduct better training for the bridge systems, update the controls and associated documentation, and ensure that Navy personnel aren’t tired when they’re on the job.
(Score: 4, Insightful) by meustrus on Monday August 12 2019, @04:54PM (5 children)
There seem to be two issues here: tactile feedback, and too many ways to reconfigure it.
While everyone here is ready to jump on the "we need tactile feedback" train, the configuration issue is more important. The very idea that you would want to reconfigure the interface is a huge part of the issue here.
Reconfigurable interfaces, though, are not just about touch screens. I'll bet every nerd here has their own preferred coding setup, and I'll bet that the older you are, the less anybody else is able to use it.
Yes, I am attacking the design philosophy of tools like emacs: give the user all the levers to reconfigure their tools to be more productive. It's a reasonable approach for researchers, but at the end of the day, we would all be more productive if our tools had decades of experience and refinement baked into their unchangeable configuration.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 3, Insightful) by shipofgold on Monday August 12 2019, @05:16PM
While I agree with you for the most part, you are locking yourself into "this is the way we have always done it" mentality which tends to stifle innovation. What missing is the return channel so that when someone does stumble on an improvement in a user interface it can be baked back into the the mainline code.
"Skinning", just for the sake of moving buttons around. has never been my cup of tea and I tend to stick with the stock interfaces of most things. But when I have an extra button or two that I want, I have been known to add it to 'my' interface.
There needs to be a method for the actual users of an interface to make improvements/suggestions and have them heard.
(Score: 2) by c0lo on Monday August 12 2019, @10:50PM (1 child)
What is good for one person may not be good for an entire team that need to work together and transfer the configuration in real-time.
E.g. don't be surprised if one member of the team goes from frustrated to ballistic when he needs to use the IDE in the configuration of a colleague.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1) by khallow on Tuesday August 13 2019, @01:28AM
Like what? What's been discussed so far is personal preferences in IDEs. There's no scenario where you have to use someone else's configuration longer than a few minutes.
Then don't do that.
(Score: 2) by PiMuNu on Tuesday August 13 2019, @08:57AM (1 child)
> Yes, I am attacking the design philosophy of tools like emacs:
Disagree - what is sensible for one use case may not be for another.
Just as a simple example, if I am working on a code that has tab indentation then I need to be able to do tab indentation well. Another code, which uses space indentation, not so much. What about Fortran70 (7 spaces everywhere)?
If I am doing some complicated latex document, no doubt there is a different optimisation than if I am writing fortran.
Probably what you say is more relevant for a single dev team where people are probably using similar codes etc.
Nb: my worst nightmare is when I get a support call from a colleague who uses a Mac thanks to the horrible user interface. No right click! No Ctrl-Whatever! How can they do *anything*??
(Score: 2) by meustrus on Tuesday August 13 2019, @02:29PM
Editors can - and should - change configuration based on what they are editing. Most code editors these days will detect the indentation mode of the open file and adjust to fit, and/or have different indentation settings depending on file extension.
But there's a reason that every project past a certain size has code style rules. It's not because 8-space indentation is actually superior for kernel code (no matter what Linus the Furious says). But because having some code with 8-spaces, some with 7-spaces, some with tabs, some with 4-spaces, and some with no f*cking spaces at all is objectively worse than any of those options on their own.
As for Macs, sure they have their problems, but at least they still have a ubiquitous File/Edit/View/etc menu bar. Even programs that have long transcended their mortal shells like M$ Word or Photoshop are way more usable on a Mac because they still have that menu bar. At least, it's more usable if you're a mouser. If you're a keyboarder, go back to the shell and enjoy bashing around like a sane person instead of P[is]Sing around like some kind of Visual Basic script kiddie.
(I've long since given up on having a choice of OS so I have now resorted to mocking them all - have fun in $LINUX_DISTRO that rips off Windows and Mac in various quantities since apparently we don't have anything better to do anymore)
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?