Notification panel: Clearer use of notification badges
Closed, ResolvedPublic

Description

Notifications are surfaced to the user attention through the notification badges. There are some aspects that can be improved:

  • Space efficiency. Surfacing both badges requires to take more room from an already crowded personal bar. While taking some extra space was unavoidable when providing two entry points instead of just one, the use of space can be optimised in some situations. For example, when there are no unread notifications we are still showing an icon and a "0" counter just to keep an entry point for the user to check read messages.
  • Accessibility. The inactive state for the badges (when there are no unread messages) uses a grey which is to light for the white text to be readable on top of it according to the basic accessibility considerations. In order to fix this, increasing the contrast may not be the best option since the badge can become too prominent for an "inactive" state (calling the user attention as if there were new notifications when there are not). More details in T98526.

Proposed solution

In recent research sessions with users, a different approach was included as part of the tests (T114086). The new approach was designed to be more efficient with space (there are no counters when all notifications are read), and it makes it easy to comply with the accessibility guidelines without generating confusion between active and inactive states.

The basic approach is to use persistent icons with smaller badges for the counters (but counters will be only shown when there are unread messages). Note that the examples use the new "tray" icon for notices (a separate change described in T135114). Different colors and levels of grey will be used to communicate the different states as shown below:

New notifications

  • Badges are placed partially overlapped with the icons (half horizontally, and one third vertically). they may expand their width to accommodate the counter, but they won't cover more of the icon behind them.
  • When there are unread notifications, icons and badges are prominent: icons are dark grey (#2F3133), and badges use color: red (#C33) or blue (#36C) depending on the urgency of notification types.
  • The badges have a 2px border radius and a 1px white border to separate them from the icons behind them.

Pending notifications

  • After opening the panels, unread notifications are no longer considered "new" (or "unseen"). Thus, badges become less prominent, using a grey background (#71777D) and they show the number of unread items.

Read notifications

  • Finally, when all notifications are read for a given category, only lighter grey icons (#71777D) are shown (with no badges) in order to avoid demanding too much user attention but still providing an entry point to check the different kinds of notifications.

Further considerations

The model worked well when used as entry point for accessing the notification panel without a single issue. A simplified prototype was used (only showing one badge), in order to check whether the metaphor worked. The testing of the badges was not the main goal of those testing sessions, but accessing the panel was done repeatedly.

Another initial concern, was about readability. Using smaller badges limits the room for the counter text. As shown in this prototype, we were able to use a 13px font size which is even bigger than the regular font size used in the personal toolbar (12px). Users were able to quickly identify how many unread notifications there were.

Related Objects

Pginer-WMF updated the task description. (Show Details)
Pginer-WMF raised the priority of this task from to Needs Triage.

Another approach has been discussed recently on mw:Talk:Echo – show one badge at all, but order by priority. Show background colour and symbol of the highest priority only, but total number of messages.

This permits not only 2 icons, but 3 or 4 as well, and still reducing space.

  1. RED (bell) – email2me, mentioned, revert, right-change, system, welcome (once in life): the alerting things
  2. YELLOW (bubbles, currently blue) – Flow, or own talk page: talks touching me
  3. GREEN (a heart) – Thanks, Wikilove: does not break my work, but might make my day
  4. BLUE (no symbol, digits only) – a page has been linked or patrolled: just informative
  5. GREY (no symbol, digit "zero" only) – no messages at all

The user will see the highest priority at a glance, and may put attention only at red or yellow level, reading less important things at coffee break.

I think it would be the best if the user could decide himself which type of messages has which priority. In this way, every user could configure his Notifications as he wants, for with one, two, three or more priorities for example.

The user will see the highest priority at a glance, and may put attention only at red or yellow level, reading less important things at coffee break.

That approach is very efficient in terms of space, but we need to be careful on some other aspects:

  • Making the workflow too rigid. Although we can anticipate the priority of message types, the specific context of the user is very relevant, and we may be getting in the way if we don't provide enough room. For example, if I'm replying to some Flow messages ("yellow" notification) for which I'm collecting some info and I get an alert meanwhile (red notification), I have no choice to focus on the task at hand since the access to the yellow notifications happens through the red ones (which in the current state would become marked as read immediately, even if you opened them just to access the yellow ones).
  • The lack of an overview. Users that found the separation of alerts and messages referred to the concept of having a quick overview of what is going on. Even if you don't plan to respond to them now, having a notion that new messages arrived has a value and that information can get easily lost. This can generate uncertainty about what is going on beyond the high priority notification you may have pending.
  • Predictable entry points facilitate repeated access. Having a clear entry point with a predictable and reproducible outcome makes it easy to train the muscle memory and rely on the peripheral vision to access information quickly. Having a single entry point with a different outcome requires the user to process what changed or reorient if the user just opened the badge out of habit without thinking about the kind of notification being opened.

Having said that, I'm open to explore the proposed direction a bit more but I think the above will help to identify what to focus on if we try it with some users.

I think it would be the best if the user could decide himself which type of messages has which priority. In this way, every user could configure his Notifications as he wants, for with one, two, three or more priorities for example.

In T115264 we are considering which is the degree of configuration needed to control notification volume, which seems related to this. In order to better understand the specific underlying needs, it would be very helpful to hear about the issues you are experiencing in this regard. Can you provide an example of some notification that (a) you would be interested in getting less of or (b) has been getting in the way of other important notifications causing distraction?

Every time I receive a THX there is red alert. And I am close to a heart attack: Did someone revert my recent edit? Another boring talk inviting me, or am I requested to fill a RTFM gap? Oh, no, it was a thanks. I would prefer to see a green heart rather than a red alert bell.

There might be a misunderstanding in T115845#1738028 – clicking on the badge always opens the entire list, with blue linked items and green thanks entries as well. I read your comment that you expect only red issues under the red badge; no, nothing was lost. This is indicated by the unique total number of unread messages, as mentioned above.

The split list of Flow messages and other ones might be merged again. Perhaps sorting of the unread part of the list could be useful in future; default sort: last on top, but alternatively highest priority on top, and chronologically descending within priority. Depends on the increasing traffic if more and more activities are notifying.

Focussing on high priority things, ignoring less important matters is a proved concept.

Can you provide an example of some notification that (a) you would be interested in getting less of or (b) has been getting in the way of other important notifications causing distraction?

I think Thanks amnd Wikilove are too prominet currently, while messges at my own talk page should be as prominent as mentions, because I think they are more an not less important then them. For the rest I think the idea of PerfektesChaos would work really well.

messges at my own talk page should be as prominent as mentions

Mmh, yes; but they can be highlighted by an orange bar, at least for a while; and everybody will catch them sooner or later on the watchlist. If not, they should be staged as red, since I am personally involved. For the time being blue/yellow is sufficient and on systems without Flow own talk page is the only event that can trigger this level.

Thanks @MGChecker and @PerfektesChaos for describing your scenario.

From what I understand alerts are perceived as high priority information that requires your response, and that does not match with "gratitude pings" like Thanks or Wikilove.

I think this can be solved without the need to add more buckets for the user to think about. Some possible options:

Move Thanks to "Messages" panel

  • Classify Thanks, Wikiloves and similar notifications as messages (i.e., show them in the "messages" panel). Conceptually it makes sense since those represent a (quick) message between users.
  • Bundle those notifications when there are many of the same kind, so the user gets a single "100 users thanked you by your edit" instead of 100 different notifications.

In this way, the red alerts badge won't be affected everytime you get a thanks notification, and you can check them at your own pace when you decide to go through your message inbox.

Highlight when there is an urgent need for a reply

  • Keep two separate buckets as they are now: alerts (for quick to check events) and messages (for user-to-user communication).
  • Highlight both badges using blue by default. When there is a high priority notification (one that is likely to need immediate attention), highlight the badge in red.

With this approach You'll see a blue alerts badge when it contains some Thanks notifications, but it will turn red as soon as your edit gets reverted. In this case we still need to figure out how to connect the badge colours with the notification that caused them (e.g., using the highlight when opening the panel) so that the user understands the cause-effect relationship.

MGChecker added a comment.EditedOct 22 2015, 12:55 PM

I don't think it's necessary to split the panel in two, if Notifications are bundled and there is a clearer panel in general, but I think the first option you mentioned can be a fast workaround until the panel really is better organized than currently and before the split.

The most recent proposal by @Pginer-WMF fulfills questioned fine-graining of notifications well in my understanding. On the other hand I don't think introducing a five-color-scheme gives clarification to users without a steep learning curve and irritating visual noise. I'd rather stay with a three-way state of 'everything read', 'minor new/unread notifications', 'major unread notifications' and go with @PerfektesChaos to possibly fine-grain which one belong to minor, which one to major.

Well, it would be okay with me if there is a general expert mode for the echo system which might extend functionality under various aspects; or decrease complexity for beginners. The first issue to reduce confusion might be the preferences page itself.

However, I would like to stick to the higher granularity assigned internally, and the implementation should be prepared for a general approach. For the beginning, displaying the unread messages might be mapped to two levels only.

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptDec 9 2015, 12:52 AM
Catrope triaged this task as Normal priority.Dec 18 2015, 12:55 AM
Ltrlg added a subscriber: Ltrlg.Dec 29 2015, 10:47 AM
jmatazzoni added a comment.EditedJan 7 2016, 1:48 AM

Talking about the badges inspired a lot of talk in this task (above) about finding a better way to divide the Notification types. So we are splitting off a separate task for that: "T123018: Revise Sorting of Notifications on the Fly-Out Menu"

Mooeypoo assigned this task to Pginer-WMF.

As @jmatazzoni mentioned, the discussion about reorganising the notifications has now its own ticket (T123018).

The current one is about changing the way the badges are presented. Which I think is captured in this ticket, and tested as part of the different research sessions.

So I'm unassigning it from myself to allow developers to pick the task (@Mooeypoo, let me know if any further details need further clarification).

Pginer-WMF removed Pginer-WMF as the assignee of this task.Feb 23 2016, 4:54 PM

@Pginer-WMF, I'd like to look again at the icon on the right-hand, "Notices" badge. I see two problems with using the chat bubble (or whatever we call that) for Notices: One is that it is so similar to the icons we use for so many of the notification types. It would be natural for users to think we're indicating that the discussion- and flow-related notifications -- and even Thanks -- that use versions of that shape will be found on that right side. But the notification types using that shape on both sides. The second, more general issue I see is that the chat bubble would seem to indicate that this is where one would find communications from other users. But again, that's not the axis along which these two categories divide. (Especially since, looking at the early survey results, we'll probably move flow-post-reply to Alerts.)

The consistent differentiator in the Urgency scheme is the idea of importance/urgency. So, the trick is to think of something that suggests a signal-- the way the bell does -- but a quieter one. At one point you were using an inbox, which could work but which I don't love because of the association with mail.

Something more abstract might be better. I'm imagining a little flag--evocative of the flag on a mailbox, or signal flags on a ship, or the expression "set a flag,"

Other ideas?

The icons in the current ticket were defined before the discussion about changing the classification scheme. So the second one was still based on discussions, which no longer makes sense if the classification scheme is changed.

As you mentioned, in the prototype for the notification scheme a tray was used:

The tray was aimed at representing the rest of communications not worth ringing the bell. I can explore other options now that we have a better idea of the kind of content we want for each bucket.
The key idea is to surface there is new activity but not convey a sense of urgency. In that regard, the flag seems associated with urgent things too.

And simply no icon on the non-urgent pile? Just digits? Grey bg if zero, else blue?

I talked this over with Volker and am convinced there's no magic idea out there waiting for us to hit on. The in-box works well enough for me and I'm content to move this forward to RFP unless @Pginer-WMF disagrees. Pau?

If we do move forward, do we have the final graphics? Is there anything else we need? Do we need a description of the various highlight states (no notifications, new notifications, what happens on opening the panel, etc.)?

I talked this over with Volker and am convinced there's no magic idea out there waiting for us to hit on. The in-box works well enough for me and I'm content to move this forward to RFP unless @Pginer-WMF disagrees. Pau?

I created a ticket for the icon to be integrated: T135114: Review "tray" icon

I made some exploration (F4000095), but found no clear candidate that worked better than the tray in this context for now. So I'm ok to proceed with the current one.

And simply no icon on the non-urgent pile? Just digits? Grey bg if zero, else blue?

Currently we only highlight the badges where there is new activity. When the user has already checked them, the badges go back to a neutral state (grey) and the distinction based only on color won't work in that case.

More generally, I think we want to communicate the mental model to help the user to set expectations (i.e., the urgent notifications in the bell vs. the rest in the inbox tray).

We can continue exploring options that make badges more compact, find better metaphors or connecting them better; but I think the proposed change is already a step forward (clarifying the distinction between active and inactive status and solving the accessibility issues). So I'd propose to make the change and create a new ticket proposing new improvements as a next step based on the observations on how this works.

There is A LOT of discussion here (which is awesome). Would anyone be able to summarize the decisions in the task description so it can be executed?

Pginer-WMF updated the task description. (Show Details)Jun 29 2016, 9:49 AM

There is A LOT of discussion here (which is awesome). Would anyone be able to summarize the decisions in the task description so it can be executed?

I updated the ticket description with the latest information and mockups. I added also the updated colors according to the latest discussions with UI-Standardization, and the new tray icon (T135114).

Change 299910 had a related patch set uploaded (by Mooeypoo):
[wip] Redo the notification badges

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

Change 300170 had a related patch set uploaded (by Mooeypoo):
Allow 'data-*' attributes in personal tools links

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

Change 300170 merged by jenkins-bot:
Allow 'data-*' attributes in personal tools links

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

Change 299910 merged by jenkins-bot:
Redo the notification badges

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

Checked in betalabs 1.28.0-alpha (4c7cd24) along with T140900: Change bubble speech icon to tray icon.
All specs from this ticket (imgs, colors, borders) seem to be in place.

The screenshots are the same as in T140900: Change bubble speech icon to tray icon.


Closer look:

Double digits for number of notifications:

Only Notices are present:

Only read Notices and Alerts:

jmatazzoni closed this task as Resolved.Aug 2 2016, 12:50 AM