Page MenuHomePhabricator

[Notifications] Update Settings > Notifications view
Open, MediumPublic

Description

Update our current Settings > Notifications subpage.

  • Add primary toggle to enable and disable push notifications
  • Add per notification type toggles
  • Add educational cell
  • Add edge case handling (permissions denied, subscription failed, API read/write calls for types toggles failed.

Why are we doing this?

As we begin to support contribution notifications through the iOS app, we need a place for contributors to opt into and out of specific notification types.

Feature job story

As an existing editor I need a way to opt into and out of notifications on my iOS device.

Designs

Figma: https://www.figma.com/file/cedgOU5CyOR0UVqtjDOvzE/iOS-Notifications?node-id=962%3A1899

Logged outLogged in - SettingsLogged in - Settings > Push Notifications (off)Logged in - Settings > Push Notifications (on)
image.png (812×375 px, 38 KB)
image.png (812×375 px, 36 KB)
image.png (812×375 px, 23 KB)
image.png (1×375 px, 87 KB)

Information architecture

  • No settings related to notifications are shown when a user is logged out
  • On log in there are two notifications related settings
    • Type subscription (shared with web) is available under Settings > Account > Notification subscriptions
    • Push notifications subscriptions are available under Settings > Push notifications

Error states

For error states please see https://phabricator.wikimedia.org/T288773

Dependencies

https://phabricator.wikimedia.org/T287305

Related

https://phabricator.wikimedia.org/T288773

Development Notes

Note: To keep track of device token subscription success/failure, I think we will need to keep a subscription boolean flag in UserDefaults.

  • 1. Show single primary toggle OFF if OS permissions have not been attempted and the subscription flag is false. Hide individual types toggles in this state.
  • 2. When toggled on, prompt for permissions and subscribe device token (subscription call work is already done in https://phabricator.wikimedia.org/T287305). Persist subscription success in UserDefaults flag. Note, we need to be prepared to wait for device token to come in after the user enables permissions. Some devices seem to set one immediately after registration in didFinishLaunching, and others seem to wait for permissions to be enabled first.
  • 3. When permissions and subscription succeeds in previous step, pull types preference flags from API (https://www.mediawiki.org/wiki/API:Userinfo). If that succeeds, show types toggles with ON/OFF states according to API. If that fails, show popup error (https://phabricator.wikimedia.org/T288773).
  • 4. When permissions from step 2 are denied, display cell that sends user to OS Settings. (https://phabricator.wikimedia.org/T288773).
  • 5. When screen is first pushed, check permissions, subscribed flag, and individual types preferences from the API and be sure UI reflects accordingly.
  • 6. When device is foregrounded, recheck permissions and update state accordingly in case they changed their permissions in the background.
  • 7. When toggling a type toggle: make write preference flags API call (https://www.mediawiki.org/wiki/API:Options). Because global preferences API stuff didn't pan out, we need to make this call for every app preferred language, plus wikidata and commons. If call to update fails, show error prompt and flip toggle back to previous state (https://phabricator.wikimedia.org/T288773)
  • 8. If the user adds new app preferred languages, make write preference flags API call on the new language wikis so they match preferences on old app languages. If this fails...try again later. No strong opinions from Product on when to try again later, consider other exponential back off methods in the app for this (reading lists, etc).
  • 9. Upon logout, behind the scenes unsubscribe device token from push.
  • 10. Privacy bonus: we could listen for their OS permissions (check on foreground), and proactively subscribe or unsubscribe their device token if permissions change to one of these states. (TBD on if this is a must, it adds many opportunities for bugs).

Other things to do:

  • 11. There's an explore feed card that could cause complications. Handle them here or break off into another task.
  • 12. Disable current news notification code for now, there is a separate task (https://phabricator.wikimedia.org/T287307) to add back in and test that it still works.
  • 13. Heavily test and optimize this screen for accessibility.
API Notes

To read notification preferences: https://www.mediawiki.org/wiki/API:Userinfo
To update notification preferences: https://www.mediawiki.org/wiki/API:Options

Notification Type > API associated value for reading and updating

Talk page message > echo-subscriptions-push-edit-user-talk
Thanks > echo-subscriptions-push-edit-thank
Talk page subscription > echo-subscriptions-push-dt-subscription
Translations > echo-subscriptions-push-cx
Mention > echo-subscriptions-push-mention
Failed mention > echo-subscriptions-push-mention-failure
Successful mention > echo-subscriptions-push-mention-success
Page link > echo-subscriptions-push-article-linked
Connection with Wikidata > echo-subscriptions-push-wikibase-action
Failed login attempts > echo-subscriptions-push-login-fail
Login from an unfamiliar device > echo-subscriptions-push-login-success
Page review > echo-subscriptions-push-page-review
User rights change > echo-subscriptions-push-user-rights
Edit revert > echo-subscriptions-push-reverted
Email from other user > echo-subscriptions-push-emailuser
Edit milestone > echo-subscriptions-push-thank-you-edit

Event Timeline

Just an FYI, this ticket might be a dupe of https://phabricator.wikimedia.org/T271855, which hasn't begun development yet. We can discuss in grooming which one we should work against, or if one is meant for design and the other development.

Thanks @Tsevener going to move this into 'blocked or waiting' for now

@JMinor should I make these changes: Keep push, remove subscriptions, add back in filters

I'm going to clean up the engineering portions of this task description to represent the requirements as I know them. Before I do this, here are the answers to the old task description questions:

[1] We need a primary toggle to enable and disable push notifications - e.g. "Enable Push Notifications"

There is now a Push Notifications toggle in the mocks.

[2] We need educational text to display that indicates the user needs to enable Notifications in iOS's Settings if the user has a. tried to toggle on Push Notifications and b. denied access to Notifications in the system prompt.

I don't see this educational text in the mocks, but there is a push denied state in Figma with an navigation arrow that I assume goes to OS Settings. @cmadeo let me know if that's right, it might be worthwhile to sync on this screen again just to make sure everything is squared away. (Edit: I see confirmation in https://phabricator.wikimedia.org/T288773. Thanks!)

Screen Shot 2021-09-09 at 1.12.20 PM.png (577×235 px, 21 KB)

[3] Are the notifications they are toggling here a. what they are opting in to see in the notification center b. what they are opting in to be pushed to their devices as push notifications (app column in Echo on web) or c. both?

My understanding is the latest ask from @JMinor is that we only have one toggle screen for push notification settings, the API details of which are listed in this task description. We will no longer have an Account > Notification subscriptions settings screen that toggles the desktop "web" checkbox preferences, thus affecting what they see or not see in the app notification center. If the user wants to change what is displayed to them in the notification center at a server-level, they will have to go to the web to change these. We may want to have some user education text for this in app notification center if it isn't there already.

Because we are moving away from tabs, we are bringing back local filtering of notification types. This is purely a local filter to allow the user to hide potential abuse.

[1] The UI needs API on the Notifications Data Controller to interact with here

The plan is for the data controller task to only be responsible for importing and refreshing notifications in the app center, and not deal with push preference settings. API for the overall push toggle (i.e. subscribing your device token to echo) has already been made in https://phabricator.wikimedia.org/T287305. The followup API calls are listed in the API Notes section of this task's description, to be called when toggling individual push types.

Note, because the global preferences API didn't work out, we will need to make this push type update API call for each app language they have set up, plus commons and wikidata.

Tsevener updated the task description. (Show Details)

I am moving this into Needs Design because we have a major remaining unknown before we can pick this up. Please look at my response to quote #3 in https://phabricator.wikimedia.org/T288688#7342910 @JMinor @cmadeo . If this information is correct, we will need from design:

  • Any mentions of Settings > Account > Notification subscriptions to be removed from this task and Figma. We will only have the Push Notifications Settings toggle screen now.
  • We should also remove the "Notifications Center - all "app notification center" types toggles are off, resulting in no notifications to see in notification center" edge case row from https://phabricator.wikimedia.org/T288773.
  • New mocks in Figma if a local notification types filter screen, similar to the project inbox and the read/unread/all local filter screens. We may want to create a new UI Phabricator task to represent this UI work too.
  • Maybe some education text in notification center explaining the user will need to go to the preference checkboxes in the web column on Desktop to control which notifications are downloaded from the server.

If I'm mistaken on the requirements, please ignore the bullet points :) Thanks!

@cmadeo @JMinor I also have a couple of minor questions in number 8 and 9 under "Development Notes" in the task description:

  1. If the user adds new app preferred languages, make write preference flags API call on the new language wikis so they match preferences on old app languages. If this fails...try again later (TBD)?
  2. Upon logout, behind the scenes unsubscribe device token from push. After logging back in, prompt them to turn push notifications back on. (TBD, need this prompt finalized by product/design). They will need to go back into Settings to resubscribe their device token.

Just need a little direction on these situations:

  • If they add a new language and attempting to update their preferences to match other languages (behind the scenes) fails. I imagine maybe this is a silent fail and we just try again later at some point.
  • We are supposed to unsubscribe their device token upon logout, so what happens when they log back in? Their "Push notifications" settings toggle will be off but they may not be aware, should we let them know?

Update from grooming -

  1. @JMinor 's original thought is to keep the Logged in - Settings > Subscriptions screen, but instead of having it hit the server to update the web column checkbox preferences, it simply serves as a local filter to keep certain notification types from appearing in Notification Center. The filter screens within Notification Center are meant more as fleeting tools to allow the users to more easily find certain notifications, but the Logged in - Settings > Subscriptions is meant more as a "hide forever" functionality for users that, say, never want to see Thanks. But under the hood they act the same, as a local filter. @cmadeo is going to finish up some thoughts around designing Logged in - Settings > Subscriptions as a filter screen, then we will discuss both options tomorrow in planning.

If they add a new language and attempting to update their preferences to match other languages (behind the scenes) fails. I imagine maybe this is a silent fail and we just try again later at some point.

No strong opinions of this from @JMinor , maybe to see where else we are doing progressive retry attempts (look at reading lists) and follow those patterns.

We are supposed to unsubscribe their device token upon logout, so what happens when they log back in? Their "Push notifications" settings toggle will be off but they may not be aware, should we let them know?

Any sort of keeping track of a username will be too gross and have privacy issues. The thoughts on this are that we do keep track if the device once successfully subscribed their device token to push (so just a simple UserDefaults success flag would work), we unsubscribe them upon log out, then check this flag upon log in. After checking this flag, present a modal (or integrate into existing login presentation modals) as a "heads up - you are now unsubscribed from push notifications, would you like to subscribe again?" with a button to send them to the Push Notification Settings screen (which should already be in a state with the Push Notifications parent toggle set to OFF), where they can flip the toggle again to resubscribe. @cmadeo will also look into this experience.

We are supposed to unsubscribe their device token upon logout, so what happens when they log back in? Their "Push notifications" settings toggle will be off but they may not be aware, should we let them know?

Any sort of keeping track of a username will be too gross and have privacy issues. The thoughts on this are that we do keep track if the device once successfully subscribed their device token to push (so just a simple UserDefaults success flag would work), we unsubscribe them upon log out, then check this flag upon log in. After checking this flag, present a modal (or integrate into existing login presentation modals) as a "heads up - you are now unsubscribed from push notifications, would you like to subscribe again?" with a button to send them to the Push Notification Settings screen (which should already be in a state with the Push Notifications parent toggle set to OFF), where they can flip the toggle again to resubscribe. @cmadeo will also look into this experience.

@cmadeo We just looked over https://phabricator.wikimedia.org/T287768 in engineering sync, and I think your flow "Contributor logs into app after having previously set notification settings in-app" on the Figma may have this covered. According to T287768 if the user logs out and logs back in again, they will see the push notifications prompt modal again when they visit Notifications Center, which should be enough of a heads up that they need to re-enable Push because they logged out. So I think we may be good here on the question quoted here, just letting you know.

@Tsevener sounds good. I also put some questions in Slack around this. For now I've updated the settings mocks to match the flow we discussed in the meeting today.

Hi @Tsevener I believe this is now ready for engineering, but please feel free to move back to needs design if I missed something!

@cmadeo made the tiniest of requests (just commented directly on Figma), but besides that looks great. Thanks for updating this! Moving this into Ready for Dev.

Updated! Thanks for catching that, @Tsevener