I agree on most of what has been discussed. I think we need to reduce the sense of urgency once you are already aware of a notification (even if you didn't read it), but I'm a bit concerned on reseting the counter to zero and adding another persistent indicator to distinguish unseen notifications from unread ones.

I'd consider the following model:

• Unseen notifications. If there are notifications the user is not aware of, the notification batch turns red. Once the user clicks the badge to open the panel, all notifications are considered seen and the badge turns grey. To distinguish unseen notifications from unread ones, the unseen notifications appear highlighted for a second after the panel is opened. A more persistent mechanism is not considered to avoid adding clutter and because new notifications are expected to appear at the top of the list.
• Unread notifications. Notifications not opened by the user get reflected in the counter of the notification batch. Once the panel is open, they are shown in the panel with a white background to distinguish them from read notifications.

Possible adjustments

If we want to make pending notifications even less prominent, we can decide to make the batch count only unseen notifications, but in that case I'd replace the counter by a generic message icon instead of displaying "0". Notification systems with a counter for the recent notifications (e.g., Facebook or Google+) hide the counter when there are no recent notifications (showing a generic element such as a message icon or a bell instead of a "0" count that may give the impression of not having notifications at all).

If we want to solve the problem of very old notifications remaining unread, but users unwilling to clear all notifications (to avoid getting rid of the recent ones), we can group old notifications and provide ways to act on all of them at once:

@Pginer-WMF Awesome. I really like this solution, and especially the clear model-diagram. Thanks :)

For our future brainstorming:
I just wanted to check that you'd seen this other idea, (it's using the wrong colors and icons, but it was all he had access to at the time. You can get the general idea :) at https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Archive_5#Granularity (on here as T58476)

There's also the second idea, of changing badge-color based on the notification-type, described at T57359.

I know we've discussed separating "Alerts" from "Messages" as part of the compact/personal-toolbar brainstorming, and had punted that for future discussion. I just wanted to make sure you'd seen these other ideas, for any changes we plan in future months/years.

I updated the ticket with Pau's new ideas & mockups. There are two parts -- turning the red bubble gray, and adding the highlight flash for new notifications.

We'll need more details on the highlight appearing and then fading. (Do we have that functionality somewhere else?)

We'll need more details on the highlight appearing and then fading. (Do we have that functionality somewhere else?)

To align with the design guidelines, the recommendation for the design team was to apply the highlight to the whole notification element, as illustrated below:

I created a prototype and a video illustrating it in action. Note that the prototype is very limited and only supports the interaction shown in the video. Supporting the animation should not be very hard with CSS transitions.

I just wanted to make sure you'd seen these other ideas, for any changes we plan in future months/years.

Thanks @Quiddity. These ideas are definitely worth exploring. If we consider improving the notification system a priority to focus on, it would be great to do some design iterations to identify the current issues and try several approaches to solve them.

This looks great, and I love having a video. :) I updated the requirements at the top.

There's an ongoing discussion somewhat related to this, at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Soften_the_notification_number

@Quiddity, should we let them know that this change is coming soon?

In T94634#1222269, @DannyH wrote:

@Quiddity, should we let them know that this change is coming soon?

Now done. https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&diff=657381775&oldid=657379357

This is not just a visual change, it sounds like we would need to introduce a new "seen" state in between "new" and "read".

This is not just a visual change, it sounds like we would need to introduce a new "seen" state in between "new" and "read".

When we discussed the idea we were thinking that the "seen" state is more a property of the notification panel ("there are new notifications you are not aware yet) rather than a state of individual notifications (as "new" or "read" are). For example, you can keep track of the last moment in time where the panel was open and highlight whichever notifications are more recent than that.

We also considered that all the above is independent from the panel viewport and scrolling. That is, if I receive 100 new notifications but only 10 are visible in the panel at a time, once I open the panel all notifications are considere as "seen". The user will be able to keep scrolling and the chronological nature of the notification list will be enough to identify the recent ones.

Yes, we think it can be implemented with a per-user "last open time". Then, "unseen" notifications (the ones that keep it red) are those that came in after the last open time.

Ooh, that's clever, that reduces the amount of state we have to track quite a lot.

Change 207429 had a related patch set uploaded (by Matthias Mullie):
Display red badge based on time of notifications vs last time panel was opened

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

Change 207429 merged by jenkins-bot:
Display red badge based on time of notifications vs last time panel was opened

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

This isn't working correctly on Beta.

• I've got 0 new messages, and I'm subscribed to a lot of threads on Talk:Flow
• Sockpuppet replies to thread #1
• I go to a random page, and the new notification takes three page loads before the number changes to 1 (incorrect, should update on next page load)
• When it updates, I have gray 1 badge (incorrect, should be red 1)
• Sockpuppet replies to thread #2
• I go to a random page, and I see red 2 badge (correct)
• I open the Echo panel, and both notifications flash blue (correct)
• Now I have gray 2 badge (correct)
• Sockpuppet replies to thread #3
• Still gray 2 badge for multiple page loads (incorrect, should update on next page load)
• Sockpuppet replies to thread #4
• On next page load, I have red 4 badge (correct)
• Sockpuppet replies to thread #5
• Multiple page loads, still red 4 badge (incorrect, should be red 5 on next page load)
• Sockpuppet replies to thread #6
• On next page load, becomes red 5 badge (incorrect, should be red 6)
• Sockpuppet replies to thread #7
• On next page load, becomes red 7 badge (correct)

So it's inconsistent. I'm trying to find a pattern -- maybe the length of time? maybe the kind of page I visit? but I couldn't find one yet.

There's code that clears caches when new notifications have been added. This new stuff now also uses that.
I'm guessing that that stuff is fired in a job (or the notification itself it only added via a job) & it takes some time/some page requests (not sure how it's been set up on beta) for those jobs to be fired.

That's just a guess right now - I'll look into it tomorrow. Could be another issue.

Change 209189 had a related patch set uploaded (by Matthias Mullie):
Until seentime is recorded, we should treat notifications as unseen

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

The badge count updates are indeed just slightly delayed, as they've always been.

However, the initial grey badge is caused by these changes. Until you've opened the notifications panel a first time after this change, the "last opened" time would never have been recorded. Since we don't have a time to rely on, I made it show grey by default.
I now see that it makes more sense to keep the badge red until the notifications panel is opened & that time is stored (so until then, it just stays red, as it currently does)
I submitted a trivial new patch to change this.

Change 209189 merged by jenkins-bot:
Until seentime is recorded, we should treat notifications as unseen

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

This was on Roadmap for last week, update?

In T94634#1266845, @greg wrote:

This was on Roadmap for last week, update?

This feature, including the patch for fix the glitch Danny reported, made it into wmf5

released, with the fix it works great! :)