Make Email Notifications On by Default

[shamim-emon]

• Fixes E-Mail Notifications should be default-ON #8726

[kewisch]

@shamim-emon What are your thoughts on the migration process here? What should happen to users who have not interacted with this setting and are used to notifications being off by default, who would now have it enabled on the upgrade?

[shamim-emon]

@shamim-emon What are your thoughts on the migration process here? What should happen to users who have not interacted with this setting and are used to notifications being off by default, who would now have it enabled on the upgrade?

@kewisch how about one time in-app prompt stating the fact that this setting is enabled and an option to turn this setting off?

[kewisch]

I'm a little bit cautious on in-app prompting, it can get in the way and if we have multiple such upgrades to run for e.g. users who haven't updated in a while, we might create a bunch of prompts.

If we were to prompt on upgrade, we'd probably need a more elaborate mechanism that will allow us to centrally register migrations the user can decide on, and show that prompt once on upgrade. This would be overkill for just this issue though and we'd need to involve design on how that would look.

What about something a little more subtle? Is there any logic we could use that wouldn't be a surprise to users, maybe without a prompt?

[shamim-emon]

I'm a little bit cautious on in-app prompting, it can get in the way and if we have multiple such upgrades to run for e.g. users who haven't updated in a while, we might create a bunch of prompts.

If we were to prompt on upgrade, we'd probably need a more elaborate mechanism that will allow us to centrally register migrations the user can decide on, and show that prompt once on upgrade. This would be overkill for just this issue though and we'd need to involve design on how that would look.

What about something a little more subtle? Is there any logic we could use that wouldn't be a surprise to users, maybe without a prompt?

@kewisch how about Soft Nudges then? Like a one time toast/snack-bar message when they open the app, like "You can now receive email notifications for important updates. Manage settings anytime."? Does that sound reasonable?

[kewisch]

I think it would suffer the same problem: Imagine you did an upgrade after 10 versions and got 11 soft nudges (one because our future selves forgot we already did one that release). It might also be a possibility to do something without user interaction.

[shamim-emon]

I think it would suffer the same problem: Imagine you did an upgrade after 10 versions and got 11 soft nudges (one because our future selves forgot we already did one that release). It might also be a possibility to do something without user interaction.

@kewisch How about we make email notification default conditional? Like it'd would depend on secondary flag? That flag would be false by default. It'd be only true if any account goes through on-boarding flow?
Let me know if this is something we can go with? Or do you have any alternate suggestion in mind?

[kewisch]

The least magic approach would be:

• If they have not set the flag prior, it gets explicitly set to false because this was the prior default. We do this as a migration.
• If they have set the flag to either true or false it stays the way it is
• If no accounts exist then they will get the implicit new default of true when the account is created, no explicit setting.

The downside here is that with that migration, we have no indicator if they have previously set the notifications or not, so if we later decide to tell users they can enable notifications, we don't know if they made a choice or not.

It might be worth looking if there is some indicator we have they went through the QR code import flow, in which case we might want to not set to false explicitly but instead keep the implied true.

The next thing I would do (that I have not) would be to determine how they previously ended up with the implicit false choice, and if it would be a surprise for them if notifications were on. We could also consider running an experiment on beta where we just default to true like you have, with no migration, and see what the feedback is.

I'm intentionally not making a decision here because I'd like to have your opinion. Given these constraints, what do you think would best serve the user?

[shamim-emon]

The least magic approach would be:

• If they have not set the flag prior, it gets explicitly set to false because this was the prior default. We do this as a migration.
• If they have set the flag to either true or false it stays the way it is
• If no accounts exist then they will get the implicit new default of true when the account is created, no explicit setting.

The downside here is that with that migration, we have no indicator if they have previously set the notifications or not, so if we later decide to tell users they can enable notifications, we don't know if they made a choice or not.

It might be worth looking if there is some indicator we have they went through the QR code import flow, in which case we might want to not set to false explicitly but instead keep the implied true.

The next thing I would do (that I have not) would be to determine how they previously ended up with the implicit false choice, and if it would be a surprise for them if notifications were on. We could also consider running an experiment on beta where we just default to true like you have, with no migration, and see what the feedback is.

I'm intentionally not making a decision here because I'd like to have your opinion. Given these constraints, what do you think would best serve the user?

@kewisch IMO We could also consider running an experiment on beta where we just default to true like you have, with no migration, and see what the feedback is. is a good suggestion and would like to move forward with it.

[shamim-emon]

@kewisch @wmontwe added corresponding default values under Feature flag, please let me know if that's alright or you'd prefer any alteration. Thanks

[kewisch]

@shamim-emon I might be in over my head on this review. I looked at https://github.com/thunderbird/thunderbird-android/pull/8650/files where a feature flag was added and there are a few more changes to ensure the flag is enabled on daily+debug, in our case should also be enabled on beta, but disabled on release. Would we need something like that as well?

[shamim-emon]

@shamim-emon I might be in over my head on this review. I looked at https://github.com/thunderbird/thunderbird-android/pull/8650/files where a feature flag was added and there are a few more changes to ensure the flag is enabled on daily+debug, in our case should also be enabled on beta, but disabled on release. Would we need something like that as well?

@kewisch just did this in this PR . Will also do it here. I have created another PR aiming to add more flexibility around feature flag handling. Once there's a decision on it, I will be able to move forward with your suggestion here.

[shamim-emon]

@kewisch @wmontwe updated the default under feature flag and enabled/disabled flag based on build type. Please let me know if anything else is required. Thanks

[kewisch]

Thanks @shamim-emon ! Wolf will take a look soon.

[wmontwe]

Thank you, I propose a different approach instead of including the feature flags in the account object.

[wmontwe]

Looks good! Just two minor changes.

[wmontwe]

👍

[thunderbird-botmobile]

Thanks for your contribution! Your pull request has been merged and will be part of Thunderbird 11. We appreciate the time and effort you put into improving Thunderbird. If you haven’t already, you’re welcome to join our Matrix chat for contributors. It’s where we discuss development and help each other out. https://matrix.to/#/#tb-android-dev:mozilla.org
Hope to see you there! 🚀📱🐦