The overall task is: Deciding how to sort the notification types (e.g. "new usertalkpage message", "your edit was reverted", "a page you created has been linked to", "thanks", etc) into two groups. The current sorting has some problems.
There were formerly two proposals. After some feedback we have decided to keep only one alternative to the current scheme (April 2016). The team wants your feedback on it (your preferences, or concerns). The recommendation is we start off with the "By urgency" grouping (prototype).
There are currently two Notification flyout menus, one for Alerts and one for Messages. Different notification types show up on different menus. There have been criticism over time that the scheme for dividing up the messages is unclear and/or inconsistent. These criticisms include the following:
- Ideas of "urgency" and "requiring follow up" are mixed together, making it difficult to explain or predict why different items are in each flyout.
- Currently, "Alert" items are automatically "marked as read" on opening the flyout. Yet some of these require follow-up or other action to be fully understood (e.g., Mention), so this feature's value is not always clear.
- Because "Alerts" are perceived as "Urgent", the "Thanks" and other items seem out of place in that flyout.
- To create a scheme that is easy to understand, learn, and predict.
- To give editors clearer information about their new notifications.
- To reduce unnecessary distraction from non-urgent notifications.
- Something that works well for editors who get large (and small) quantities of notifications.
- Something that scales well, as new (requested) notification types are created.
- Something that scales well, once cross-wiki notifications are available.
See examples of the most common notification types at:
- Urgent versus Non-Urgent
- (formerly and now abandoned) Follow-up versus No follow-up (is a reply needed/likely)
(This table has no annotations, and just shows the most common notification-types. See a more detailed version here at googledocs which also includes a 3rd and 4th (more complicated) alternative.)
|Two Alternative Schemes for Separating Notifications into the 2 Different Flyout Menus|
|#1: CURRENT DIVISION||#2: URGENT VS. NON-URGENT|
|View Mockup of this Concept in Action|
|welcome||내 사용자 토론 문서의 편집||내 사용자 토론 문서의 편집||welcome|
|편집이 되돌려짐||flow-new-topic||편집이 되돌려짐||문서 링크|
|문서 링크||flow-post-reply||언급||감사 표현|
|언급||flow-post-edited||사용자 권한 바꾸기||flow-thank|
|사용자 권한 바꾸기||flow-topic-renamed||다른 사용자로부터의 이메일||flow-new-topic|
|다른 사용자로부터의 이메일||flow-mention||flow-post-edited||flow-post-reply|
|Ideas of Urgency and Follow up are mingled in ways that are inconsistent, making this difficult to explain or predict.||Division, while subjective, is clear and will track with some users' expectations (given the red badge color).||The division is subjective. Given differing working styles, some users will disagree with assignment of individual items.|
|Because some "Alert" items require follow-up and are not self-contained (e.g., Mention), ability to Mark as Read on open is of questionable value||Factor of urgency may provide an aid to triage ("check these first")|
|Because alerts are perceived as Urgent, Thank Yous and other items seem out of place.|
|GENERAL POINTS||GENERAL POINTS|
|In this scheme, an effort was made to determine the messages that users would want to know right away vs. those that they may regard as less pressing. Urgency was more or less arrived at by consensus in consultation with various team members.||What to label these: "Alerts" works reasonably well, since it does carry a connotation of urgency. But many of the Alerts are arguably Messages as well (e.g., edit-user-talk). Suggest "Notices" as not sounding to deprecatory but connoting a lower level of urgency.|
|The red, "Urgent," badge color for Alerts is recommended for this scheme.||In labelling the non-urgent items, we need to be careful that some groups (e.g., Translation) don't perceive that we are labelling their activities less important.|
|Many of the Urgent (Alert) items require follow-up (e.g., edit-user-talk), so use of automatic Mark as Read is not recommended.|