Page MenuHomePhabricator

Improve notification read/unread controls and make status indication more clear
Closed, ResolvedPublic

Assigned To
Authored By
Pginer-WMF
Feb 8 2016, 12:44 PM
Referenced Files
F4195407: dot-statu-adjusted.png
Jun 23 2016, 4:16 PM
F4096179: dot-status.png
May 31 2016, 11:40 PM
F4096086: Slice 1.png
May 31 2016, 11:40 PM
F4063318: mark-read-transition.gif
May 27 2016, 7:59 PM
F3366372: Panel-read-dot-tic-reviewed.png
Feb 17 2016, 2:55 PM
F3322768: Panel-read-current.png
Feb 8 2016, 12:44 PM
F3322840: Panel-read-dot-tick.png
Feb 8 2016, 12:44 PM
F3322758: Panel-read-tick.png
Feb 8 2016, 12:44 PM
Tokens
"Piece of Eight" token, awarded by RandomDSdevel.

Description

The current model to deal with notification read status is based on the use of background color to distinguish read and unread status and the X" icon to discard unread notifications to mark them as read.

Panel-read-current.png (646×492 px, 56 KB)

We found some issues with this model:

  • Not reinforcing the current status. We found some users that when exposed to a notification panel with all unread notifications, it is hard for them to tell whether the notifications are read or unread. The reason may be that there is no way to compare the background color of both kinds of notifications but also that the "X" is not helping enough the user to identify the status.
  • The action may have unexpected side-effects. Users associate "X" with "discarding", which aligns well enough with "mark as read" for the action to be discovered but the misalignment in meanings can create some confusion. Some users got surprised that after clicking the "X" for a notification, it didn't disappeared completely from the panel. This seems more apparent when the model is applied to the Notification Page (where "discarded" notifications may not even change position).
  • Hard to reverse. Once the user marks as read a notification, there is no visual clue to reverse the action.
  • Not accessible to screenreader users

The purpose of this ticket is to explore better alternative models.

Design goals

The solutions we explore should meet the following:

  • Make clear the current status. By looking a notification it should be clear if it is unread or not.
  • Actionable but not distracting. Invite to change the status without distracting from the notification content.
  • Allows to reverse the action from the same place. This will help to quickly switch between the two states.
  • Keep the focus on the unread notifications Those are the items the user needs to process. visual clues on read items should not make them more prominent than the unread ones.

Proposed solution

After exploring several options (T136438) and observing user behaviour (T135564) we propose to highlight the status with a dot (try prototype). Since it seems a simplest solution that users were able to identify without issues during our research.

Panel-read-dot.png (646×492 px, 56 KB)

Design details

Shape

Slice 1.png (432×711 px, 18 KB)

  • The dot is a 10x10px circle.
  • The dot should be placed in a larger active area to be clickable (e.g., 30x30px).

Status

dot-status.png (404×1 px, 35 KB)

  • The fill color and border will change depending on the active/inactive and hover/normal status
  • For hover status a tooltip will be shown with "Mark as unread" (when active) or "Mark as read" (when inactive).
  • If the dots are defined with CSS, the shape properties such as border or fill color can be part of a CSS transition (0.25s long with ease in-out timing) to make the changes more fluent.

Notification item transition
On the Notification Panel, since notification items get rearranged, we want to adjust the transition for those too (this does not affect the items in the Notification page).

The transition from unread to read item will involve the following steps (probably keyframes of a CSS animation):

  • Mark the notification as read. The notification becomes styled as read (grey background and grey dot, see section above) in the same place for a brief moment (0.1s with ease timing). This helps communicate the notification become marked as read.
  • Fade out the notification. The notification becomes gradually transparent (0.1s with ease timing) to communicate it is removed from the current section.
  • Rearrange unread notifications. Unread notifications fill the gap generated by the notification that disappeared. This starts as the previous step is half way and should last for 0.25s with ease timing.
  • Fade in the notification in the read section. The notification (already moved to the right position in the read section) becomes gradually opaque (0.1s with ease timing). Rearranging the read notifications may be needed to make room for the new notification.

Marking as unread should result in the reverse notification. An example of the above steps is shown below:

mark-read-transition.gif (486×640 px, 2 MB)

Related Objects

StatusSubtypeAssignedTask
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedMooeypoo
Resolved Mattflaschen-WMF
ResolvedMooeypoo
Resolved Capt_Swing
Resolved SBecker
DeclinedNone
ResolvedMooeypoo
ResolvedSBisson
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedCatrope
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedNone
ResolvedMooeypoo
ResolvedNone
InvalidNone
ResolvedNone
ResolvedSBisson

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Pginer-WMF raised the priority of this task from to Needs Triage.Feb 8 2016, 12:44 PM

As a point of comparison, we were talking (among other things) about Facebook's notifications in the meeting. I left kind of confused about how FB actually worked here, so I tested and screen-recorded it.

For me, it shows the exact same dot for both read and unread notifications, until you hover over the actual dot.

For unread, it changes the dot appearance on hover and says 'Mark as read'.

For read, the dot appearance doesn't appear at all on hover, and it says 'Read'.

The dots are hidden entirely until you mouse over the notification.

Another interesting thing to note with Facebook is that unread messages are not sorted to the top. I actually think this solves the confusion about what happens to a message when it is marked as read. In our system it could move down several rows or disappear out of view completely - making it look like the notification had been deleted. The only drawback to always-sort-by-date approach is if you have more than a page worth of unread notifications but I think (a) this is an edge case and (b) in such cases you could just scroll down in the widget, or use the full inbox.

Since the 2nd and 3rd models seemed the most promising according to the initial feedback, I extended the Notification Page prototype to support those models:

In T126214#2009390, @Mattflaschen wrote:

@kaldari suggested a tooltip in T126258: 'Mark as read' in notifications needs a tooltip. This is a suggestion for the old UI, but it might still be useful for the new one.

Yes. Tooltips will be helpful in this context to confirm what those visual clues are about and anticipare what will happen when clicking them. I used the default tooltips of the browser in the prototype, but in this case it would be great to avoid the default delay and show them immediately.

Another interesting thing to note with Facebook is that unread messages are not sorted to the top. I actually think this solves the confusion about what happens to a message when it is marked as read.

This is an interesting point, but I'd consider a separate topic since we also got feedback about the representation of read/unread concepts when evaluating the Notification Page designs (T115316) for which read and unread items are not moved around when changing status. Also, in several of the testing sessions where users did only noticed that notifications disappeared when discarding them that was not causing confusion or much surprise (maybe because of the associations of the "X" with discard).

I think the goal of providing unread notifications grouped on top of the notification panel is to let the user focus more easily on the pending work, and that seems useful in our context. If a user taps on the badge indicating there are 2 pending items, it may also be surprising not seeing those two items immediately after opening the panel.

@Pginer-WMF I'd argue for proposal B), as read isn't necessarily congruent with done. Thunderbird or Apple Mail both use a dot as icon for unread messages. See section "The Mac Mail Main window" at http://www.hawaii.edu/askus/850 for an example description, so this is also a UI pattern that might be familiar to users.

@Pginer-WMF I'd argue for proposal B), as read isn't necessarily congruent with done.

It is true that "read" and "done" are not the same, but presenting the items in a more actionable way may help to increase the sense of achievement as you process items. The pattern of keeping items as "unread" despite you having read them, suggests these items do not just represent a piece of information but the activity behind it. Google Inbox is an example of a product where the "done" metaphor has been applied to represent read/completed items in the e-mail context.

@Pginer-WMF That's an interesting point and Google Inbox an interesting example. Then again, one of their main selling arguments is, that Inbox' automatisms care about with reading the topic is actually done. Like with dinner reservation or flight schedule emails. The mail's unread status is just to get a short span of user attention while the further work is already accomplished in the background and before the automated result is shown (like in the user's calendar).
But with notifications the action is IMO not only to read it, but to (re-)act on it. A checkmark is therefore not the best symbolic representation.

A checkmark represents a more "final" state, as in must be fully accomplish and also bigger hurdle to reset (to uncheck). Comparing with a task list here.

A checkmark represents a more "final" state

I think this is a subtle but interesting point. Either of these models could work, I think. But I've been feeling that the checkbox, while very clear, seemed to me to be a little heavy or overstated. Perhaps this is partly why: subconsciously, for me, it might register as too definitive for a state that is still somewhat transitional towards a true resolution.

I agree with what @Volker_E and @jmatazzoni say: the checkmark represents that you are done with the item (which goes beyond just reading it). This means that if you are not really done, it encourages you to keep it as "unread" until you are really done. It encourages the use of these information items to represent and organise the work you have associated with them. So I think these associations may be positive for our goals.

Note that a pure read/unread model has also inconsistencies in the very moment you are allowed to mark something as unread (it is not possible to unread what you read in reality). By marking as unread you are actually indicating that you are not done with the item, which may be better supported directly.

I noticed that one point is missing from discussion

Some users got surprised that after clicking the "X" for a notification, it didn't disappeared completely from the >panel.

We have messages with read/unread status still displayed in the Notification panel. The reason for that persistence is Notifications are considered important, so a user should be able to return to them any time (or mark them as unread). I think, however, that having "X" for discarding the message from the Notification panel would have a value for a user. We have "discarding" behavior for cross-wiki notifications - so, why not make "X" behave the same for a local wiki?

We have "discarding" behavior for cross-wiki notifications - so, why not make "X" behave the same for a local wiki?

For cross-wiki notifications and for local notifications the effect of the "X" is the same as the user clicking on the notification itself (minus the navigation to a different page). What is different is that inside the cross-wiki bundle, only unread notifications are visible.

For local notifications, recent read notifications are kept to facilitate follow-up actions (e.g., read the notification about a question, navigate away to find a piece of information and easily find the conversation again to reply).

jmatazzoni renamed this task from Clarify read/unread status for notifications to Improve notification read/unread controls and make status indication more clear.Apr 28 2016, 5:54 PM

@Pginer-WMF, do we need to add anything to clarify how this works on the Notifications page? I.e., on the special page, there would clearly be no animation to indicate the move from one state to another. Anything else that's relevant?

Also, to clarify for the developers and QA, can you please spell out the highlight/movement steps, in proper sequence, in your animation above? I'm seeing this:

blue dot displayed:

  • On rollover, dot turns gray and displays "Mark as read" tooltip.
  • Onclick, background changes to gray. and [WHAT EXACTLY IS NATURE OF ANIMATION?]

gray circle displayed:

  • On rollover, [ANYTHING IN CIRCLE ON ROLLOVER?] and displays "Mark as unread" tooltip [RIGHT?]
  • Onclick, background changes to white, blue dot fills in, and [PLEASE DESCRIBE ANIMATION]

@Pginer-WMF @jmatazzoni On a minor note, we need to make sure that the clickable area is big enough.

On a minor note, we need to make sure that the clickable area is big enough.

What's your recommendation for a minimum diameter?

I provided some more details in the ticket description about the size, color, states, and transitions for the read/unread marks.

@Pginer-WMF, I see you reclassified this from Notifications to Notifications Page. Yet I'm pretty sure these changes take effect on both the page and the panel, correct?

Change 295262 had a related patch set uploaded (by Mooeypoo):
[wip] Change mark as read buttons to circles

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

Change 295318 had a related patch set uploaded (by Mooeypoo):
[wip] Fade in/out elements that are moved in the notifications list

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

@Pginer-WMF, I see you reclassified this from Notifications to Notifications Page. Yet I'm pretty sure these changes take effect on both the page and the panel, correct?

You are right. I went to the list of T136567, adding "NotificationPage" tag to all items, without having this into account. I don't recall removing "Notification" tag but maybe that's what happen with sub-projects.

In cases like this, I'm not sure what is better: (a) leave the general tag, or (b) add both specific tags: NotificationPage, and NotificationPanel (not sure the later exists). So feel free to adjust as you consider.

I don't recall removing "Notification" tag but maybe that's what happen with sub-projects.

Yes, it is. You can't have something be tagged with both the parent project (Notifications) and the subproject (Collab-Notifications-Page) at the same time. Tagging the subproject untags the parent project.

In cases like this, I'm not sure what is better: (a) leave the general tag, or (b) add both specific tags: NotificationPage, and NotificationPanel (not sure the later exists). So feel free to adjust as you consider.

We don't have a tag for the notification panel. In this case, I think it's better to keep the Notifications tag.

This comment was removed by Catrope.
This comment was removed by Catrope.

Change 295262 merged by jenkins-bot:
Change mark as read buttons to circles

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

I'd like to propose a small color adjustment on the unread markers.

  • Change the blue of the unread mark (i.e., mark as read action) to be #36C
  • Change the unread mark (i.e. mark as read action) on hover to be a lighter blue ( #99B2E5 )

The revised color spec would be as follows:

dot-statu-adjusted.png (404×1 px, 37 KB)

The goal is to coordinate with recent color palette adjustments and avoid the problem of the unread status to become hidden until the cursor is moved away.

I tried to send a patchset myself but Vagrant is not willing to collaborate.

Checked in betalabs in the flyout and Special:Notifications - all specs have been implemented except for
"For hover status a tooltip will be shown with "Mark as unread" (when active) or "Mark as read" (when inactive)." - which may be addressed later.

Change 296240 had a related patch set uploaded (by Catrope):
ToggleReadCircleButtonWidget: Tweak colors per Pau

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

Change 296240 merged by jenkins-bot:
ToggleReadCircleButtonWidget: Tweak colors per Pau

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

Now that we've done this, Mark as Read in the dotdotdot menu is redundant, yes? @Pginer-WMF, I'll file a separate ticket for that, shall I?

Change 295318 merged by jenkins-bot:
Fade in/out elements that are moved in the notifications list

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

Now that we've done this, Mark as Read in the dotdotdot menu is redundant, yes? @Pginer-WMF, I'll file a separate ticket for that, shall I?

I believe it is redundant, yes. (No-JS users don't use it, which is the only edge-case I could think of)