Page MenuHomePhabricator

Add affordance for accessing Notifications on the iOS app
Open, MediumPublic

Description

Why are we doing this?

We want to provide a way for logged in users to access notifications within the iOS app

What do we need to do?

Add affordance to top bar (“add bell”), what happens when there’s no explore feed, add toast behavior for when user is in article

Design proposals

Figma: https://www.figma.com/file/cedgOU5CyOR0UVqtjDOvzE/iOS-Notifications
Bell badging

Assets: https://phabricator.wikimedia.org/T288652

Explore feed with unread messagesExplore feed with NO unread messagesExplore feed off with unread messagesExplore feed off with NO unread messages
image.png (1×750 px, 177 KB)
image.png (1×750 px, 177 KB)
image.png (812×375 px, 36 KB)
image.png (812×375 px, 36 KB)
In-app notifications

Tapping on either notification style pushes user to the in-app notification center

System styleCustom style
image.png (1×750 px, 362 KB)
image.png (1×750 px, 325 KB)

Questions
  • If we utilize system notifications for in-app alerts when the bell icon is not visible, will users who have push notifications turned off be able to see these notifications?
  • If we utilize system notifications for in-app alerts when the bell icon is not visible, will users who have 'moon mode' turned on be able to see these notifications?
Dependencies

https://phabricator.wikimedia.org/T287310
https://phabricator.wikimedia.org/T288652
https://phabricator.wikimedia.org/T288669

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@cmadeo I tinkered with this a bit and here are my findings on notification receipt while the app is foregrounded:

  1. If the user has enabled push notifications in their settings, and allowed permissions, it's very easy to display the standard (with rich deep press) system notification view on top of the foregrounded app. We can also suppress this easily too.
  2. If the user has at one time enabled push in their settings, but allowed permissions and later revoked them, we are unable to display the standard system notification view on top of the foregrounded app. We do however, still get a callback when that push is received, so we can hook into that and display a custom banner if needed.
  3. If the user has never enabled push in their settings, and never allowed permissions, this means the device did not get registered with the service and we won't get that callback. In this case we may need to poll the notifications API regularly to determine if there are new notifications, and display a custom banner if we find anything.
LGoto triaged this task as Medium priority.Aug 2 2021, 6:36 PM
LGoto moved this task from Needs Triage to Product Backlog on the Wikipedia-iOS-App-Backlog board.

@cmadeo We have a request from engineering sync:

Case 3 from my comment above gets gross technically for us, because we would need to poll regularly to see when new data arrives in order to display custom banner on top of their foregrounded app if the user has never registered or given permissions for push notifications. Can we scrap handling this situation?

Case 2 is halfway gross but we at least wouldn't have to poll. I also want to float the idea of scrapping it too just so we don't have to consider a custom notification banner design. I think it can be argued that if a user denies push permissions, they also don't want to be interrupted while reading an article. But this case is still easier to implement than case 3 above if it's a must.

Case 1 is easy - users will get a notification (classic OS-style push UI) on top of their foregrounded app if they have enabled permissions.

Thanks!

@Tsevener just out of curiosity would it be easier to always show the in-app banner if the app is foregrounded?

@cmadeo unfortunately no - depending on how their permissions and registration is set, we may need to take extra steps to ensure we get the data to populate an in-app banner in certain cases. If they've never registered for push notifications or allowed permissions, we'll need to continually poll for new notifications. If theyve registered for push notifications but since disallowed their permissions, we'll need to design the custom UI for an in-app banner. Both are technically possible, just looking for areas that might not be a must for v1 to simplify. Happy to discuss or negotiate further!

@Tsevener certainly for v1, I'm happy to work with whatever is technically easier or more feasible!

cmadeo updated the task description. (Show Details)

Engineering sync notes:

I think the bell icon view and state will be handled in separate tasks, so the bell-related piece of this task description can be considered something for QA only.

Engineering can confirm the in-app notification view appears while foregrounded as a part of this task, and add the notification tap > deep link to Notifications Center routing to finish up this task as well.

@cmadeo one good point brought up in Engineering sync is how the user will route to Notification Center when tapping on the notification banner. Do we programmatically dismiss/pop all screens, select the first tab, then push on the Notification Center? They could lose their place which could be a lot of movement and annoying. But the alternative is pushing the notification center on top or from the right of wherever they are, which could be some really weird contexts (like the editing flow).

Great question @Tsevener could we try pushing from the right and having the back arrow lead back to where they were instead of the Explore feed?

Here are our options from task sync. This is what we could do when a user tap a notification that is happening on a foregrounded app, a backgrounded app that is navigated to a particular area, or a terminated app that has a particular navigation state restoration ready to be restored:

  1. No matter where in the flow things are, notification center is pushed on from the right and back button will be updated to reflect where it was pushed from. It is understood that this could interrupt flows like editing.
  2. No matter where in the flow things are, notification center is presented on top of wherever the user currently is, and will instead have a close modal button. It is understood that this could lead to presentations on top of presentations (settings is already a modal, editing flow is already a modal, media and link wizards within editing flow are already modals on top of modals).
  3. We do a hybrid of 1 and 2, where we dismiss any modals the user has presenting (i.e. editing flow, settings), but then push on notification center from the right on top of whatever navigation stack is underneath. Back button will be updated to reflect where it was pushed from.
  4. We go nuclear and dismiss all modals and pop any navigation stack underneath to root. We programmatically select the Explore tab, then push on the notification center from the right. It is understood that the user would lose their place.

I think the priority of things to try is 2, 3, 4, then 1. We aren't sure what will work best right now so we'll just have to explore how these go when we pick this ticket up.

@JMinor @Dmantena @cmadeo please let me know if I'm misremembering anything here, thanks!

Looks accurate to our sync. thanks for the writeup!