Research:Cross-wiki notifications user research
The goal of this study is to understand how active Wikimedians who regularly edit multiple projects use the current suite of notifications feature to keep track of events that have occurred since their last visit to a wiki.
- view notifications of events that occurred on multiple wikis simultaneously
- view all of their notifications in a redesigned notifications page with faceted filtering
- mark notifications as read and unread
- view related notifications in bundles
We will also be testing new UI elements in the notification panel.
- 1 Methods
- 2 Findings
- 2.1 Round 1: Cross-wiki notifications
- 2.2 Round 2: Notification panel and notification page redesign
- 2.2.1 Secondary actions
- 2.2.2 Muting and volume control
- 2.2.3 Bundled notifications
- 2.2.4 Mark as (un)read
- 2.2.5 Notification page and settings
- 2.2.6 Other findings
- 2.2.7 Recommendations
- 3 Subpages
- 4 References
Interviews with 3-5 editors will involve questions that focus on understanding their current practices around notification configuration, monitoring, and triage, as well as a series of simple tasks and questions intended to evaluate a prototype interface for cross-wiki notifications.
Round 1: Cross-wiki notificationsEdit
The results of the first round of user studies are presented in this slide deck.
Round 2: Notification panel and notification page redesignEdit
Actions providing access to related information can facilitate user navigation and simplify the notification messages. For example, showing the user name of the author of a topic as a secondary action allows users to access the user talk page, and allows for the notification to avoid including it just for that purpose.
- all participants were able to discover the secondary actions menu when prompted (unlike the first round, where discoverability was identified as an issue)
- inconsistency in the actions listed in the menu may be an issue
- some secondary actions (e.g. "mute future revisions to this page") may interact with watchlist in poorly understood ways
- several participants expected to see a diff link under secondary actions, but it was only available in some cases
Muting and volume controlEdit
Being able to mute (or subscribe to related events) right from a related event may help users to easily get the notifications that are most relevant to them.
- several participants commented that the "sound" analogy was confusing (or would be confusing to others), but all correctly interpreted it after reading the action description
- participants without extensive experience with Flow thought that muting a topic was akin to removing a page from their watchlist
- the functionality of "adjust notification volume" was not fully tested, as the prototype did not provide a settings page
Expanding the current bundles can be useful when individual items require special treatment.
- expand bundled notifications was discoverable
- the name of the participant who posted each message was useful, the preview may or may not be
- this functionality was only tested with messages, if other notification types are going to be bundled as well, more testing may be needed
Mark as (un)readEdit
For notifications the user marked as read but still need some associated work, being able to mark them back as unread may be useful.
- people have no problem finding and understanding the "mark as read" option, and most are quick to find the option to mark individual messages as unread.
- several users seemed to have a hard time visually distinguishing read and unread messages, because of the low color contrast between them.
Notification page and settingsEdit
Some changes beyond the panel have been also included to get some initial thoughts on some early ideas for the notification page or the notification settings.
- Link to "all notifications" was discoverable.
- Faceted search on the left rail is not very discoverable. People don't know they can click these options to filter their notifications, and they have varying interpretations of what these options mean.
- Several participants first gravitated towards the search box and the "View" options dropdown when asked to find reverted edits by a user, but neither of these elements were active in the prototype, so their functionality and usability was not tested.
People love one-click ThanksEdit
Several participants were happy to see that they could thank someone for edit-related actions from within the Notification Panel. They wanted to be able to do this for more types of actions, including page reviews, talkpage messages and reverts!
Some wording was confusingEdit
The wording of several menus and items was ambiguous or confusing to many participants. Examples:
- Watch new activity (for Flow notifications) was confusing because people associate the term "watch" with watchlists, and "activity" is an ambiguous term. Several participants were confused about why they were being prompted to watch a discussion--if they were getting a notification, wasn't the page already on their watchlist? The filled-in star icon next to "watch new activity" also created confusion, since a filled-in star indicates that a page is already on your watchlist in the existing Mediawiki interface.
- View settings for all events was confusing to several participants. They did not seem to associate the word "event" with notifications.
- View reverted edit was confusing to one participant because it was unclear to them what they would view--the reverted edit, the reverting edit, or the diff?
- This page (in Mute in the secondary actions for Flow discussions) was confusing to several participants, because it was unclear which page was being referred to.
- Left you a message and New topic was created are the same kind of notification (one refers to your user talkpage, the other to any other talkpage), but worded differently.
- Mixing active and passive voice across notification types (e.g. Cesio left you a message vs Your edit to plants in space was reverted) may cause confusion or make it harder for people to quickly scan through their notifications.
Diff not clearly and consistently availableEdit
Most participants reported a desire to view the diff for any edit-related notifications (including thanks notifications) and even logs for page review actions. But they were unsure where to click to view the diff: on the timestamp? in the secondary actions? by clicking the body of the notification?
The profile icon and username placed in the lower-left of each notification links to the notifying user's page. People seemed to like and expect this, but several also wanted one-click access to the user's talkpage.
- make diff, talkpage links consistently available for all relevant notification types
- revise design of faceted filter panel on notification page
- make identified changes to confusing/inconsistent wording throughout the interface
- increase color contrast between read and unread notifications
As design and development work progresses, these recommendations should be taken into consideration.
- avoid creating (or suggesting) interactions between watchlist and notification panel, settings
- Focus on complementing, rather than duplicating, current watchlist functionality
- Consider providing user education tips upon feature activation, to help adopters understand new functionality (cf. New User Education in VE)
- Develop and publish detailed notification design guidelines to ensure consistency among current and future notification types