Page MenuHomePhabricator

cross-wiki notification: bundled notifications are not counted
Closed, ResolvedPublic

Description

To check two scenarios of incorrect count in bundled notifications.
First:

  1. The actual count of bundled notifications is correctly displayed.

  1. Click on the Notifications icon - the flyout panel opens, the count changes to 1.

  1. Refresh the page - the count of bundled notifications returns to the correct one.

Second scenario - marking some of the bundled notifications as Read does not change the internal bundle count.

  1. Have several notifications from another wiki in your Notifications panel - click on the flyout.
  1. The cross-wiki counter will correctly display the actual number of messages in 'Expand [number] of messages'.

3.Click on Expand and mark some of the cross-wiki messages as Read - by clicking on the X button.

  1. Click 'Collapse all' - the cross-wiki counter still displays the previous number of messages.

Details

Related Gerrit Patches:
mediawiki/extensions/Echo : masterInclude cross-wiki notifications in unread count

Event Timeline

Etonkovidova raised the priority of this task from to Needs Triage.
Etonkovidova updated the task description. (Show Details)
Etonkovidova added a subscriber: Etonkovidova.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 19 2016, 10:57 PM

Bundled notifications shouldn't be counted in the badge -- that is, the badge should recognize it has an extra (+1) notification that is the cross-wiki one, but it shouldn't display the number of sub-notifications that that bundle holds.

For example, if I have 10 unread notifications locally, and a bundle with 5 unread from wiki1, 2 unread from wiki2, and 1 unread from wiki3, the badge should have the number 11, and not 19.

What we do have as a bug here is that the nojs-version produced by the backend *does* count the sub-notifications, which is inconsistent with the frontend JS ui which doesn't, which is why the badge doesn't represent the number correctly when the page just loads AND why the badge number changes when you open the popup (because it's replaced by the JS version)

I personally think we should stick with the way the UI works (counting cross-wiki as *one* notifications) but either way, since the backend and frontend behave differently, we should make a decision and then make sure both act the same.

@Catrope, @jmatazzoni, @Pginer-WMF -- your input is welcome.

For example, if I have 10 unread notifications locally, and a bundle with 5 unread from wiki1, 2 unread from wiki2, and 1 unread from wiki3, the badge should have the number 11, and not 19.

The cross-wiki bundle is just a group of notifications, I don't think we should count it as one.
I think there are two ways of counting that can meet the use expectations:

  • Count all notifications. If we consider that the panel now gives us access to notifications from all sites, we can assume the counter indicates all the pending notifications, regardless of their origin. In your example, the counter would be 19.
  • Count only local notifications. In your example, the counter would be 10. The problem with this is that getting new notifications on other wikis may result in a highlighted "0" badge, which may be confusing (keeping it as "1" has similar problems).

Since the goal of cross-wiki notifications is to give more visibility to what is going on elsewhere, I'm more inclined to go with the first approach and keep the count global and consistent on all wikis. In theory, having a global counter can lead to higher numbers (making them less relevant), but we need to check how often users end up with lots of unread notifications from different wikis (and how different would be to count them separately in that case).

It's clear that the behavior of x-wiki notifications puts them in a somewhat ambiguous status. These messages both are and, in some ways, are not "in" the current panel. So I could see this going (and us getting complaints) either way.

However, for many of the same reasons Pau sites above, I'm inclined to say that the counter should count everything that is in the panel, including notifications from other wikis. I think that behavior will be more clear and consistent -- though, as I say, I fully expect there will be some who would not wish it.

I see a couple of minor issues here:

  • Occasionally, a small number of people will see "99" as their number when they actually have more messages. 99 is, if I have this right, the highest number the badges are able to show. Would we want to increase the limit to 999? If we did, would the design accommodate it?
  • I foresee that some people may wish to turn off x-wiki in some wikis. This would probably be the case whatever the numbering, but the numbering may make it more pressing. Since that behavior is more or less possible now via the beta opt-in, tracking the need for it during beta will be difficult....

Occasionally, a small number of people will see "99" as their number when they actually have more messages. 99 is, if I have this right, the highest number the badges are able to show. Would we want to increase the limit to 999? If we did, would the design accommodate it?

It makes sense to avoid stating "99" translations when you have more than that. However, I'm not sure the precision past that point matters much (i.e, having 99 or 123 pending notifications is just "a lot"). I'd propose the counter to be "99+" once the user has more than 99 notifications.

According to our recent data about notifications, there are 12 users with more than 100 alerts, and 43 users with more than 100 messages (curiously, the numbers are much higher for those having exactly 100)

I foresee that some people may wish to turn off x-wiki in some wikis. This would probably be the case whatever the numbering, but the numbering may make it more pressing. Since that behavior is more or less possible now via the beta opt-in, tracking the need for it during beta will be difficult....

That is a valid concern. However, I think beta-features will still be helpful: if a user enables the feature to notice that (a) it is useful to view notifications from other sites, but (b) the counter went up so much that is distracting, we will easily hear about the later. Research with users making use of the feature on their real notifications will be helpful to surface these issues.

Also, based on the previous data, most users don't seem to have pending notifications from many different wikis at a time. Thus, the total number of notifications may not be much higher than the one of their busiest wiki.

I like the idea of 99+ as well. Thanks Pau.

Do we have a decision that 1) all notifications should be counted and 2) the counter will stop at 99+?

Yes, let's go with that decision.

SBisson claimed this task.Feb 18 2016, 1:14 PM
SBisson triaged this task as Medium priority.

Change 271690 had a related patch set uploaded (by Sbisson):
[WIP] Include cross-wiki notifications in unread count

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

Change 271690 merged by jenkins-bot:
Include cross-wiki notifications in unread count

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

Etonkovidova added a comment.EditedMar 1 2016, 10:12 PM

Checked the fix in betalabs (for both scenarios)

  • all unread messages are counted; refreshing does not return the count to the previous count (checked the first scenario)
  • deleting some of the bundled notifications is reflected immediately and correctly in the counter
  • turning 'Enhanced notifications' beta feature ON/OFF does not cause the counter to make mistakes.

Closing this bug. However, Elena is going to find a way to try out the 99+ feature and will reopen if that's a problem.

jmatazzoni closed this task as Resolved.Mar 2 2016, 12:04 AM