Modal "can't communicate with pod" error is really bad

[caitp]

Describe the bug
This breaks all interactivity with the app, preventing views of history, diagnostics, etc.

To Reproduce
Steps to reproduce the behavior:
have a connectivity issue with a pod

Expected behavior
Don't block access to logs, settings, diagnostics, etc

Screenshots
N/A

Phone

• Hardware: iPhone 13
• OS Version: iOS 17.1.2

Loop Version

• Version Number: 3.2.3 (57)
• Repo: LoopKit/Loop

CGM

• Device: Dexcom G6
• Manager app: Dexcom App

Pump

• Manufacturer: Insulet
• Model: OmniPod (not the new one)
• Firmware version: n/a

Additional context
Modal dialogs are always bad, especially when they prevent diagnosis oraccess to essential info

[marionbarker]

Please review this section of LoopDocs:

• https://loopkit.github.io/loopdocs/operation/features/notifications/#loop-alert-unable-to-reach-pump

We are in agreement that the messaging needs to be updated.
There is a PR waiting for review for DASH. Once the wording is found acceptable, that will be added to the other pump managers.

• OmniBLE PR 104: Clarify wording for Learn More screen in Uncertain Delivery State

Please close this issue. We do not need it open to track this concern.

[caitp]

You arent getting it, it isn't the wording that is the issue, it's that the dialog is modal and prevents access to diagnostics and other functionality

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[caitp]

This issue is not stale, it just has not been addressed yet

[marionbarker]

There are PR in place to update the message for both OmniBLE and OmniKit.

There is a different issue #2118 for a true problem for Eros pods.

There are no actions that can be taken with the Loop app until comms are restored or pod is discarded.

DASH pod (OmniBLE) comms restoration causes an immediate return to normal operation for Loop.

Eros pod (OmniBLE) comms restoration does not return promptly as detailed in the other issue linked above.

In both cases, history is uncertain unless comms are restored.

[caitp]

That simply isn't true, though. Diagnostic logs, rileylink selection, cgm status, Health records, all would be available

[marionbarker]

Please understand - I am not the designer, I'm trying to explain how it works and what I think is the thought process is behind this. (Avoid someone making assumptions about the Loop prediction that may be invalid.)

It is possible this needs to be readdressed with the addition of the libre sensor in Loop-dev.

@ps2 needs to answer that.

Loop takes on the role of the CGM app in that case. I'm not sure if the manufacturer's CGM app is still available for that case. With Dexcom, there is another app you can look at to get CGM readings.

• The rileylink selection is available when you tap the Learn more button so you can switch to a different rileylink. (Scroll to the bottom of Learn more screen.)
• Health records are available through Apple Health.
• You are correct that Diagnostic logs from Loop are not available until comms are resumed or you discard the pod.

[caitp]

I understand how it works, and understand that that's what you're doing. I'm not trying to be snooty here :) But I don't believe I'm wrong here.

The app can clearly communicate that there is a comms error and that readings may not be reliable in any number of ways, without breaking the general layout and navigation of the application, or requiring users to jump through hoops to see their data. Text overlays, colours, icons, or simply not showing a glucose prediction at all. (in conjunction with the rest of those items). Doing this while still providing CGM readings and access to settings and diagnostics would be perfect. Making the entire application unusable because of a bluetooth or battery issue, is not a good UX. Similarly, hiding access to useful tools like the rileylink selection behind "Learn more" does not make sense, users should be able to use the processes they're already trained on to do this.

[marionbarker]

There was a missing line in OmniKit that interfered with the design of the uncertain comms handling for Eros.

Please see Issue #2118 and PR LoopKit/OmniKit#25

[4gra]

@caitp I agree. What are the steps required to re-enable this functionality, like moving to open loop for example? If so, documenting this is I suppose a reasonable path to take. But the modal needs to be easily, permanently dismissible.

A realistic user story is pump battery failure: not necessarily immediately resolvable by the user (you're outdoors, away from replacement, etc.), but the information Loop provides (history, diagnostics, etc.) is still critical and will inform user actions (exercise, treatment, recording of pen insulin, etc.), and locking down functionality suddenly is at best unnecessary and at worst compounds the risk by removing access to info.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[caitp]

@4gra

@caitp I agree. What are the steps required to re-enable this functionality, like moving to open loop for example?

I'm not entirely sure what you mean here in terms of re-enabling, so I'm not sure how to respond to this. Are you asking how we could allow people to opt into the modal "lock everything up if we can't connect to the pump" behaviour?