Echo (Notifications)

Wikimedia Foundation engineering activity

Notifications

Project hub for the Notifications infrastructure and UI (code-name: Echo)

Group:	Features
Start:	2012-07-01
End:	2013-07-01
Team:	Ryan Kaldari, Benny Situ, Luke Welling, Vibha Bamba, Brandon Harris, Oliver Keyes, James Forrester, Andrew Garrett, Matthias Mullie
Management:	Fabrice Florin, Terry Chay, Howie Fung
Status:	See updates

This page is the project hub for Notifications, a new engagement tool for Wikipedia and Media Wiki sites (previously called Echo). This product is designed to replace and/or augment existing notification systems on MediaWiki sites, as well as provide significantly more control to users as to how their notifications are handled, read, and deleted. This notifications project is being developed by the Wikimedia Foundation's editor engagement team.

Notifications was released on the English Wikipedia on 30 April 2013 and can also be tested here on MediaWiki.org. For more information, read this blog post and visit this FAQ page. For tips on how to test this tool, see this testing page. Once you've tested Notifications, please take this quick survey, then join the discussion on this talk page.

To learn more, read below, or check out the feature requirements page and other related documents.

Goals

Notifications inform you of new activity that affects you on Wikipedia -- and let you take quick action.

Echo all-notifications page

Echo notifications preferences

User touchpoints for Echo

Workflow: Notifications for a new user's first steps on Wikipedia

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. For a quick visual overview of this project, check the Echo slides.

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

Notifications will be developed to provide these solutions:

• Provide a unified user experience
• Inform users of important activity
• Promote editor engagement

Objectives

Echo project roadmap

Our near-term goals include:

• Develop better features and new notifications
• Deploy on MediaWiki throughout April 2013
• First release on En-Wiki in April 2013
• Update on En-Wiki by June 2013 (as time allows)

For a more detailed project roadmap, check out this timeline and our Planning page for Editor Engagement Features (E2).

User groups

Notifications will support several different user groups:

• new users (after registration)
• current users

For our first release, we will focus on new users, who 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.

We will also develop some features to support power users, but we will initially emphasize notifications that can engage new users, who need this service most urgently. Anonymous, unregistered users will not receive notifications at this time.

Scope

Echo features timeline

Here is our proposed scope for the first release of Notifications on the English Wikipedia, due in April 2013.

In-scope:

• focus on logged-in users
• only en-wiki and mediawiki
• only notifications about:
  • your contributions
  • your talk page
• build these features:
  • flyout
  • all notifications page
  • notifications preferences
  • email notifications

Out-of-scope:

• no support for anonymous users
• no cross-wiki support in 1st release
• no notifications for:
  • your watchlist
  • public announcements
  • 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 future releases

For more info, please refer to our related documents section.

Project update

Here's a recent project update on Notifications:

[edit status] • [add new]

2013-04-monthly:

In April, we deployed Notifications on the English Wikipedia and mediawiki.org. This first release aims to inform users about new activity that affects them on Wikipedia, such as talk page messages, page reviews, mentions, edit reverts or thanks. Ryan Kaldari developed a new feature that lets users mark all notifications as read, and updated the fly-out and archive page, based on designs from Vibha Bamba. Benny Situ completed the bundling feature and developed some of the first metrics dashboards, in collaboration with Dario Taraborelli. Luke Welling continued to develop HTML email notifications and a notifications mailbox. Fabrice Florin managed the product development and release of this notification system, and coordinated its socialization on the English Wikipedia with Oliver Keyes. We're also grateful to Steven Walling and Matt Flaschen from our E3 team for developing the Welcome and Getting started notifications. To learn more, visit the project portal, read the FAQ page and join the discussion on the talk page.

Read more about our plans for this project on our Planning page for Editor Engagement Features (E2). Project tasks are being managed on this publicly-accessible Trello.

First release

For the first release of Notifications on the English Wikipedia in April 2013, our main focus will be on supporting new users, who will have most web and email notifications enabled by default. Current users will have most web notifications turned on by default, and most email notifications turned off.

Here is the first 'minimum viable product' we plan to deploy for that first release:

1. Features:

• Badge
• Flyout
• Archive
• Email notifications
• Preferences
• Bundling
• 'Mark all as read'

2. Notifications:

• Talk messages
• Page reviews
• Page links
• Mentions
• Edit reverts
• Thanks
• User rights
• Welcome
• Get Started

3. Required for launch:

• Default settings by user group
• JobQueue (Redis)
• Redis machine

4. Socialization:

• Portal/overview on en-wiki
• FAQ page on en-wiki
• Talk page (for current users)
• Survey (for new users)
• Links to these touchpoints

5. Metrics:

• Events dashboard
• Preferences dashboard

To test the current version of the tool, visit this testing page. To track our progress, check out this release checklist. To learn about product details, read these feature requirements.

Related documents

• Project Overview (en-wiki)
• FAQ (en-wiki)
• Testing tips
• Feature requirements
• User experience
• Metrics plan
• Planning page for Editor Engagement Features (E2)
• Engineering Plan
• Engineering risks
• Technical Architecture
• Notifications Prototype
• Extension page (with installation instructions)
• Notifications Slides
• Notifications Short List (work in progress)
• Notifications - Best Practices Screenshots
• Release checklist - Etherpad
• Notifications Planning - Trello
• Timeline - Google
• Bug list - Bugzilla
• Bug submission form - Bugzilla

Values

For the User:

• Being aware
• Getting a sense of activity
• Reducing confusion
• Quick actions 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

Rationale

The central tracking bug, "MediaWiki needs a sane notification system", can be found at bugzilla: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.

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.