Petrel controller to much info or not enough?

[iointerrupt]

Static fixed displays are strictly superior here. In an emergency situation, the last thing you want, is to look down at the computer, and see a new unfamiliar display layout. It adds cognitive load at the precise worst moment to do so.

That said, I do think big improvements in these displays are possible, but mostly through better organization and font size choices.

 

[mr_v]

Static fixed displays are strictly superior here. In an emergency situation, the last thing you want, is to look down at the computer, and see a new unfamiliar display layout. It adds cognitive load at the precise worst moment to do so.

That said, I do think big improvements in these displays are possible, but mostly through better organization and font size choices.

Not sure if I am following you - progressive information discovery (aka "progressive disclosure") is one of the key concepts of good interface design. You show only the basic information first and let users see more info if necessary. A typical example is "basic" vs "advanced" settings in software. "Normal" working mode and "emergency" modes will be different here - "contextual awareness" in ux design. For example, if my battery is good but I need to pay attention to the cells during an emergency, why should I see battery info on the screen? I.e. a well-designed interface will focus users only on the information required for the user to perform a specific task in the given context. Approachability wins here.

As for your question, there are at least two things that stop you from seeing unfamiliar display layouts.

First, tutorials. Yes, users will have to read just like they do now.

Second, baked in emergency scenarios. It is possible to show emergency situation simulations. You don't have to do this in the actual hardware/dive computer - an phone app or a web site is sufficient. Integrations with different manufacturers will add substantial costs in this as the company making a dive computer will have to understand what emergency situations may happen in various CCRs and then account for those scenarios.

In general, good user experiences revolve around understanding the jobs that users must do while using a product. For a CCR diver, we can define the following jobs:

1. Get a unit ready for a dive.
2. Monitor the unit during the dive.
3. Change settings during the dive.
4. Deal with emergencies.
5. Perform post-dive configuration.

Each of these jobs may have sub-tasks. Unfortunately, many of these jobs/tasks will be unit dependent which means additional costs for all the parties involved. That's why Shearwater does what it does. Some screens are static and are open to use interpretation (e.g., showing PPO2 for individual cells.) Other screens correspond to the general flows applicable to divers on all units (e.g., define gas).

 

[iointerrupt]

Progressive information discovery is just one tool in the interface designers toolbox. Works splendidly for an online banking website, but it is the wrong tool for a realtime life support system.

After years of looking at the same dive computer display, the "man-machine interface" starts to disappear. In an emergency not a thought is wasted on "wait what is this showing me now". You look at the display, you see the numbers you need, you act.

This, is the height of good design and usability, to me.

 

[Markus MDDT]

I agree. Seems Shearwater products are falling into the feature-creep territory that are providing diminishing returns. Moreover, the information presented on the screen is mostly ad-hoc and does not correspond to the usual task flows. Some may argue that it is an intentional design logic - the diver must think.

If I would do a process risk analysis for a stressful scenario and rank all actions or "process steps" that would have to be done in order to stay alive, the manual steps which relied on the diver visually getting an input and acting correct out of the data would have WAY higher risk than then the automated actions. I generally see manual operations as being perceived as low risk because you think you are "skilled" and want to live. The data I see points me to trying to eliminate that manual process as much as possible to save a life. The risk wont be zero but generally MUCH lower. IF I have to do a value based decision I really only want the data that is critical, NOTHING else.

The case posted by the OP is interesting one. Having some background in human factors, here's how I'd approach this.

- Show the average PPO2 when all cells are in sync. The definition of "in sync" is critical here. Ideally, you want to define a monitoring timeframe and acceptable deviation ranges in that timeframe, e.g., "in last 5 minutes the cells were no more than 0.01 apart with sampling done every 10 seconds."

Interesting Idea!
I think Shearwater has already (and is doing) a very good job of determining when a cell is actually deviating and/or could impact deco etc. This relies on statistic-modelling and we should not get warned when we are inside of the normal variance. Acting on normal variance fluctuations taskloads us and can make us "over steer", causing a problem when there is not.

- If the cells become out of sync, switch the display from showing one value to showing value for each cell and prompt the diver to perform a flush/cell reference check using the best reference gas available. For example, if flushing with one gas should give PPO2 of 0.8 and flushing with the other gas should give PPO2 1.1, the other gas is shown as the desired flush gas.

- After performing the flush, the diver can monitor PPO2 of each cell and vote out the cell that is not performing well.

- Go back to the main mode that displays the average information.

Yes. that could definitely work!

 

[Markus MDDT]

Progressive information discovery is just one tool in the interface designers toolbox. Works splendidly for an online banking website, but it is the wrong tool for a realtime life support system.

This IS the tool for developing banking websites but it still uses the same principles of understanding how the brain processes information presented to us which is very applicable to more critical situations. Just an example is the "Pull Up" and "Terrain" audio prompts you get in a plane. Visually removed from UI (backed up by altimeter of course) for the same type of reasons I give. "They could just look at the altimeter!!" apparently not enough or correct type of presentation of info in the scenario. In Jas 39 gripen they even have male and female voices depending on which prompt. Brain reacts differently depending o gender.

After years of looking at the same dive computer display, the "man-machine interface" starts to disappear. In an emergency not a thought is wasted on "wait what is this showing me now". You look at the display, you see the numbers you need, you act.

This, is the height of good design and usability, to me.

I really think we are not at the pinnacle of technical design and usability. Good? Yes! But not at the top

 

[mr_v]

If I would do a process risk analysis for a stressful scenario and rank all actions or "process steps" that would have to be done in order to stay alive, the manual steps which relied on the diver visually getting an input and acting correct out of the data would have WAY higher risk than then the automated actions. I generally see manual operations as being perceived as low risk because you think you are "skilled" and want to live. The data I see points me to trying to eliminate that manual process as much as possible to save a life. The risk wont be zero but generally MUCH lower. IF I have to do a value based decision I really only want the data that is critical, NOTHING else.

So yeah, the process kinda works like that when we design user flows. We analyze all tasks, assign criticality, etc.

In a typical highly automated system, computer deals with all mundane tasks and users deal with exceptions. Anytime there is a calculation or a process that requires multiple variables, computers are faster and less error prone.

@iointerrupt, I misspoke about the specific emergency case. I meant to say/add "contextual awareness," i.e., computer detects and abnormality and UX reflects that. You already see some of that, a bit primitive, in Shearwater, e.g., a user must acknowledge a warning that PPO2 is too high. It is done better in other cases by other manufacturers, e.g., Apple can detect a fall and a car can detect a crash.

Here is the kicker - the cost of such system development is too high. That's why companies that deliver superb UX prefer to design everything from hardware to software while imposing exceptionally strict requirements on partners. Apple was the first in the software area but now everyone's catching up.

With underwater life support systems, you essentially need to find people who are well versed in design and understand what you're trying to accomplish - a very hard task in diving because diving science, especially rebreather, is less of a common knowledge.

Btw, Poseidon stands on out in ths area. Its interfaces and flows seem to resonate well wtih diver tasks - I was impressed! - but they won't sit well with many people who prefer manual controls. Shearwater will have a rebellion the moment it tries to streamline more flows than it already has. Moreover, it will have top work with multiple unit manufacturers to adapt the flows. I was a part of the OEM team that did that in a different industry - what a pain in back that was...