Closed Bug 1479532 Opened 2 years ago Closed 2 years ago
Use more sensible importance level for default notification channel
46 bytes, text/x-phabricator-request
|Details | Review|
46 bytes, text/x-phabricator-request
|Details | Review|
46 bytes, text/x-phabricator-request
|Details | Review|
As far as I can tell from , only the tab queue notification used when lacking the "Draw over Apps" permission and the "synced tabs received notification" use a higher than default priority on Android versions not supporting notification channels. So we should - definitively create a separate channel for synced tabs with IMPORTANCE_HIGH - think about what to do with the tab queue error notification (either accept a lower priority going forward, or create some channel that makes sense for that kind of messages, though I've got no real idea what to call it - "Important messages", "Error messages", ...???) and then lower the importance of our default notification channel to what is probably IMPORTANCE_LOW (so as to not cause audible notifications by default). While we're at it, we might also be able to think of a better display name for our default notifications channel other than simply repeating our app name.  https://dxr.mozilla.org/mozilla-central/search?q=path%3Amobile*java+notification+priori&redirect=false
This is really annoying. Something like twitter or reddit with looping video results in a very aggressive notification.
(In reply to Kevin Brosnan [:kbrosnan] from comment #1) > This is really annoying. Something like twitter or reddit with looping video > results in a very aggressive notification. Bug 1477700 would fix that even for existing users by assigning the media notification to a new channel with more sensible settings. In the meantime a workaround would be to manually adjust the settings for Firefox's currently one and only notification channel.
For new users this will be effective immediately. For our existing users, we can fix this by also using a new Channel ID for our default channel (so we get a chance to set a more sensible default priority) and calling deleteNotificationChannel for the old channel ID to hide it for people who have already installed Firefox.
Previously, most of our notifications were silent, so we adopt a default priority of IMPORTANCE_LOW instead of IMPORTANCE_DEFAULT. Since we cannot change the priority setting for existing users on Nightly any more, we technically have to retire the old default channel and replace it by a new channel with a different ID. While in a way this is circumventing Google's API design and destroys any existing customisation users have set for that channel, we are only using this exceptionally to *lower* the initial priority of our default notification channel, which we accidentally set too high. Besides, it is unlikely that there are many users who really want to receive all kinds of random Firefox notifications with a high priority. We also take the opportunity to rename the default channel to the slightly more descriptive label of "Miscellaneous" instead of just repeating our app name.
This channel is intended for messages that require a higher priority than normal, but don't merit a dedicated channel of their own. For now, the only use case is for notifying the user if we're lacking the "Draw over apps" permission required for Tab Queues.
Comment on attachment 9004330 [details] Bug 1479532 - Part 0 - Cleanups. r?jchen Jim Chen [:jchen] [:darchons] has approved the revision.
Attachment #9004330 - Flags: review+
Comment on attachment 9004329 [details] Bug 1479532 - Part 1 - Create notification channel for receiving synced tabs. r?jchen Jim Chen [:jchen] [:darchons] has approved the revision.
Attachment #9004329 - Flags: review+
Comment on attachment 9004328 [details] Bug 1479532 - Part 2 - Create notification channel for one-off high priority messages. r?jchen Jim Chen [:jchen] [:darchons] has approved the revision.
Attachment #9004328 - Flags: review+
Comment on attachment 9004327 [details] Bug 1479532 - Part 2 - Use more sensible importance level for default notification channel. r?jchen Jim Chen [:jchen] [:darchons] has approved the revision.
Attachment #9004327 - Flags: review+
Hi Bram, I've got two questions regarding the names for some of our notification channels: 1. We need a separate notification channel for possibly various one-off notifications that don't fit a specific category, but unlike other notifications require a high default notification priority . My original idea was "Important notices" (but I wasn't entirely happy with that choice to be honest), while jchen suggested just calling it "Notice" . 2. What should our default notification channel, which will be used for any notification not assigned a more specific channel, be called? At the moment we're using "&brandshortname" there, but personally I don't think this is ideal: The list of notification channels appears within Android's app settings for our "&brandshortname" app, so just repeating that name for one of our notification channels doesn't really tell the user anything new, or more importantly, what kind of notifications to expect from that specific channel. Hence I my suggestion was to rename that channel to "Miscellaneous", which is at least more honest about what kinds of notifications are grouped under that channel, but jchen on the other hand thinks that that choice of name sounds too generic .  At the moment, the error message shown when we don't have the required "Draw over apps" permission for the Tab Queues feature is the only message in that category, though.  https://phabricator.services.mozilla.com/D4365#inline-16224  https://phabricator.services.mozilla.com/D4364#inline-16227
Landing the clean-up patch in advance of the rest.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/b6b190197966 Part 0 - Cleanups. r=jchen
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/24d55d779101 Part 1 - Create notification channel for receiving synced tabs. r=jchen
Also landing part 1 - if we cannot uplift string changes to Beta, we can do without part 2 for a revision and leave out the string change from part 3 for uplifting.
(In reply to Jan Henning [:JanH] from comment #14) > Hi Bram, I've got two questions regarding the names for some of our > notification channels: > > 1. We need a separate notification channel for possibly various one-off > notifications that don't fit a specific category, but unlike other > notifications require a high default notification priority […] > > 2. What should our default notification channel, which will be used for any > notification not assigned a more specific channel, be called? At the moment > we're using "&brandshortname" there, but personally I don't think this is > ideal[…] Hi Jan, Would you help me understand the problem a bit better? As I understand it, currently we have only one notification channel under Settings > Notifications: > What’s new in Nightly > Learn about new features after an update And your proposal was to create two new channels: 1. One-off notifications that’s high priority but don’t fit any category 2. Any other notifications not fit for more specific channels My thinking is as follows: * Try to closely follow our In Product Communication strategy: https://docs.google.com/presentation/d/1H5A-obzXXIL0AX4BJRdcqFRc7IkE9ajOJVFCYBSB5Ts/edit * It sounds like our high-priority but non-specific messages are permission alerts (ie. a permission needs to be granted; without it, Firefox cannot function correctly) and other such alerts. Why not call it “Warnings”? And are there bad repercussions if the user turns all “Warnings” off? (If that’s the case, then maybe we should enable it by default, and not have a way to turn it off.) * What are some sample notifications that belong in the “Default” channel? It will help us come up with a name. * This sounds like a problem well suited to our Content Strategy team, so I’m CCing Michelle Heubusch on this bug.
Flags: needinfo?(bram) → needinfo?(mheubusch)
Sorry. The right person to CC is Brian Jones.
Flags: needinfo?(mheubusch) → needinfo?(brjones)
(In reply to Bram Pitoyo [:bram] from comment #20) > * Try to closely follow our In Product Communication strategy: > https://docs.google.com/presentation/d/1H5A- > obzXXIL0AX4BJRdcqFRc7IkE9ajOJVFCYBSB5Ts/edit That presentation is behind a login, so I cannot see it (I'm not an employee). > Would you help me understand the problem a bit better? Sorry for not giving you enough context here. This isn't about our current in-app notification settings from Settings > Notifications, but about the new Android OS feature introduced in Android O: https://developer.android.com/training/notify-user/channels The main point about notification channels is that on previous Android versions, the app had absolute control over how notifications were going to be displayed (silently, audible, with vibration/lights/..., peeking out at the top of the screen, etc.). With Android O on the other hand, notifications are just assigned to a notification channel (previously created by the app) and then it's the notification channel that controls how that notification appears. While the app can set the initial notification settings for a channel when first creating it, afterwards the settings are under full control of the user and cannot be programmatically changed by the app any more. Also, for apps targetting Android O or later, notification channels are mandatory. So you need at least one channel for every separate combination of notification settings you want to use, plus separate channels for everything else that the user should be able to control separately (e.g. having a separate channel for the media control notification allows the user to set the contents of just that notification as visible on the lock screen, while keeping all other notification contents hidden for privacy reasons). Now when we first implemented notification channels, we only did the minimal solution of creating a single notification channel for all notifications. For whatever reasons, the default priority of that channel was set to High, which meant that on Android O and later, all Firefox notifications would suddenly start appearing as audible high-priority notifications, appearing visibly at the top of the screen. Even worse, this also happened when updating an existing notification, including each time the download progress on a download (or updater) notification was updated. So of course we got a number of bug reports about users being annoyed by that. Since for users who had already installed that update we couldn't change the priority settings of the default channel any more and nobody thought of the solution I came up with in Part 3 for replacing the default notification channel, the only choice was to create new notification channels with more sensible default priority levels for any kind of notification that came up frequently enough to annoy users when using a default priority setting of High. Hence our current set of notification channels already ended up at what is visible here: https://hg.mozilla.org/integration/autoland/file/24d55d779101/mobile/android/base/locales/en-US/android_strings.dtd#l897 (note that the Updater channel is only used on Nightly, and I plan to hide it for Nightly builds installed from Google Play as well), plus the planned additional channels for Leanplum promotions from bug 1486432 and the generic High priority Warnings channel from this bug. > * It sounds like our high-priority but non-specific messages are permission > alerts (ie. a permission needs to be granted; without it, Firefox cannot > function correctly) and other such alerts. Why not call it “Warnings”? Yes, "Warnings" might fit nicely, thanks for the suggestion. > And are there bad repercussions if the user turns all “Warnings” off? (If that’s > the case, then maybe we should enable it by default, and not have a way to > turn it off.) See above - as this is an OS feature, we cannot control what the user does with it after we create the channel. Hence it's important not to abuse the our high priority channels so the user doesn't ever feel the need to downgrade or block those notifications. > * What are some sample notifications that belong in the “Default” channel? > It will help us come up with a name. Looking at https://searchfox.org/mozilla-central/search?q=Channel.DEFAULT&case=false®exp=false&path=mobile**java and subtracting things in bug 1486432 and this bug, what's left is - the data reporting settings notification you get after installation - notification when Guest Mode is active - any notifications sent by Gecko that are not concerning Downloads (i.e. mainly Web Push Notifications sent by web pages the user has given permission to, although there might be a few other notifications triggered by app code implemented not in the Java Android app part, but from Gecko code instead, and in my opinion Web Push Notifications might in theory merit a separate channel of their own as well) - the What's New notification - queued Tab Queue tabs - Firefox Accounts notifications
(In reply to Jan Henning [:JanH] from comment #22) Thanks a lot for clarifying! Below is a list of our current notification category names, as they exist under Settings.app: * Firefox ← this is the default, general purpose channel * Firefox Location Service * Downloads * Media playback * App updates * Synced tabs To this, we want to: 1. Rename the default, general purpose channel 2. Add a new channel for high-priority, non-specific messages Here are my initial recommendations, which looks at all the categories together and try to come up with a unified terminology, so the resulting strings are consistent: * Firefox → Browser * Firefox Location Service → Location service * Downloads * Media playback → Sound and video * App updates * Synced tabs * (no name) → High priority alerts (alternative title: Permission alerts) What do you think of this initial direction? I’ll know better after talking to Content Strategy (NI’d in this bug).
(In reply to Bram Pitoyo [:bram] from comment #24) > * Firefox Location Service → Location service Hmm, that string was specifically chosen to correspond to the wording we use elsewhere - the settings option for that and the notification title all use "&vendorShortName; Location Service": https://dxr.mozilla.org/mozilla-central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/mobile/android/base/locales/en-US/android_strings.dtd#441-446
(In reply to Bram Pitoyo [:bram] from comment #24) > To this, we want to: > > 1. Rename the default, general purpose channel > 2. Add a new channel for high-priority, non-specific messages And 3., the Leanplum channel from bug 1486432, although there are separate needinfos open in that bug on whether we can still come up with a better title than what has currently landed.
(In reply to Jan Henning [:JanH] from comment #25) > (In reply to Bram Pitoyo [:bram] from comment #24) > > * Firefox Location Service → Location service > > Hmm, that string was specifically chosen to correspond to the wording we use > elsewhere In that case, let’s keep using “&vendorShortName; Location Service” (In reply to Jan Henning [:JanH] from comment #26) > And 3., the Leanplum channel from bug 1486432, although there are separate > needinfos open in that bug on whether we can still come up with a better > title than what has currently landed. While the name “Snippets” is short and sweet, it’s also vague. I wonder if it’s more correct to describe it with something like “Mozilla and Firefox products and services”? (Whatever description we use, we should also use it in this page to ensure consistency between Firefox Settings and the Android System Settings).
I'm moving the string changes into bug 1488874 in case we cannot uplift them anymore and will land only part 3 minus the string changes in this bug.
Attachment #9004327 - Attachment description: Bug 1479532 - Part 3 - Use more sensible importance level for default notification channel. r?jchen → Bug 1479532 - Part 2 - Use more sensible importance level for default notification channel. r?jchen
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/c5c8915e1e6e Part 2 - Use more sensible importance level for default notification channel. r=jchen
Comment on attachment 9004327 [details] Bug 1479532 - Part 2 - Use more sensible importance level for default notification channel. r?jchen Approval Request Comment [Feature/Bug causing the regression]: Android O support, bug 1450447 [User impact if declined]: Some of our notifications will appear as audible, heads-up, high priority notifications, even though they aren't actually that important and weren't appearing as a high priority notification on previous Android versions. [Is this code covered by automated tests?]: No. [Has the fix been verified in Nightly?]: No. [Needs manual test from QE? If yes, steps to reproduce]: Install a previous, affected build on Android O, verify that our default notification channel (&brandshortname, i.e. presumably Firefox Nightly or so) is set to alert audibly and that e.g. the post-installation data collection notification, or the guest mode notification indeed create an audible alert. Then upgrade to a fixed build. Verify that there is still only one notification channel called &brandshortname in Android's notification settings for Firefox. Verify that e.g. the guest mode notification no longer causes an audible alert when it appears. The latter part should also hold for a fresh install. [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: No. [Why is the change risky/not risky?]: Minor change to replace our previous default notification channel with a new channel created with the correct default priority. [String changes made/needed]: none
Attachment #9004327 - Flags: approval-mozilla-beta?
NI moved over to bug 1488874.
Comment on attachment 9004327 [details] Bug 1479532 - Part 2 - Use more sensible importance level for default notification channel. r?jchen Approved for the next 63 beta
Attachment #9004327 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Just to clarify, it's only https://hg.mozilla.org/mozilla-central/rev/c5c8915e1e6e that requires uplifting, everything else either already landed in 63 or will be handled in bug 1488874.
QE, please verify this thanks.
Verified as fixed on latest Nightly build 64.0a1 and latest Beta build 63.0b5 following the steps from comment 30. Device: Samsung Galaxy S8(Android 8.0.0).
You need to log in before you can comment on or make changes to this bug.