Page MenuHomePhabricator

Handle tap through of native notifications shown while app is open
Closed, ResolvedPublic

Assigned To
Authored By
Jul 28 2021, 6:58 PM
Referenced Files
F35023725: Screen Shot 2022-03-25 at 9.53.37 AM.png
Mar 25 2022, 3:07 PM
F34970365: IMG_0607.PNG
Feb 28 2022, 8:31 PM
F34970374: IMG_0609.PNG
Feb 28 2022, 8:31 PM
F34597604: image.png
Aug 16 2021, 3:46 PM
F34597610: image.png
Aug 16 2021, 3:46 PM
F34597606: image.png
Aug 16 2021, 3:46 PM
F34597608: image.png
Aug 16 2021, 3:46 PM
F34597668: image.png
Aug 16 2021, 3:46 PM


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

Bell badging


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)

  • 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?

Testing Notes for QA

To test, we need to confirm that:

  • Push notifications appear on top of the app while app is foregrounded (if they have enabled push notifications via app Settings).
  • The user can tap a push notification when the app is in these 3 states. Confirm the following happens in each state:

When app is in foreground and background

  • If the navigation hierarchy is set up so that the app IS NOT presenting modals (that is, any screen that animates up from the bottom, like Settings), Notifications Center simply pushes on from the right. The user can then tap Back to get to where they were before. For example, user Taps Explore > Featured Article > Push notification appears and user taps > Notifications Center pushes on from the right > User can then tap Back to go back to the Featured Article.
  • If the navigation hierarchy is set up so that the app IS presenting modals (like Settings), the modals are first automatically dismissed, then Notifications Center is pushed on from the right.
  • If the navigation hierarchy is set up so that the app IS presenting modals, AND that modal is showing some sort of editor (say, our wikitext section editor, article description editor, or user talk new topic or reply screens), we first show an editor confirmation alert to confirm the user is okay with losing their changes. If they tap cancel, nothing happens, the user isn't navigated out of editor. If the user taps "Discard Edits", the modals are then dismissed, then Notifications Center is pushed on from the right.

Screen Shot 2022-03-25 at 9.53.37 AM.png (998×534 px, 265 KB)

When app is terminated and not in memory

  • When the user taps a push notification while the app is terminated, the user is brought straight to Notifications Center when the app launches.

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.


@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!

JMinor renamed this task from Add affordance for accessing Notifications on the iOS app to Handle tap through of native notifications shown while app is open.Nov 9 2021, 7:42 PM
JMinor lowered the priority of this task from Medium to Low.

Going to explore this a bit and will push out an Experimental build for product and design to play with. I'll move it back into Needs Acceptance Criteria after that.

@JMinor @cmadeo @OTichonova I pushed a new Experimental build (black icon) with some prototype options on this.

  1. Fresh install build
  2. Log in if necessary
  3. Go to Settings > Notifications > Enable push permissions
  4. Go to Settings > Push notifications tap debug

These are the different options we have set up. Hopefully the cell descriptions are explanatory enough, but let me know if you have any questions. The gray background color indicates which option is selected.

IMG_0607.PNG (1×750 px, 167 KB)

To trigger a fake push notification, shake the device from anywhere in the app. You should see a notification appear on the foreground (unless you chose one of the options that suppresses it in the Editor flow), tap to navigate to Notifications Center.

IMG_0609.PNG (1×750 px, 1 MB)

Note: sometimes when you shake, the Apple OS will pop up a "Undo Typing" alert when you're editing text. This is just an unfortunate side effect of hooking into the shake gesture. I suggest tapping cancel to get rid of it before tapping the local notification.

Thanks @Tsevener! This is SO HELPFUL! I'm really curious about the technical complexities of each of these, specifically curious about Option 1 with the editor opened, would we be able to detect if the editor was already open in the stack and then show the alert? I'm just a bit curious about what might happen if someone goes to answer a notification and then sort of forgets that they're already in an editing flow -- otherwise the simplicity of tapping 'back' to get to where you were before the notification 'interruption' seems intuitive and easy to use.

(Extra comment for more thank you's! This is really helpful and I appreciate your making it so easy to play around with!)

@cmadeo yep, we could detect if the editor is already open and show an alert for Option 1 before pushing, like how we did for options 3 & 4. I didn't demo that because, since we're pushing it on from the right, they wouldn't actually lose their editing changes. They should be able to tap back and get back to the Editor, so this particular alert with how it's worded isn't necessary. But preserving the editing flow (as we do in Options 1 & 2) can get them into some wacky setups (for example, they're in Editor > Media Wizard, are pushed to Notifications Center, that pushes them to an article, then they tap Edit again and another Editor is presented, etc).

I think the most technically stable options would be to dismiss any modals that are currently presenting to avoid that situation, which is why I tried to offer the most variations on 3 & 4 - to give users a heads up that their editing changes will be lost because we're dismissing.

Per the sync meeting, we'll pursue option 5, have Anthony test some of the "messier" paths and see if that is sufficient.

@cmadeo @JMinor sounds good, I'll start on option 5. Is there specific wording that you would like for the Editor flow alert?

@Tsevener could we use the following alert text:

Header: Dismiss the editing mode?
Body: Are you sure you want to leave editing mode without publishing first?
Button (cancel): Cancel
Button (destructive): Discard edits

Also thinking we might want to show this if a contributor has entered new text in the editor and then taps on the 'x' to dismiss the editor! < @JMinor

@cmadeo that looks good! I forgot to mention, I'm also going to use this alert on the article description editor screen - is it okay if I use the same copy there?

Perfect to use it there too! Thank you!

@cmadeo since y'all already saw an example of this in action via a prototype build, I'm moving this straight to QA. I added a screenshot of the new alert view in the Testing Notes for QA section of the task description. Feel free to move this to Needs Design Review if you want another look though.

JMinor claimed this task.