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.

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.

In T73564#844657, @Quiddity wrote:

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.

In T73564#844657, @Quiddity wrote:

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.

In T73564#1787336, @Catrope wrote:

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.

This is blocked on the back end, as well.

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

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

Ready to update documentation: T129907: Update Notifications documentation: mark as unread

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.