Page MenuHomePhabricator

As a contributor I want granular control over my push notifications
Open, Stalled, LowPublic

Assigned To
None
Authored By
cmadeo
Feb 17 2022, 8:26 PM
Referenced Files
F35002394: image.png
Mar 11 2022, 6:25 PM
F34620044: image.png
Feb 17 2022, 8:26 PM
F34620042: image.png
Feb 17 2022, 8:26 PM
F34620039: image.png
Feb 17 2022, 8:26 PM

Description

NOTE: This ticket needs to be updated after the longitudinal study is complete in order to represent user preferences

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.

Findings from Diary study

2 of 5 participants requested different ways to triage their push notifications or have granular control over their push notifications by type (eg. to only receive pushes for urgent or important types).

Quotes from Diary study

  • It would be nice to have push notifications for important things: cancelled edits, for new message, for mentioning my username in talk pages, and to have usual notifications for page links, as an editor with more than 10,000 created articles, these notifications for me are very often.
  • It would be great to have an extra tag in the push notifications, like a symbol or a word, for example [thanked]. So that we don't need to unblock the phone if the push is not very relevant, even if we keep it activated to act as a push.

Designs

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

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, 104 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

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
Cross wiki summary preferences > echo-cross-wiki-notifications

Event Timeline

@cmadeo @JMinor It sounds like no UI is going to change for this one, so we were just hoping for one last green light on the comment I mentioned here: https://phabricator.wikimedia.org/T288688#7698816. Please let us know if it's okay to base the initial toggle state on their primary language preference on the server, and when the user toggles them we will write the new preference to all of their local notification wikis (be it an app language or another project).

Yes, that is the plan. The read is based on primary language, the writes will be to all languages the local inbox contains.

@JMinor As discussed, here are a couple of unavoidable buggy-feeling scenarios that granular pushes introduces, due to a lack of global preferences.

Scenario 1

  1. User decides they don't like Thanks notifications, user turns off only Thanks type in Notifications Settings
  2. Under the hood, we construct a list of projects to receive the "turn off thanks" API call (app languages + commons, wikidata, + any other project that has a notification locally on device), we make the call to turn off the thanks push type at all these projects.
  3. Later, some other project that wasn't a part of the list in step 3 (a non-app language, for example) generates a thanks notification. User STILL sees push because they never turned it off for this new project in step 2.
  4. User visits Settings to be sure Thanks is off. Thanks displays as off, because that toggle state only represents the app's primary language.

Scenario 2

  1. User has one primary language and one secondary language in the app. They successfully turn off Thanks notifications for these two languages.
  2. User deletes secondary language.
  3. User decides they want Thanks again, and turn on Thanks via settings. This turns it on only for the primary language.
  4. User later adds secondary language again to the app.
  5. After a while, user notices that they aren't getting secondary language thanks pushes. User goes to Notifications Settings. Thanks appears toggled on - because that state is only based on their primary language.

As for level of effort - we estimate this one will take us about 3 weeks from the time we begin development to the time we merge. This is mainly due to API complexity and the fact that it takes a network call, which leads us to need loading states and failure states.

LGoto lowered the priority of this task from Medium to Low.Apr 7 2022, 7:39 PM
JMinor changed the task status from Open to Stalled.Apr 7 2022, 8:56 PM

Thanks @Tsevener per our sync today, given the LOE an "leaks" you've identified, we'll pause this before moving to final implementation. If we get concerns from beta testers about being overwhelmed by irrelevant or low value push types, we'll re-animate this ticket and get into the buggy-looking scenarios.