Page MenuHomePhabricator

A1. Quieter Echo notifications for Flow posts
Closed, ResolvedPublic2 Estimated Story Points

Description

The user has new Echo notifications about Flow threads.

When the user opens the notifications panel, turn the bubble from red to gray, to indicate that the user has now seen the notifications.

Everything else about the read/unread state should stay the same as current functionality. See mockup below.

When the user opens the notifications panel, there is a highlight on the items that are new since the last time the panel was opened. The blue highlight should appear and then fade, as seen in the mockup below.

Pau made a video showing how the highlight should work: https://www.youtube.com/watch?v=1u3M3qZ8N8s

Rationale:
Active users have said that getting individual Echo notifications for every active conversation makes them feel overwhelmed. If you don't want to look at every thread that you've got a notification for, then you either have to mark them all as read, open them in different tabs for later use, or just live with a red notification bubble. Leaving the red notification bubble promotes notification-blindness, and makes it less likely that users will actually pay attention to new notifications.


See also:

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
DannyH raised the priority of this task from to Medium.Mar 31 2015, 10:45 PM
DannyH updated the task description. (Show Details)
DannyH moved this task to Team discussion on the Collaboration-Team-Triage board.
DannyH added subscribers: DannyH, Pginer-WMF.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 31 2015, 10:45 PM
Mattflaschen-WMF set Security to None.

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:

Quiddity added a subscriber: Quiddity.EditedApr 2 2015, 6:07 PM

@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.

DannyH renamed this task from When the user opens the Notifications Messages panel, reset the number in the red bubble, but keep the read/unread state as is. Includes a "new" symbol for new unread notifications. to Quieter Echo notifications for Flow posts.Apr 2 2015, 9:42 PM
DannyH updated the task description. (Show Details)
DannyH updated the task description. (Show Details)Apr 2 2015, 9:44 PM

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?)

Restricted Application added a project: Notice. · View Herald TranscriptApr 2 2015, 9:47 PM
DannyH moved this task from Unscheduled to April 27-May 1 on the Roadmap board.Apr 2 2015, 9:48 PM
gpaumier moved this task from Backlog to Triaged on the Notice board.Apr 3 2015, 8:41 PM
gpaumier moved this task from Triaged to Archive on the Notice board.Apr 9 2015, 5:44 PM
DannyH edited a custom field.Apr 13 2015, 6:38 PM

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.

DannyH updated the task description. (Show Details)Apr 15 2015, 5:00 PM

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

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

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptApr 22 2015, 7:09 PM
DannyH renamed this task from Quieter Echo notifications for Flow posts to A1. Quieter Echo notifications for Flow posts.Apr 22 2015, 8:04 PM

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

DannyH added a comment.May 5 2015, 5:05 PM

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

greg added a subscriber: greg.May 6 2015, 9:17 PM

This was on Roadmap for last week, update?

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! :)

DannyH closed this task as Resolved.May 6 2015, 10:29 PM
DannyH moved this task from QA Review to Done on the Collaboration-Team-Sprint-B-2015-05-20 board.