Notifications/User Experience

This document is a work in progress. Comments are appreciated but this is not a final draft.

This page describes feature requirements for a new notifications system for Wikipedia, code-named Echo. Features below are for the first release of Echo, with a target date of January 2013. To learn more about Echo, check out this project hub, the testing page, the full feature requirements, the metrics plan and other related documents.

User Experience

edit

Key Components of the Notifications Experience are:

  1. Notifications Growler & Notifications Flyout (Web Delivery)
  2. Notifications Archive (See All Notifications)
  3. Notification Settings (Preferences)
  4. Email Experience
 
Sample notifications: talkpage messages
 
Sample notifications: recognitions and cross-references
 
Sample notifications: edit reverts and reviews
 
Core Notification Types
 
Flyout UX
 
Preferences for V1
 
Subject line of an individual Notification
 
Individual Notification UX
 
Daily/Weekly Digest
 
HTML Email UX for Bundled Notifications

Notifications Growler and Flyout

edit

A "Notifications," link will appear in the user's chrome with a red badge and a count of new notifications. Of the total new notifications, only 10 will be shown in the flyout. There will be a link to go and See All Notifications in a Notification Archive.

Archive

edit
 
The All Notifications Page
 
Quick View of Templates

This archive will be bucketed by day (today, yesterday, 2 days ago, 3 days ago) The archive will support a max of 7 days.

Notification Settings

edit

Settings around Notifications can be customised to a large extent.
Although Echo attempts to carry smart defaults, an editor may decide what type of notifications they want to switch off.
Here are some suggested mocks for preferences cleanup.
This is purely a wireframe and hence the colors etc could be ignored for now.

Email Experience

edit

Open questions around the email notifications experience:

  1. With the assumption that there are relevant notifications what is the frequency of email notifications: Daily, Weekly, Bi-monthly.

Design Considerations:

  1. Email notification should carry actual content not just pointers to content
  2. Notifications should be actionable from within your email
  3. Notifications must be bundled in email just like the flyout to avoid inadvertent spam.
  4. Email must be aware of 'Read Notifications' Flag
  5. What happens when we detect that a user is reading an email notification on a mobile client

Real Time Notifications

edit

This is a list of real time Notifications

  1. Real Time System Messages
  2. Edit Notices
  3. Error Messages
  4. Descriptor Messages
  5. Protection Notices
  6. Talk Page Edit Notices
  7. Site Notices
  8. Central Notices

Read vs Unread

edit

Note: It is important to note that all notifications exist in a state of "read" or "not read". The process by which a notification is marked as "read" is something that we will want to experiment with. There are several ways of handling "Notifications as Read":

  1. They have been "seen" (e.g., when the user views their notifications)
  2. They have been "acted upon" (e.g., the user visits their talk page after being notified it was edited)
  3. They are manually marked read

The mockup provided assumes that notifications are marked read upon being seen.

Elements and Process

edit

A new user interface link, "Notifications," will appear in the user's chrome. If the user has "unread" notifications, the number of unread notifications will appear next to the link as a badge upon a red background. This badge will auto-update (see below).

Clicking on the "Notifications" link or the badge will display the Notifications Bar (clicking on it again, or anywhere outside of the Notifications Bar, will close the bar, possibly marking all Notifications as read).

Notifications are "bucketed" by the wiki they have come from. Individual wiki buckets will contain all unread notifications from that wiki, regardless of timestamp.

Buckets are sorted top-to-bottom based on the most recent timestamp held within the bucket. Thus, it is possible for a bucket at the top of the bar to contain Notifications that are older than those contained in buckets beneath it provided that there are Notifications that are newer than the most recent Notification in lower buckets.

Buckets will have a header that indicates which wiki they are coming from (both its "official" name and the "URL"). Headers are not hot.

Inside each bucket, Events are displayed. Events may be atomic or bundled, depending on the preference of the Publisher. Events contain timestamps printed in context-relative format (e.g., "10 minutes ago, "3 hours ago"), with the most recent listed first.

Event text should really be capped at 250 characters.

Events should have distinguishable icons. (Should the process of Event-to-Icon association should happen at the Central Service layer or at the Publisher layer? Or skin?)

Clicking on any one Event's entry will cause that Event to be "actioned" - usually going to view the item in question.

The entire section of the Event is "hot". While some things (such as user names) may appear to be hot links, they are not - the entire element is and is focused on a single URL.

At the bottom of the Notifications Bar will be an additional link, "View all notifications". Clicking this will bring the user to a Special page which lists all notifications, read and unread.

Preventing Notifications Creep

edit
  • The general approach is to switch certain types of notification off or move them into their own threshold as an editors engagement with the project increases

-Turn off watchlist notifications/ move them into their own space once we know that this component is creating creep or the user will not care about this any more.

Echo Replaces

edit
  • The "yellow bar" notifications about talk page edits, LiquidThreads "New Messages" link and special page, others as determined.