4 ms·

I'm having trouble visualizing exactly how this works from the text, but it sounds like a total nightmare. Some sort of complicated list of steps for transferri

I'm having trouble visualizing exactly how this works from the text, but it sounds like a total nightmare. Some sort of complicated list of steps for transferring control screens between different stations on the ship, and it's not clear why or when you do this at all. I'm guessing the Navy doesn't spend a lot of time on UI/UX, which is ironic since these long, high-stress shifts with lives on the line is exactly where it's needed most. I can't imagine a worse solution than a bunch of poorly designed, unintuitive screens being transferred all over the ship in a chaotic situation.

newnewpdro 7y ago
Transferring controls between stations seems to have obvious utility if you consider the desire to relieve sailors without removing others from their stations. Give the helmsman a bathroom break by transferring the controls to another's station rather than having the people move to the controls. The whole splitting of throttle/steering controls seems a bit odd to me however. I can't imagine a situation where I was at the helm and didn't want the throttle at my command as well.
- adatavizguy 7y ago
  > The whole splitting of throttle/steering controls seems a bit odd to me however. I can't imagine a situation where I was at the helm and didn't want the throttle at my command as well. We lost electricity on our yacht at sea. There are electronic controls for both steering and throttle at the helm but none of them worked for a time. Because the yacht had two screws and the manual throttle control was in the engine room, we were able to steer and navigate the yacht with a man in the engine room with a radio. Traditionally throttle is the responsibility for engineering because there is a lot more going on with a ship than a car throttle.
- VBprogrammer 7y ago
  Only a few decades ago navy ships would have been oil fired boilers with steam turbines. Adjusting throttles wasn't a case of moving a lever. A valve had to be moved by hand, changing the flow to the turbine. This had to be done in concert with the guys in the boiler room. Doing so may have required lighting up a number of extra burners in the boiler or changing the size of the nozzles in use. Of course modern diesel engines are more flexible. You might still have to fire up the gas turbines on a modern navy vessel which would at least require checking oil etc. The systems in use likely haven't evolved far for a number of reasons.
- nostrademons 7y ago
  Damage control reasons as well. If a shell hits the bridge or CIC and wipes out half the stations, killing the sailors manning them, it's desirable to be able to move critical functions to other live sailors where they are and not make them clear away rubble or dead bodies before they can assume their functions. The previous station may not even exist anymore.
octorian 7y ago
In my own experience, any software developed under government contract has horrendous UI/UX. Probably because it's hard to specify "don't suck and be pleasant to use" in terms of formal system requirements.
- Nextgrid 7y ago
  Also because the people paying for the system aren’t the ones that will end up using it day to day. The system looks nice enough for the bean counters to approve it based on looks without soliciting actual user feedback (partly because those users are way lower down the food chain but also because of the mindset of the bean counters - they see it looks nice from their perspective but aren’t aware of the benefit of user testing).
  - octorian 7y ago
    This complete separation of "customer" and "user" is one reason I disliked working in the gov't contracting world.
- jbay808 7y ago
  I've had hits and misses. I think in general it's easy to not notice good UI because it just blends into your expectations, while bad UI stands out.
- moksly 7y ago
  It’s complicated because it’s political. You have managers, politicians, project owners, project managers, business process consultants and the actual workers all influence decisions, and often the decision becomes some sort of compromise where everyone gets something because it’s, well political. At the same time, the public sector doesn’t operate like the tech sector. We may have 2500 employees who spend 37 hours a week behind a screen, using various pieces of software to do their daily grind on the bureaucracy, but we have maybe 10 technicians to build/maintain/operate those 300 IT systems for the total of 7000 employees at 200 different locations on a network we also operate. With 10 people on staff, and political management looking to make it 9, no one can be specialised in UI/UX because you can build things without a great UI/UX. Even when you buy the development from a company who does have some UI/UX guy, the decision goes back to the compromise and messy decision making of all those different stakeholders. I think we have gotten better at it over time though, but it’s probably never going to compete with the private sector where you need great UI/UX if your competitors have it.
watwatinthewat 7y ago
I work at a Navy research center. We don't try to be profitable but take DoD clients to cover costs, trying to break even yearly. The point there is we are mission or tax funded but work for customers. The projects in my department take customer data, process/develop it in some way, and push it back out. Since we don't deal with the display at the end, there is a constant push for slides, demos, etc., from management to help sell it. Hacked up demos by non-ui software engineers then became the product, and we have million dollar contracts coming for a mobile app and something that works in the browser. The center's selling point is it's way cheaper than a private company or contractor, so subcontracting a UI designer isn't an option. I'm sure we'll have a working product, but it will probably be something like you describe. We shouldn't have taken it on, but when someone with money says, "I love it! How much?" it's hard to say no. This is not an uncommon situation.
- reilly3000 7y ago
  If they are going to own mission critical software they need to have a UX budget. The buyer has to pay for UX or they shouldn't expect to get anything but afterthoughts. If fact one could argue that a UX package should be the spec in an RFP. It would be VERY cheap to invest in training procurement teams in how to buy and own effective software, especially in light of the billions that get wasted when they can't articulate their needs to the point that a vendor can't be successful. There isn't really room for iteration and continual feedback on a warship. It has to be done right the first time then maintain stability in every conceivable scenario and reduce the need for ongoing training after updates.
- mensetmanusman 7y ago
  From what I have read, a major source of error is lack of sleep. With 4 hours of sleep, it doesn’t matter what the UI/X is...
  - seanmcdirmid 7y ago
    UI/UX does matter, actually, especially on 4 hours of sleep. It is much easier to get confused with a complex interface on less sleep than more.

newnewpdro 7y ago

Transferring controls between stations seems to have obvious utility if you consider the desire to relieve sailors without removing others from their stations. Give the helmsman a bathroom break by transferring the controls to another's station rather than having the people move to the controls. The whole splitting of throttle/steering controls seems a bit odd to me however. I can't imagine a situation where I was at the helm and didn't want the throttle at my command as well.

adatavizguy 7y ago
> The whole splitting of throttle/steering controls seems a bit odd to me however. I can't imagine a situation where I was at the helm and didn't want the throttle at my command as well. We lost electricity on our yacht at sea. There are electronic controls for both steering and throttle at the helm but none of them worked for a time. Because the yacht had two screws and the manual throttle control was in the engine room, we were able to steer and navigate the yacht with a man in the engine room with a radio. Traditionally throttle is the responsibility for engineering because there is a lot more going on with a ship than a car throttle.
VBprogrammer 7y ago
Only a few decades ago navy ships would have been oil fired boilers with steam turbines. Adjusting throttles wasn't a case of moving a lever. A valve had to be moved by hand, changing the flow to the turbine. This had to be done in concert with the guys in the boiler room. Doing so may have required lighting up a number of extra burners in the boiler or changing the size of the nozzles in use. Of course modern diesel engines are more flexible. You might still have to fire up the gas turbines on a modern navy vessel which would at least require checking oil etc. The systems in use likely haven't evolved far for a number of reasons.
nostrademons 7y ago
Damage control reasons as well. If a shell hits the bridge or CIC and wipes out half the stations, killing the sailors manning them, it's desirable to be able to move critical functions to other live sailors where they are and not make them clear away rubble or dead bodies before they can assume their functions. The previous station may not even exist anymore.

octorian 7y ago

In my own experience, any software developed under government contract has horrendous UI/UX. Probably because it's hard to specify "don't suck and be pleasant to use" in terms of formal system requirements.

Nextgrid 7y ago
Also because the people paying for the system aren’t the ones that will end up using it day to day. The system looks nice enough for the bean counters to approve it based on looks without soliciting actual user feedback (partly because those users are way lower down the food chain but also because of the mindset of the bean counters - they see it looks nice from their perspective but aren’t aware of the benefit of user testing).
- octorian 7y ago
  This complete separation of "customer" and "user" is one reason I disliked working in the gov't contracting world.
jbay808 7y ago
I've had hits and misses. I think in general it's easy to not notice good UI because it just blends into your expectations, while bad UI stands out.
moksly 7y ago
It’s complicated because it’s political. You have managers, politicians, project owners, project managers, business process consultants and the actual workers all influence decisions, and often the decision becomes some sort of compromise where everyone gets something because it’s, well political. At the same time, the public sector doesn’t operate like the tech sector. We may have 2500 employees who spend 37 hours a week behind a screen, using various pieces of software to do their daily grind on the bureaucracy, but we have maybe 10 technicians to build/maintain/operate those 300 IT systems for the total of 7000 employees at 200 different locations on a network we also operate. With 10 people on staff, and political management looking to make it 9, no one can be specialised in UI/UX because you can build things without a great UI/UX. Even when you buy the development from a company who does have some UI/UX guy, the decision goes back to the compromise and messy decision making of all those different stakeholders. I think we have gotten better at it over time though, but it’s probably never going to compete with the private sector where you need great UI/UX if your competitors have it.

watwatinthewat 7y ago

I work at a Navy research center. We don't try to be profitable but take DoD clients to cover costs, trying to break even yearly. The point there is we are mission or tax funded but work for customers. The projects in my department take customer data, process/develop it in some way, and push it back out. Since we don't deal with the display at the end, there is a constant push for slides, demos, etc., from management to help sell it. Hacked up demos by non-ui software engineers then became the product, and we have million dollar contracts coming for a mobile app and something that works in the browser. The center's selling point is it's way cheaper than a private company or contractor, so subcontracting a UI designer isn't an option. I'm sure we'll have a working product, but it will probably be something like you describe. We shouldn't have taken it on, but when someone with money says, "I love it! How much?" it's hard to say no. This is not an uncommon situation.

reilly3000 7y ago
If they are going to own mission critical software they need to have a UX budget. The buyer has to pay for UX or they shouldn't expect to get anything but afterthoughts. If fact one could argue that a UX package should be the spec in an RFP. It would be VERY cheap to invest in training procurement teams in how to buy and own effective software, especially in light of the billions that get wasted when they can't articulate their needs to the point that a vendor can't be successful. There isn't really room for iteration and continual feedback on a warship. It has to be done right the first time then maintain stability in every conceivable scenario and reduce the need for ongoing training after updates.
mensetmanusman 7y ago
From what I have read, a major source of error is lack of sleep. With 4 hours of sleep, it doesn’t matter what the UI/X is...
- seanmcdirmid 7y ago
  UI/UX does matter, actually, especially on 4 hours of sleep. It is much easier to get confused with a complex interface on less sleep than more.