Mobile design/Watchlist view

From MediaWiki.org
Jump to: navigation, search

This document describes the mobile watchlist feature for logged in users.

Rationale[edit | edit source]

Watchlists are one of the most heavily used and important features for editors on Wikipedia; patrolling changes to watched articles is a vital activity for maintaining the quality of the content on Wikimedia projects, as well as engaging users in contributory actions. However, the default desktop watchlist view is extremely crowded with information, contains redundant functionality, and is not mobile-friendly.

By providing a mobile-friendly watchlist view, we will allow editors to easily keep track of changes to things they care about on Wikipedia, which we hypothesize will indirectly boost editor engagement and encourage more activity in experienced editors.

User research[edit | edit source]

Summary

Preliminary qualitative research suggests that experienced editors want a mobile watchlist that replicates desktop functionality, makes use of user-created watchlist enhancement tools, and allows them to act on changes that need attention.

Specific features requests
  • Navigation popup-like features: short, condensed meta-information upon hover/touch. Primarily useful as an informal assessment of the user who is making the change and whether they are a productive or non-productive contributor.
  • Diff view to see the actual change.
  • Bookmarking/saving articles as a reminder to read and/or edit.
  • An undo or revert button.
  • Links to other heavily used pages, like history and talk.

User stories[edit | edit source]

Watchlist view
  • As an experienced editor, I want to be able to track changes to items on my watchlist when I'm on a mobile device, so I can stay on top of things I care about on Wikipedia.
Drill-down view
  • As an experienced editor, I want to see key information about the user who made changes to an item on my mobile watchlist, so I can assess whether the change is likely to be high quality or low quality (vandalism, spam, test edits).
Diff view
  • As an experienced editor, I want to see the specific changes that were made to items on my watchlist, so I can assess whether these changes are high quality or low quality (vandalism, spam, test edits).
Tag for followup
  • As an experienced editor, I want to be able to tag specific changes when I'm viewing my mobile watchlist, so I can follow up on them later when I'm on my desktop and have full editing functionality.

Design requirements[edit | edit source]

  • Create a mobile watchlist view that adds value to the experienced editor's workflow
  • Present the bare minimum required information for the editor to understand the changes that have been made
  • Summarize or use visual cues to convey complex information where possible
  • Leave space for features that may come in next iterations (e.g., diff view, tagging revisions, etc.)

Project phases[edit | edit source]

2012-10:

The watchlist view has completed development and will be deployed to the Beta site in mid-November. The drill-down view and diff view are still in development but will probably be released to the Beta shortly after.


In progress[edit | edit source]

Watchlist logged-in view
A mobile-friendly feed of recent changes to articles on the user's watchlist
Drill-down watchlist view
A deeper secondary view at the revision level, presenting meta-information about what has changed and who changed it
Diff view
Integrating the difference between revisions view into the drill-down watchlist view
Read later
Article-level saving for a mobile-friendly view of the "View and edit raw watchlist" feature on desktop

Planned[edit | edit source]

Tag for followup
Revision-level tagging to highlight important changes and act on them later
Mobile-desktop watchlist integration
Making mobile watchlist changes such as revision tagging persist in the desktop watchlist view

User experience[edit | edit source]

This feature is intended to be used by experienced editors who already have many pages saved in their watchlist, and who understand the general watchlisting workflow on desktop.

Adding to watchlist
Top level watchlist view
Drill-down view with diff
Watchlist read later view

Adding to watchlist[edit | edit source]

Pages that have been added to the watchlist on both desktop and on mobile will appear in the mobile watchlist view. On mobile, users can add articles in the same way as on desktop: by tapping the watchlist star. They will receive a notification that their article has been added to the watchlist. If they tap an activated watchlist star again, the article will be removed from their watchlist, with a corresponding message.

Flow
  1. User is logged in and reading Wikipedia
  2. User sees an article she would like to add to her watchlist
  3. User taps watchlist star in the top righthand corner of the chrome
  4. Watchlist star icon activates (visually marked by a fill) and a notice appears, letting the user know that the article was added to her watchlist
  5. Notice disappears after 2 seconds, or when the user taps on the dismiss button in the corner of the notice or taps outside the notice
  6. User taps the watchlist star again
  7. Watchlist star icon deactivates (returns to previous state with no fill), and a notice appears letting the user know that the article was removed from her watchlist

Viewing pages[edit | edit source]

Users can view changes to watched pages by navigating to the watchlist view. Information will be presented relative to user's current time, with most recently changed pages at the top and less recent changes at the bottom. From this view, the user will be able to see the name of the page that changed, the time it changed, and the user who made the change, as well as the edit comment. Long article names and edit comments may be abridged and can be accessed in the drill-down watchlist view.

Flow
  1. User is logged in and has articles on her watchlist
  2. User taps on the lefthand navigation icon and selects the Watchlist menu
  3. User is taken to a mobile-friendly list of recent changes to articles she has watchlisted
  4. Tapping on an arrow in the righthand corner of each change takes the user to the drill-down view with additional information about the change
  5. User can scroll through 3 days' worth of changes
  6. Tapping back from the watchlist view takes the user to the last page she was on before activating the lefthand navigation menu

Drill-down view[edit | edit source]

Users will be able to tap on any revision and go to a separate page, where a deeper view of the changes (full article name and edit comment, bytes added/removed, and difference between previous and current revisions) will be presented. From this view, the user will be able to take actions such as tagging the revision for followup or undoing a change.

Flow
  1. User is logged in and is viewing pages on her mobile watchlist
  2. Tapping the arrow to the right of any change takes the user to the drill-down view of the change
  3. User can see additional information about the change and the user who made it
  4. And eventually user will be able to take action (such as tagging for followup) from this view
  5. And tapping back takes the user back to her top-level watchlist view

Read later[edit | edit source]

Users will be able to see a list of all articles that they have watchlisted, so that they can easily access articles they saved to read later, not just ones with recent changes.

Flow
  1. User is logged in and is viewing pages on her mobile watchlist
  2. User can see a list of all articles on her watchlist and can quickly remove items from the list
  3. User can see some additional information about each article, such as a snippet of the first sentence and the time when it was last modified
  4. User can navigate directly to any article on the list
  5. User can switch between this and the "recent changes" view

Mockups[edit | edit source]

Developer card wall[edit | edit source]

Implementation[edit | edit source]

In-progress work in branch at https://github.com/brion/MobileFrontend/commits/watchlist Will squash and merge once it's got a little more work on it. --brion (talk) 00:55, 23 October 2012 (UTC)