Notifications



This page is the project hub for a new notifications system for Wikipedia, code-named Echo. This product is designed to replace and augment existing notification systems on MediaWiki sites, as well as provide significantly more control to both users and developers as to how their notifications are handled, read, and deleted. Echo is being developed by the Wikimedia Foundation's editor engagement team.

To test an early beta version of Echo, visit this testing page. To learn more about Echo, read below, or visit the user experience page, the feature requirements page and other related documents.

Goals












This new notifications system (code-named "Echo") seeks to unify the delivery of interaction messages in MediaWiki core, through a common API that can provide a uniform interface for users, as well as a scaleable, high-performance platform for developers. For a quick visual overview of this project, check the.

Problems and Solutions
We aim to solve these core problems:
 * There is no central notification system on MediaWiki sites
 * The current ad-hoc approach is inefficient
 * Users are not notified of key events
 * Users are confused by current notices

Echo will be developed to provide these solutions:
 * Provide a unified user experience
 * Help developers add it to their code
 * Promote editor engagement

Objectives
Our near-term goals include:
 * Deploy on MediaWiki throughout 2012
 * First release on En-Wiki in Jan. 2013
 * Second release around March 2013?
 * Third release around June 2013?

User groups
For the first release, we will support three types of registered users:
 * new editor (our primary target)
 * active editor
 * very active editor/admin

However, we will focus on new editors (over experienced editors) for this first release, because new users need notifications more than power users. Specifically, we will concentrate on some of the first notifications which a new user will receive after creating an account on Wikipedia, as shown in the workflow to the right.

This doesn't mean we will not support active or advanced editors, but we will initially emphasize notifications that help engage new users, who need this service most urgently.

Anonymous, unregistered users will not be targeted for this release.

Scope
Here is our proposed scope for the first release, due in Jan. 2013.

In-scope:
 * focus on logged-in users
 * only en-wiki and mediawiki
 * only notifications about:
 * your contributions
 * your talk page
 * your watchlist (partial?)
 * build these features:
 * flyout
 * all notifications page
 * notifications preferences
 * email notifications (plain text)

Out-of-scope:
 * no support for anonymous users
 * no cross-wiki support in 1st release
 * no notifications for:
 * public announcements
 * your account
 * your tasks
 * limited mobile support (mobile web/tablets?)
 * more tasks may be added to this out-of-scope list
 * we may address these tasks in next 2013 releases

As this project expands, new sections will be added on this page, including:
 * key features
 * best practices
 * deliverables
 * schedule

For now, please refer to our related documents for more information on these topics. The rest of this page focuses more on design considerations, at this early stage of development. More to come.

Project update
Here's a recent project update on Echo:

Project tasks are being managed on a publicly-accessible Trello.

Related documents

 * Testing tips
 * Feature Requirements
 * User Experience
 * Engineering Plan
 * Technical Architecture
 * Echo Prototype
 * Extension page (with installation instructions)
 * Echo Overview Slides
 * Notifications Short List (work in progress)
 * Notifications - Best Practices Screenshots
 * Echo Planning - Trello
 * Echo Timeline

Values
For the User:
 * Being aware
 * Getting an aggregate sense of activity
 * Confusion Reduction
 * Quick action I can take at a glance

For the Foundation
 * Promotion awareness through community
 * Driving Engagement for new users
 * Eventually promote a user's interest graph

Focus

 * Focus on a single wiki use case and ensure behavior consistency across wikis
 * Technical constrains associated with implementing cross wiki need to be considered (Ryan Kadari)
 * Initially preferences to be associated with a single wiki

Open Areas

 * Taxonomy of notification nodes
 * Integration with existing UI elements
 * Interwiki Notifications Behavior

Rationale
The central tracking bug, "MediaWiki needs a sane notification system", can be found at 32281. Currently, notifications within MediaWiki are ambiguous and replicative. Multiple extensions and functions will fire off notifications and very few utilize the same system. This creates massive user confusion. For example, the following systems utilize their own, distinct methods of user notifications:
 * Standard "user talk" and watchlist notifications
 * LiquidThreads replies and postings (Special:NewMessages)
 * Feedback Dashboard responses

Primary Reasons are "providing a unified experience for the user" and "providing ease for developer implementation."

Unified UX: On the user end of the issue, notifications are presented to the user is many different forms. For example: orange bar at the top of the page, LiquidThreads notifications in the form of a number in the top right corner, or a watchlist notification via email. Each type is implemented differently and presents the event in a different manner, making the system confusing to users. A user should be able to easily maintain what notifications he/she wants to receive as well as be able to look at and act upon those notifications. With the current spread-out and differentiated notifications system, this is impossible, especially in cases where there are multiple wikis on a farm and notification events occur on each individual wiki.

Ease of Developer Implementation: The notifications system also presents a development issue. Should the need arise to create a new type of notification or a new vector for delivering notifications, it would require numerous code changes in various modules of MediaWiki depending on what notification is being changed and how it is being changed. A centralized system would necessitate only one or two changes in code, usually in the form of an event registration hook or additional method in the notification system. This issue becomes amplified for extension developers because there is no infrastructure to work off of for sending notifications, so making a new type of notification would require either changes to the core, which causes issues when upgrading, or writing custom code, which only furthers the issue at hand. See the Echo Functional Requirements here

Hypothesis
A well-designed and useful notifications system will:


 * Promote editor retention by:
 * Providing users with a modern experience that is similar to other sites
 * Providing a sense of activity within the various projects
 * Reducing the clutter on user talk pages
 * Providing an easier mechanism for displaying 360 interaction processes (as opposed to things like "talkback" templates), thus "centralizing" the discussion
 * Promote better software development by
 * Making it easier for extension developers to plug notifications into their code as needed
 * Making it easier for core developers to add new notification vectors
 * Providing a stable and platform-native interface pattern
 * Improve performance and efficiency by
 * Having all notifications stored in one location, thus requiring fewer database queries
 * Allowing wikis to push notifications to users at the system's convenience

Product/Design Principles

 * 1) Notifications will be a function of user engagement
 * 2) Notifications directed at you will be of most importance
 * 3) You can customize what actions get reflected in your notifications.

Nomenclature

 * Service - the central notification service.
 * Publisher - in this document, a publisher is a feature or extension that is a consumer of the publication/service API. Examples: LiquidThreads, Feedback Dashboard, Talk page edits
 * Event or Notification Event - A specific type of notification. Publishers must define and register notification events with the Service as well as the acceptable back-end pluggables they can use
 * Client - a single user viewing notifications from a single device. Users may have multiple devices.
 * Device - any system where the notification may be seen. Devices can include but are not limited to: user email, MediaWiki "in web" notifications, sms messages, etc.

Core Notification Categories

 * Direct Messages: Talk Page Messages | Wiki-Love | Someone responded to your feedback | Teahouse Answers
 * System Messages: Welcome | Admin Rights | Confirmations
 * Article Contributions: Patrolled | Reverts | Deletion Nominations | Notify me when article rating changes | Actions related to File Uploads |
 * Helpdesk: Teahouse | Helpdesk
 * Commons: File nominated for deletion | Promoted to featured image

Clients
The Clients (Web/mobile/ Tablet) on which notifications will be available are WIP.

Recent changes:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Echo.git&a=rss