Prompt to turn on Bluetooth
Closed this issue · 19 comments
If the user opens CoEpi for the first time and Bluetooth is turned off, CoEpi prompts you to go to settings to enable it. But if CoEpi is already running and the user turns off Bluetooth and re-opens CoEpi, it doesn't notice Bluetooth is off, and doesn't prompt to turn it on.
CoEpi should check Bluetooth status whenever the app is foregrounded, and prompt to turn on Bluetooth if it's turned off.
It sounds like this is an iOS-specific issue: Android already checks Bluetooth status on every launch and prompts if Bluetooth is off.
"Should we maybe show a small (non blocking) notification when bluetooth is turned off? The user may be opening the app just to browse alerts or planned features like browsing the journal, and I imagine that showing a prompt to turn on bluetooth each time to be irritating. Both Android and iOS allow to observe the BT status.
It's also not necessarily more costly to implement. On Android (where we don't check it either when coming to the FG) checking it when coming to FG and wiring this with the permissions would be a bit complicated, due to internals with how the permissions work. This seems to be also discouraged in general. it probably depends too on how frequently people disable/enable BT. Do most people have BT always turned on, or do they rather enable it on demand?" -- @i-schuetz (had issues posting the comment)
So we wouldn't be able to have it pop up on FG if Bluetooth was deactivated earlier? How do the permissions work now? It doesn't trigger when Bluetooth is turned off?
Since this is a privacy focused app and one that relies on bluetooth to access other people's exposures, shouldn't we have the pop-up come to enable each time its off so people have that kind of autonomy over their Bluetooth permissions and as a reminder to activate? While it could be annoying if checking often, a user might not realize their bluetooth is off since its subtle, (and would be one more step outside the app to remember to do) which would defeat the purpose of them using the app.
Could we also put it into the "settings" page we're working on now? To indicate that a user wants to be prompted to activate bluetooth?
So we wouldn't be able to have it pop up on FG if Bluetooth was deactivated earlier?
Technically we can do this, though it's not trivial to implement, among other things because on iOS the TCN library initializes the BT (which triggers this dialog) and we'd need to add something to it to not show a new one immediately after.
How do the permissions work now? It doesn't trigger when Bluetooth is turned off?
Both iOS and Android ask for permissions when the app is started. If the permissions are given and BT is disabled, a dialog to enable it is shown directly after. On iOS this process is controlled mostly by the OS and currently triggered in the TCN library.
Since this is a privacy focused app and one that relies on bluetooth to access other people's exposures, shouldn't we have the pop-up come to enable each time its off so people have that kind of autonomy over their Bluetooth permissions and as a reminder to activate? While it could be annoying if checking often, a user might not realize their bluetooth is off since its subtle, (and would be one more step outside the app to remember to do) which would defeat the purpose of them using the app.
This is what I'm wondering whether it can be achieved with the small non-blocking notification. Note also that the notification, differently to the dialog, can be permanent (while BT is disabled), which may be beneficial (not sure).
Could we also put it into the "settings" page we're working on now? To indicate that a user wants to be prompted to activate bluetooth?
Adding such an option to the settings is of course possible. The points with the implementation of the feature itself remain.
We've to consider that we support basically 2 target groups: healthy/asymptomatic users that go out and want to see if they contact infected users, and infected users that are more likely to stay at home and use the app only to report symptoms. Reminders to enable bluetooth that are too attention drawing, are likely to alienate the "sick" target group, and make them report less frequently or not at all. But I'm not sure about this. It would be good to know whether people on average tend to let bluetooth always on, or use it more "on demand" and whether this varies when someone stays at home for large periods of time.
This sounds like the kind of thing that we'll be better able to decide once we have some real-world usage. If there is significant user demand for "let me leave Bluetooth off and don't nag me about it", we could implement something like this. I suspect most people who manually turn off Bluetooth won't mind clicking through a notification reminding them that they've done so, but we'll see...
There's an intersection here between unclear UX and implementation cost, because as I've said it's relatively complicated to implement in both platforms. On iOS we even would have to modify the TCN library and at the moment I'm not even sure it would work.
Edit: For the record, it's possible on iOS without changing the TCN library, but workaroundish / not good code.
Just a quick idea, would something like this work?
I wouldn't be opposed to something like that, but wouldn't want to spend a lot of time to implement it without clear guidance from users. If it turns out to be way easier in Android that iOS, it might be OK to have it only implemented there: iOS users are a lot less likely to turn off their Bluetooth religiously, because doing so doesn't save much battery on iPhones compared to Android phones.
If it's only a time problem: unless UX changes the design significantly, this is straight forward. With the alert (on Android) we need to sync between the permissions result and the "app comes to foreground" event + manage a flag to not show the dialog again when it's dismissed (as "app comes to foreground" is triggered). It's not difficult, but there's not much difference time wise with the idea above. It would also be consistent for both platforms.
That's not a problem to design something like that, especially if it will simplify the backend
I'm adding the design now
Okay, for the record I'm not pushing it, just adding perspective so we make an informed decision 🙂
We won't be able to have feedback about Bluetooth reminders until users have it downloaded to their phone and are using it. It's not something we can ask in user testing know since it would be a hypothetical question - so its hard to know if someone would get annoyed or not with the permissions.
You made a good point about not wanting to alienate users who are reporting frequently. I added this and am getting feedback from the rest of the team. If not here, I think it should be in the app's settings section (that we are also working on). If this works well on the back-end and keeps it simple for the user who doesn't keep getting pop-ups, this could be solution we need
Thanks! Some points:
- We can't toggle bluetooth directly, only trigger the dialog. Unless the toggle is decorative (may be ok?)
- Should we maybe label it with "Contact tracing" instead of "Bluetooth"? This way the purpose is clear (the bluetooth dialog explains the rest)
- On smaller screens the element may not be visible initially, should we put it at the top maybe?
- Do we want to show it always or only when bluetooth is off (I'm for the later, to reduce clutter in the "normal case")?
So if a user toggled the screen, the pop-up would come up? That seems weird to have on the main screen if the pop-up still comes - so then we shouldnt have it on there.
If we put it at the top, it would be like we are prioritizing it and detract from the main content : symptom adding
The popup would show only when you press on the item (or toggle). The difference with the other flow is that here we don't force the user to interact. Putting it at the top is nearer to what was initially suggested: It's important / can't be overlooked (this later point isn't very important to clarify now, unless it invalidates the idea, as we can easily change the row position).
(I think of it more as a warning/important info, similar to e.g. "app is in offline mode". Apps that support offline mode often show this, so you know that what you're seeing may be outdated, can't checkout, etc.). With the difference that we should prompt to enable.
Another idea, perhaps?
Following discussion, closing. Feel free to reopen if it's needed again.