Reading/Reading Lists

Recently, the various Reading teams have found our work converging around a number of related feature sets. These features and projects will likely continue to have separate implementations, but we want to consider them as a whole so that we can share infrastructure, personas, and learnings across products.

Why
There are a number of different things that have come up around the same time that have caused us to look into this.
 * New Readers offline focus, with features being extended on both mobile web and Android.
 * Apps synced bookmarking and offline features.
 * Doc James community wishlist proposal, being worked on by the Reading Android team.
 * Gather is dead
 * Book creator (OCG) is dying and needs to be replaced/deprecated

What

 * multiple features built for specific populations of users (or potential users) across all three platforms (web, Android and iOS)
 * shared backend requirements and development
 * shared product glossary
 * shared design language

How

 * Meetings! We kicked off this discussion during the Reading team's onsite in March. From there, product managers have met to continue to dig in.
 * Develop understanding of products/features vs. user stories vs. personas
 * Identify and specialize personas from New Readers and previous Design Research work, who have needs relating to downloading, bookmarking, sharing and reading collections of articles
 * Generate a list of {use-cases|features|stories}
 * Create a matrix of each persona X each story
 * Assign priority that persona would give that story
 * Wikif-y the chart!
 * Extract shared requirements for backend needs
 * Begin design process for initial features for initial platform (Android)
 * ...tbd...
 * PHAB TICKETS?

Background

 * Understanding Android offline collections. A slide deck prepared by User:RHo (WMF) to help flesh out understanding
 * Link to copied versions of etherpad notes
 * book creator?
 * ...what else??

How does Watchlist fit in?
The Watchlist is another way that users of Wikimedia projects collect groups of articles together, in this case to notify editors of changes to those articles. Our work will not build on the Watchlist infrastructure, but we are thinking about how Watchlist fits into the user experience for readers and editors alongside other features.

Our goal is to coordinate across reading audience for lists related to consumption, not a single, complex mega-solution for all lists of articles. Watchlist has a complex technical and usage history and would significantly increase scope of these efforts beyond feasibility.