The separation of notifications in two different buckets ("alerts vs. messages" first, "alerts vs. notices" later) was aimed to anticipate to users what kind of notifications the received before opening the panel. This is important to avoid distractions. It allows users to decide whether to rush to check these notifications immediately ("my edit was reverted", "I was directly mentioned in a conversation"), or check them later at their own pace ("a page I created has been linked" or "someone replied to a topic in a discussion I'm interested").
While the distinction is useful, it is not clear that separating both concepts completely as different entry points is the best possible solution:
- **All items are notifications and splitting them requires an effort to understand the purpose of the separation.** If I recall an important conversation I got a notification about, I need to know whether I was mentioned or it was a regular reply in order to know which bucket to look at.
- **The distinction results confusing to communicate.** Distinctions based on familiar concepts such as content vs communication presented a mismatch in terms of urgency. Buckets based on urgency seem to make it hard to anticipate which kind of notifications they'll find there. Concepts picked for the groups and the general concept tend to be so close that lead to translation issues in several languages.
- **Splitting has not been consistent in all places notifications are provided.** Mobile notifications provide a single entry point, and the notifications page shows all of them together.
In addition, when the separation was done, it aimed to solve too many issues related to volume and urgency for which other mechanisms have been considered since then:
- Volume control (T115264) will help to avoid getting distracted by notifications you are not interested in. Users are not required to process information every time a new notification is received. For example, a user getting too many pages linked to the one she created, can just mute that event and not get distracted by a blinking badge in the future (making it less relevant in which bucket those were appearing).
- The improvements on the notification page (T115316) provide more filtering capabilities to focus on a given set of notifications. Users interested on a more focused work can use that tool (keeping the panel for quick notification checks as simple as possible).
# Proposed solution
Provide a single entry point for notifications.
Use the badge color (and the read indicator) will be used to indicate urgency:
- If there are no urgent notifications, the badge will be blue.
- If there is any urgent notification, the badge will be red.
- For unread items, the read indicator of each item will be blue (for non-urgent) or red (for urgent) depending on their urgency.
[[ http://pauginer.github.io/prototypes/notifications/organisation-schemes/index.html#single | This prototype ]] (part of the [[ http://pauginer.github.io/prototypes/notifications/organisation-schemes/index.html | notification schemes prototype ]]) illustrates the idea with an example, also captured by the animation below:
- **One single place for notifications.** All notifications are there, which simplifies the process of where to go in order to check notifications. This also saves space in the already crowded personal toolbar and keeps it aligned with the mobile approach.
- ** Helps deciding whether to check them now or later.** Urgency is both surfaced when making the decision on whether to check notifications, and indicated on individual items to explain why the badge turned red.
- ** No separate counters.** The user is indicated that she has 100 pending notifications, and some are urgent. We are not telling how many urgent there are. I don't think this is very limiting since the read status will make it visible once the panel is open.