Use slider instead of button to Deactivate Pod

[marionbarker]

Edited to says - updated now that PR #13 was merged.

I started with @dabear InsertCannulaViewImprovementsOmniKit branch for PR #13.
I merged main into my branch (InsertCannula_Deactivate_ViewImprovements) and then added the same modifications as were used for OmniBLE but to the OmniKit files.

I tested this with an Eros pod on my desktop. Insert Cannula and Deactivate pod both present a slider instead of a button.
Graphics are the same as for OmniBLE PR 102.

Both the insert slide and deactivate slider worked as expected.

[ps2]

So we already have all instances of deactivate pod behind two taps. You have tap on "Replace Pod", and then the big red "Deactivate Pod". Is there still inadvertent deactivation going on somehow? If so, please describe the context and how it happened.

[marionbarker]

I have seen instances on Facebook where inexperienced caregivers managed to deactivate a pod. I believe there were also kids who did this by mistake. I got a lot of thumbs up from parents of children who thought this was a good idea. I'll see if I can get a real-life story posted here.

I think it adds symmetry to the user experience when both insertion and deactivation have the same look and feel.

And as an adult, it is the deactivate pod that always makes me think twice.

[marionbarker]

Tina Hammer (parent of a T1D and Loop and Learn moderator) asked me to copy her comment her:

I accidentally deactivated a couple months ago. It made me 👹!

[ps2]

We don't make design decisions by the number of people who think it's a good idea, and the number of people who say they had a problem helps understand the scale of the problem, but doesn't shed much light on the nature of the problem itself. So far I've just gotten input on the former two things, and not anything that describes how this problem happens.

I assume the user went to pod settings for some normal reason (check status, suspend/ etc), scrolled down so that the red "Replace Pod” button was onscreen, accidentally tapped it, and then also accidentally tapped the big red button at the bottom? Seems pretty unlikely, but possible. It’s the unlikeliness of it that makes me want to understand it; maybe we have another issue somewhere. Are people often accidentally navigating to the “Deactivate Pod” screen for some reason?

I'm not actually opposed to this change, just wanting to understand the issue before making the decision.

[marionbarker]

I got the same answer from 2 parents where this happened to them.

[dnzxy]

@ps2

Are people often accidentally navigating to the “Deactivate Pod” screen for some reason?

I'm not actually opposed to this change, just wanting to understand the issue before making the decision.

I can only speak for myself, but I very frequently have issues with leaking pods, so have to switch before they hit their 72 hrs mark. To gather informaton that Insulet will require me to state when calling these prematurely failed pods in, I need information that is found under Previous Pod Information. On my iPhone 11 screen, when you go into the PumpManager UI for Dash, and just want to scroll down, this is what my eyes see and my fingers do:

• I tap around the yellow scribbled area and then "drag up" to scroll down.
• I am always super paranoid about hitting "Replace Pod" although I know there will be a second layer to confirm; still
• I then scroll down, and grab my information.
• I have had instances, where I accidentally hit "Replace Pod", prompting the confirm alert to open, then the iPhone has a little delay/freeze (cause it's an older iPhone, I do have memory issues running Loop/iAPS), and more than I care to admit I almost deactivated a pod, because that freeze just appeared as the alert was open, and I wasn't sure where I am really tapping, cause the entire UI is frozen.

I'm aware this may be a fringe use case, just wanted to add to the conversation.

[ps2]

To deactivate a pod during a delivery uncertainty situation takes three steps. The first screen says that Loop can't communicate, and it will keep trying to or you can "Learn More" about other options. When you press that button, then you go to a page explaining why Loop cannot display information in this state, with a spinner, a message saying "Attempting to re-establish communication", and a button saying "Deactivate Pod". You have to press "Deactivate Pod", then you're taken to another screen, with the big red button that says "Deactivate Pod" again (this is the standard deactivate pod screen you see after you tap "replace pod" in the scenario above).

As has been discussed in other tickets, this UI is difficult for users. It often happens when users are needing to do something, so they are in a mode of "click though all the dialogs" so they can get to the action they want to do (like bolus, or enter carbs). Each page only offers a single option which is a step towards deactivation. Users are not understanding that the primary action they need to take is to restore communication. If they are already tapping through three different buttons, and three pages of info about what they are doing, I think it's unlikely that a slider will stop them either.

The delivery uncertainty UX should be reviewed with the goal of helping users take action for restoring communication. Perhaps by having a button that attempts comms and has a slower timeout before reporting an error. The button doesn't really change what Loop is doing, as it's already trying to re-establish comms, but it would give the user a better understanding that this is the situation, by involving them in it.

[culdeus]

Would argue the restore communication having deactivate pod is a broken logic loop, if the pod can't connect then how can you deactivate it? If this is some FDA thing then have the button to press "Enter pod menu" or something, not deactivate pod. Some kid is going to button mash that and kill their good pod.

I have removed all those UI pop ups as they are error prone and add no value. Dash pods as a rule maintain near perfect comms and there seems no real reason to warn the user of that until perhaps 5-10 min of comm loss.

Deactivating pods should really only be issued by the UI by entering the pod menu. That's the way I'm trying to patch it to prevent accidental pod kills.

[ps2]

@culdeus Sounds like the uncertain delivery state is still not being understood; I'll take responsibility for that not being communicated well in the dialog. But it's not just a normal case of comms loss, and only happens when we're trying to make a delivery adjustment. Let me try to clarify by using the case of Loop trying to auto-bolus 2U:

Normal situation without any comms issues:

1. Loop says "hey pod"
2. Pod says "yo!"
3. Loop says "bolus 2U"
4. Pod says "no prob!"

Normal comms-loss situation:

1. Loop says "hey pod"
2. Pod doesn't respond.
3. Loop knows the pod is unavailable and doesn't send the bolus command.
   Note that in this situation we still know what the pod is doing in terms of delivery, so things like the IOB display, bolus calculations, etc still make sense, so Loop can proceed, and only alerts the user after an extended period of this happening.

Uncertain delivery situation:

1. Loop says "hey pod"
2. Pod says "yo!"
3. Loop says "bolus 2U"
4. Pod doesn't respond.
   Now we're in a situation where we don't know if the pod received our 2U bolus command and acted on it or if the message was lost. You could have 0U or 2U onboard. What does Loop display? What does it calculate if you try to bolus for a meal?

We do need to update the dialog to be better about suggesting action, and guiding the user. But this situation is real, and we can't just drop the state, and pretend everything is ok. We don't alert the user about it with a notification, as most of the times it resolves on its own. But when the user goes to use the UI, they do need to know that all of Loop's understanding of current dosing is severely impacted.

[culdeus]

I am mostly echoing Maggie Yoder's comment, and I am working to remove this as code customization in advance of winter where gloves are risky to kill a pod simply to make the button not do anything at all.

[ps2]

I think it's fine to make the "forget pod" action (it's not really deactivate, as we can't deactivate w/o comms) somewhat harder; it's currently three taps, but it is the default action on each page, and to guide the user more to actions that might help Loop recover, in the case of uncertain comms.

[marionbarker]

I modified the name to "Use slider instead of button to Deactivate Pod".

I believe the comments on how you get here when having a communications failure belongs with a different PR.

Because these changes have to be made in both OmniBLE and OmniKit, I started with just OmniBLE for this other PR.
Please see: OmniBLE PR 104: Clarify wording for Learn More screen when Unable to Reach Pod

[marionbarker]

Please hold on this PR until Loop Issue 2105 is resolved.

[ps2]

LoopKit/Loop#2105 is merged. Let me know when this is ready to merge. Thanks!

[marionbarker]

@ps2: Do you want a test on an Eros pod? We just got some donated so I have pods I can burn. Otherwise, I'll test just the DASH version and rely on code review for this one.

[marionbarker]

Other than white space and file names, this PR contains the same changes as OmniBLE PR 102 which was confirmed to work as expected using an rPi DASH.