Page MenuHomePhabricator

Echo's 'seen time' should be replaced with marking specific notifications as seen
Closed, DeclinedPublic


Right now, we're marking 'seen' notifications according to a timestamp of when the user last looked at their list. However, this is potentially very problematic.

For one, if a user has 100 notifications, their list will only show 25 or so - but the 'seen' timestamp will be updated to the moment they opened their notification popup - which will make all 100 notifications "seen", instead of just the 25 the user has actually seen. When the user then goes to Special:Notifications, all items are seen including the 75 that the user really hadn't seen before.

This is a wrong behavior. We should really make 'seen' a flag, like 'read' is, and mark notifications as seen specifically when the user actually sees them.

Event Timeline

Mooeypoo created this task.Aug 28 2015, 8:19 PM
Mooeypoo raised the priority of this task from to Needs Triage.
Mooeypoo updated the task description. (Show Details)
Mooeypoo added a subscriber: Mooeypoo.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 28 2015, 8:19 PM
Mooeypoo set Security to None.
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptAug 28 2015, 8:19 PM
Catrope triaged this task as Normal priority.Sep 2 2015, 11:27 PM
Catrope added a subscriber: Catrope.

Follow-up from discussion: Should we use a persistent cache (never falls out of cache), or a cache that can expire? This is related to whether we need a DB index on seen-ness.

In T110731#2306088, @Mattflaschen wrote:

Follow-up from discussion: Should we use a persistent cache (never falls out of cache), or a cache that can expire? This is related to whether we need a DB index on seen-ness.

I think the most straightforward approach would be to use MainStash, which is persistent.

What is the behavior that we want from the user's perspective?

Pginer-WMF added a comment.EditedJun 30 2016, 10:12 AM

The highlight provides a visual cue on which are the new notifications among those that are unread. When the badge becomes blue/red it indicates that there is something new, and when opening the notification panel a brief highlight allows to understand which of the unread notifications are new.

The highlight on the badge and the highlight on new notifications work in sync since they refer to the same items (the new notifications). So I'd not keep the badge or the notifications highlighted for later once the panel is open, even if some of the new notifications didn't fit there. Highlighting notifications at the bottom of the panel as they apear into the view without being new may create more confusion than help.

If all the new notifications do not fit in the panel, the badge should still change from blue to grey, and all the visible items will show the highlight. That will already communicate that there may be new items beyond the panel and you want to check "all notifications".

Despite the use of the terms "seen" and "unseen", we are not keeping as unseen the new notifications that the user may not actually see in the panel if she decides not to scroll. So I'd think of it less of a literal "seen" and more like the propagation of the badge highlight to communicate what that means regardless on whether all affected items enter the viewport or not.

Catrope closed this task as Declined.Apr 18 2017, 5:46 PM

We decided to stay with timestamp-based seen-ness, and made some improvements (including a global timestamp) to make it work better.