Also, after marking all messages as read, it goes instantaneously to zero, but on page reload it increases to 27 again. A second click on mark all as read, followed by a new page reload, makes it 13. A new click+reload finally changes it to zero.

Maybe slave lag?

Does ChronologyProtector cover the shared DB used by UnreadWikis?

Change 277609 had a related patch set uploaded (by Sbisson):
[WIP] Stop counting notifications objects on the client

https://gerrit.wikimedia.org/r/277609

Change 278340 had a related patch set uploaded (by Sbisson):
Use UnreadNotificationCounter to count notifications

https://gerrit.wikimedia.org/r/278340

Change 277609 merged by jenkins-bot:
Stop counting notifications objects on the client

https://gerrit.wikimedia.org/r/277609

Change 278340 merged by jenkins-bot:
Use UnreadNotificationCounter to count notifications

https://gerrit.wikimedia.org/r/278340

Checked in betalabs - the counter correctly displays the number of messages after marking 1 (or more as read) or after marking them as unread.

Note: If there are more than 25 unread messages, 'Mark all as read' option will mark only first 25 as read. Others will be displayed as unread. Presently, it's the expected behavior.

I discussed this behavior with Elena:

Checked in betalabs - the counter correctly displays the number of messages after marking 1 (or more as read) or after marking them as unread.
Note: If there are more than 25 unread messages, 'Mark all as read' option will mark only first 25 as read. Others will be displayed as unread. Presently, it's the expected behavior.

In other words, if you have 99+ unread and "Mark all as read" in the panel, you'll still have 99+ in the counter (Elena says the counter no longer drops to 0 and then back up again when you close the panel, as it used to do). So I'd say that this behavior isn't wrong. But it is potentially confusing.

I thought about changing the language of the command, maybe using the wording from the new Notifications Page, where we say "Mark group as read," to indicate that it's just this group of up to 25 visible messages. But on the special page, there is a clearly defined group (of one day). Whereas here the meaning of "group" would be a little unclear. And we can't say "Mark visible as read," since they may not all in fact be visible on the screen. And "Mark up to the first 25 as unread" is just weird. So if there's a language change that can illuminate this slightly unusual behavior, it's not coming to me.

So, as I say, the behavior isn't wrong, by the standards of our system. But before I close this, does anyone have an idea for making it less mysterious? @Pginer-WMF ?

I thought about changing the language of the command

One of the risks here is that we may be adding complexity for the common case (users with less than 25 unread notifications) to support the edge case (users with more than 25 unread notifications). I thought on some possible directions that try not to make things complex for most of the users while helping those with a high number of notifications. In order of preference:

Mark all local notifications as read, even those not shown in the panel

I'd like to identify which is the most likely intent of a user with more than 100 notifications that clicks on "mark all as read". I think the intent is to get a "blank slate", and the most useful action is to mark all local notifications as read, even those not previewed in the panel.

The potential problems with the approach seem to be that a user with more than 25 unread notifications may not understand that the panel acts as a preview showing some notifications but representing the wider group of notifications.

I don't have much information to think this is a big concern, but if we are really worried, we can add a confirmation step only for those users with more than 25 notifications: "This will mark 123 notifications as read. Are you sure?". This helps to communicate the reach of the action when it may be wider than expected.

This introduces some friction but since it is only shown when acting on a big number of items, it may be well accepted as a reasonable pause for thought by the user. If we wanted to make the experience more fluent, we can mark all notifications as read without interruption and provide an information message afterwards, with an option to undo ("123 notifications were marked as read. [Undo]"). Only when the action affects a big number of notifications.

Show all unread notifications in the panel

If we showed all unread notifications in the panel there will be no problem on which notifications may be marked, since all of them will be in the panel.

To avoid technical limitations, unread notifications can be lazy loaded (e.g., using infinite scroll). In this way, users would be able to view all the items that will get affected by the "mark all as read" action if they want to.

If we load all unread notifications it would be good to also include one or two read notifications at the end of the list to convey the idea that the user really reached the end of the unread ones.

Mark only those notifications in the panel as read, and clarify the scope of the action

If we want to clarify that the action scope is only for the items in the panel, I think we should only do it when it is relevant. One way to achieve this is:

• For users with less than 25 notifications, show the usual "mark all as read" action.
• For users with more than 25 notifications, show the action as "mark 25 as read". When applying the action we can adjust the transition to better communicate the mental model (i.e., show how a new set of unread notifications is replacing the previous one).

This exposes an arbitrary technical limitation to the users, so it may still produce some confusion (why 25?) since the group does not correspond to a relevant criteria for the user.