@cmadeo @JMinor Per sync, here’s my attempt to better articulate my design questions. Please call out any assumptions I made that are incorrect.

Edit: Ha, dunno what's up with the thumbnail not rendering correctly, but here's a direct link: https://phab.wmfusercontent.org/file/data/kz2q2xgnfahc6ctrwpri/PHID-FILE-jpndonh5nrwg6ta54agl/NotificationsCenterMarkAsRead.png

Thanks @Dmantena! This is super helpful and I'll share some notes and thoughts below:

• Totally understand how/why we'll need paging (technically) for the table. My preference would be for this to not be visible to the user outside of loading states. I've put together a ticket for defining loading behavior in the table for paginated results https://phabricator.wikimedia.org/T288835
• Apologies if this is over simplifying, but it sounds like a lot of our complications re 'Heavy' users could be resolved by removing the 'select all' option in the editing view. With this in mind I think we have the following options:
  • Remove 'Select all' and replace with individual selection
  • Remove 'Select all' and replace with individual selection and a more 'nuclear' option of 'Marking all as read' which is supported by the API. In this scenario, it's still theoretically possible that someone could 'Mark as read' a notification they haven't yet seen in their inbox because it was inbound while they were taking the action. Personally this feels like enough of an edge case that I would rather not prevent folks for whom getting to 'inbox zero' is important from getting a tool for quick selection over this scenario, which let's hope is a pretty rare case and is possible to recover from by going to your 'read' messages.
  • Do the same thing that Apple Mail does (you can check this out by going to Mail > All Mail and then opening the edit menu and tapping on the option to 'select all') Apple mail selects all of the loaded messages, but if you scroll down / take action you'll see that un-loaded messages are unselected. This means that to clear out a big inbox you'd need to: tap select all > tap mark as read > wait for messages to load > rinse and repeat until the inbox is empty. It's not the worst thing, but certainly not the simplest solution for someone who has a lot of messages.

I don't actually have a strong preference between the later two options, so I'm happy to defer to @JMinor or eng!

We are going to move forward with #2 (Mark all as read)
This means that we will have three options available: Mark as read, mark as unread and mark all as read -- we'll want to confirm before actually marking all as read.

Data side of this work is in https://github.com/wikimedia/wikipedia-ios/pull/4069.

Prototype UI work is in notifications-usertesting branch, but it likely needs to be cleaned up before putting into a PR.

This is ready for design review. There are a couple of workarounds we had to do that you should know about:

1. For iOS13, we weren't able to display a contextual menu from a toolbar button. So we went with an action sheet instead only for iOS13. We are displaying the contextual menu for iOS14 & 15. This difference comes into play after selecting Edit, choosing cells, then tapping "Mark".

iOS13 screenshot

2. To get the count when displaying the text "Are you sure you want to mark all X messages of your notifications as read?" - I was unable to pull a server-side count without some difficulty keeping it in sync with all the local actions that the user was taking, so instead we're just calculating a local count of notifications. BUT we are still calling the nuclear "Mark all as read" API call to the server which marks everything as read. We refresh pretty often so it's likely our local count is close, but it might not be exactly what the server will mark as read. Just letting you know. If accuracy of this count is important, we might want to remove the count from the text.

Looks great! Thanks all!

Looks good to me on 6.9.0 (1882)