This page is the project hub for Notifications, a new engagement tool for Wikipedia and MediaWiki sites (also known as 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 April 30, 2013 and has since been deployed on dozens more Wikipedias, with many more releases planned in coming months. The tool 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.
Goals[edit | edit source]
This new notifications system 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 Notifications slides.
Now that we have completed feature development and deployed our first release on the English Wikipedia, MediaWiki.org and Meta-Wiki, our near-term goals are to deploy on more wikis throughout summer and fall 2013. For a more detailed roadmap, check out this release plan and our Planning page for Editor Engagement Features (E2).
Problems and Solutions[edit | edit source]
We aimed 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 was developed to provide these solutions:
- Provide a unified user experience
- Inform users of important activity
- Promote editor engagement
User groups[edit | edit source]
Notifications will support several different user groups:
- new users (after registration)
- current users
For our first release, we focused on new users, who need notifications more than power users. Specifically, we concentrated on some of the first notifications which a new user can receive after creating an account on Wikipedia. We also developed some features to support power users, but we 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[edit | edit source]
Here is our project scope for the first release of Notifications on the English Wikipedia.
- focus on logged-in users
- only en-wiki and mediawiki
- only notifications about:
- your contributions
- your talk page
- build these features:
- all notifications page
- notifications preferences
- email notifications
- no support for anonymous users
- no cross-wiki support in 1st release
- no notifications for:
- your watchlist
- public announcements
- your tasks
- limited mobile support
- we may address these tasks in future releases
For more info, please refer to our related documents section.
Project update[edit | edit source]
Here's a recent project update on Notifications:2013-10-monthly:
Read more about our plans for this project on our Planning page for Editor Engagement Features (E2).
First release[edit | edit source]
For the first release of Notifications on the English Wikipedia in April 2013, our main focus was on supporting new users, who have most web and email notifications enabled by default. Current users have most web notifications turned on by default, and most email notifications turned off.
Here is the first 'minimum viable product' we deployed for that first release:
- Email notifications
- 'Mark all as read'
- Talk messages
- Page reviews
- Page links
- Edit reverts
- User rights
- Get Started
3. Required for launch:
- Default settings by user group
- JobQueue (Redis)
- Redis machine
- Portal/overview on en-wiki
- FAQ page on en-wiki
- Talk page (for current users)
- Survey (for new users)
- Links to these touchpoints
- Events dashboard
- Preferences dashboard
Related documents[edit | edit source]
- 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[edit | edit source]
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[edit | edit source]
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.