Page MenuHomePhabricator

Allow marking Echo notifications as unread
Closed, ResolvedPublic

Description

The notification panel allows you to mark notifications as read in different ways (you can click on the notification to get to the content, click the "X" or the "mark all as read" action), but it does not allow to make a read notification to become unread again.

Allowing to mark read notifications as unread again makes sense to highlight there is pending work to be done (e.g., the user is planning to reply to a message) when the notification panel is used to organise the wiki work to be done.

Proposed solution
"Mark as unread" is presented as a secondary action for those notifications that are read (check T114357 for more details on secondary actions).

For messages, marking as unread turns the notification to the same status it was before. The notification badge is updated but not highlighted in blue (since the notification is not new). As with any other unread notification, it can become read by opening the notification, marking it as read using the "X" or using the "mark all as read" action.

For alerts, marking as unread keeps the notification as unread even if the panel is opened/closed multiple times afterwards. Unread notifications will appear on top even if more recent notifications appear (similar to what happens in messages where unread bock is always at the top). A special close action is provided to (a) communicate that the notification has been "fixed" and (b) allow to mark it as read. Alerts get marked as read if they are opened (as described in T118722, this may change in the future if we decide to keep a stronger fixed/pinned state).

Further aspects to observe
After providing support for marking as unread, we may want to observe the user behaviour to determine the following:

  • Should we provide also a secondary action for "mark as read" to keep the symmetry? We didn't considered as part of the initial ticket since there are already multiple ways to mark as read, but we want to check if users are expecting to find it also as a secondary action.
  • Should we differentiate more the behaviour between alerts and messages? If we find that "marking as unread" is not enough to explain why alerts don't get unread automatically we may want to surface that more explicitly.
  • Should marked as unread messages also become more "sticky"? Messages don't get automatically read when opening the panel, but they can become read when visiting their associated page. An explicitly marked as unread message becoming read when visiting the page may or may not be the expected behaviour.

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 18 support votes, and was ranked #45 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Notifications#Echo_notifications:_mark_to_read

Details

Reference
bz71564

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:57 AM
bzimport added a project: Notifications.
bzimport set Reference to bz71564.
bzimport added a subscriber: Unknown Object (MLST).
He7d3r created this task.Oct 2 2014, 5:54 PM

Switch [Mark all read] to pin tasks? Or a pin next to an alert? Lots of design needed.

FWIW, I like how Facebook does this:

  • new messages show a numbered badge
  • if you open the notifications flyout, the numbered badge is cleared (notifications are seen)
  • once you click a notification, its background changes from blue-ish to white

In essence, opening notifications clears the badge, but you can still distinguish between what you did and didn't take action on.

Not even sure if this is possible in Echo, didn't think this through yet ;)

In the meeting, we discussed the idea of being able to "pin" or "sticky" a notification semi-permanently. That seemed like the best way to avoid a circular "mark as unread, close flyout, [...], open flyout, have to mark as unread again", etc.
Perhaps having a pin icon near the same location as the x icon? (that flow notifications have)

I do also like the sound of Matthias' description. That would solve the annoyance factor of having a single 'pinned' notification causing the red badge [1] to always display.

Quiddity triaged this task as Low priority.Jan 10 2015, 9:28 PM
Quiddity added a project: Design.
Quiddity set Security to None.
Quiddity renamed this task from Allow marking as unread to Allow marking Echo notifications as unread.Feb 25 2015, 6:57 PM
Quiddity raised the priority of this task from Low to Normal.
Quiddity updated the task description. (Show Details)
Quiddity removed a subscriber: Unknown Object (MLST).
Legoktm moved this task from Backlog to Needs plan on the Notifications board.Jul 6 2015, 8:05 AM

This raised a question about part of the current behavior. We currently automatically mark notifications as read when you visit certain pages. Should we do this for a notification after it's marked as unread. @Catrope suggested no, because it would be annoying if you want to keep it unread.

If so, we should think about how to clarify that. There was also some discussion about marking as read on click instead of on visit in all cases.

I do also like the sound of Matthias' description. That would solve the annoyance factor of having a single 'pinned' notification causing the red badge [1] to always display.

In our current system that already wouldn't happen, because the red/blue-ness of the badge is based on unseen notifications, not unread notifications.

DannyH removed a subscriber: DannyH.Nov 6 2015, 12:43 AM

In the meeting, we discussed the idea of being able to "pin" or "sticky" a notification semi-permanently. That seemed like the best way to avoid a circular "mark as unread, close flyout, [...], open flyout, have to mark as unread again", etc.

Perhaps we could also reevaluate whether automatically marking alerts (but not messages) as read the moment they've been seen is a good idea? I don't really like it.

Perhaps we could also reevaluate whether automatically marking alerts (but not messages) as read the moment they've been seen is a good idea? I don't really like it.

Requiring a click on trivial notifications would probably become annoying. E.g. I get a notification every time someone links to https://en.wikipedia.org/wiki/Amazon_Music . I probably don't want to have to click on each one of those.

Same for e.g. Thanks. Okay, great, someone thanked me, but I shouldn't feel obligated to click it (and clicking the X still counts as clicking it). Maybe I want to see what edit it was, maybe I don't want to bother.

Change 251309 had a related patch set uploaded (by Mooeypoo):
Allow notifications to be marked as unread

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

@Pginer-WMF I was guessing which icon to use as the 'mark unread' icon, and the 'circle' one seemed like a good choice -- but please let me know if there needs to be any other icon.

It looks like this in the patch:

As I proposed in T115581 (and was copied to the description of this ticket), my idea was to use the secondary actions defined in T114357 as the way to make a notification to become unread again. I included that in the prototype we are planning to test as described in T116741. For the prototype I used the following visual element (but I don't think it would work well when placed directly in the notification item):

Regarding the solution illustrated in T73564#1789209, I have some comments:

  • Mark as read and mark as unread are presented at the same prominence level. I don't think that both actions are needed with the same frequency since marking as unread seems more like an "undo" feature that you would use as an exception of the regular use. Having said that, presenting both options has the benefit of providing a more clear contrast between the actions by using an equivalent location. So it may help to identify one as the reverse of the other, but the visual indicators also needs to be complementary (more on this below).
  • Action vs. status. "Marking as read" is represented as an action ("X" to "discard" the item from the top of the list), while the indicator for unread seems more like a status indicator. I think both items should work as a system based on the same approach (i.e., you normally expect "on"/"off" or "turn on"/turn off", but not a mixed "off"/"turn off"). I explored some options below to present these options by either their status or the actions to switch.

Based on the above, I think we should consider whether we want to (a) surface the "mark as unread" action that much, and (b) design a visual system to communicate both concepts (which would be great to include in the upcoming testing rounds). I added some examples to illustrate possible options for the second choice:

Surfacing status
Surfacing the read/unread status can work to provide users control over it.
In the mockups below, unread items are highlighted with a blue dot that becomes less prominent when the notification becomes read. This is a similar common approach to several existing email clients and notification systems. The fact that one status turns into the other suggests that this is the element you should act on to change the status, but a tooltip can also help to avoid hesitation in the process (showing "mark as read" or "mark as unread" when hovering the status indicator to anticipate what will happen once you click on it).

If we highlight status we need to consider whether to distinguish new an previously unread items. Currently new items are temporarily highlighted when the panel is open, but this status can be also integrated into the system if it helps users to organise their pending work.

For the case of notifications that become read automatically (i.e., alerts), marking them as unread is highlighted in a special way to communicate that the status is preserved when the user opens the panel the next time. The mockup below illustrates the transition that occurs when opening an alert panel with one new notification (that gets marked as read automatically) and one notification that was marked explicitly as unread before (not becoming read until the user explicitly acts on it).

Surfacing actions.
Marking as unread can be presented as an undo action to move the notification to the previous state.
Since we are surfacing an action (as opposed to the read status above), we cannot lower the prominence level too much which may result into a more crowded panel.

For alerts, the mark as read action can be modified to highlight that the control has been pinned by the user action.

As per the feedback when this ticket was discussed, it seems we want to keep the "mark as unread" just as a secondary action.

Another issue was also raised about the difference in behaviour between the alerts and messages panels. Alerts and messages have similarities (both are notifications that users can open) and differences (notifications require to explicitly be marked as read while alerts are marked automatically as read).

"Marking as unread" needs to be persistent to be useful, which changes the usual behaviour in the case of alerts. In order to highlight that, I explored two approaches: one based on highlighting the "X" action to indicate that the notification has been blocked. Another using a more explicit "pin" metaphor.

I'm more inclined for the first approach for the following reasons:

  • Since the user explicitly acted on the affected suggestion, it should not be hard to make the connection between the "mark as unread" action and why the alert remains unread the next time the panel is opened. So, there may not be a need to add yet another concept.
  • Introducing a new concept ("pin") adds complexity. If we keep both actions ("pin" for alerts and "mark as unread" for messages"), we are presenting similar actions in a different way to highlight some side-effect (not being read automatically) instead of the aspects they have in common. If we use only the "pin" concept for both alerts and messages it is not working well for new messages (why are those pinned automatically?).

I'll add some more design details to the ticket describing the expected behaviours.

Pginer-WMF updated the task description. (Show Details)Nov 16 2015, 10:19 AM
Pginer-WMF updated the task description. (Show Details)Nov 16 2015, 11:04 AM
Pginer-WMF updated the task description. (Show Details)Nov 16 2015, 12:21 PM

This is blocked on the back end, as well.

Restricted Application added a subscriber: JEumerus. · View Herald TranscriptJan 20 2016, 7:51 AM
IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
DannyH updated the task description. (Show Details)Feb 6 2016, 12:07 AM

Change 251309 merged by jenkins-bot:
Allow mark-as-unread in notifications

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

Etonkovidova added a comment.EditedMar 15 2016, 6:59 PM

For alerts, marking as unread keeps the notification as unread even if the panel is opened/closed multiple times > afterwards.

The current behavior for Alerts

  • 'Mark as unread' does not change the counter - for the counter to reflect a correct number of alerts, a page needs refreshing
  • After Alerts were 'Mark as unread', opening Alerts will mark all of them as read again.
  • Alerts marked as unread will be displayed red in cross-wiki Alerts Notirifications

Given the above issues with 'Mark as unread' for Alerts, a user may not even realize that 'Mark as unread' option worked.

jmatazzoni closed this task as Resolved.Mar 23 2016, 7:18 PM