Reading/Web/Projects/NewMobileWebsite

= Introduction =

Each day, more than 30 million users access Wikipedia through our mobile website.

The mobile web version of MediaWiki has been around for X years, and in that time, devices have evolved. The internet has fundamentally changed to support more people all over the world on an enormous variety of devices with varied connection, screen size, languages, and more. The internet has fundamentally changed and with it, so have the expectations of its users and their needs.

Our current infrastructure limits our ability to reach and connect to these users, both as readers and as potential future contributors, not only in terms numbers, but in terms of background. In other words, we’re limiting our community to a closed set instead of exploring the globally diverse population our movement strives to support.

Reaching More People Worldwide
Through research in 2016, we learned that many people who are interested in using Wikipedia are not currently using it due to cost and access barriers. For example, in Nigeria, the cost of internet would need to decrease 97% to be widely affordable - and that impacts how people use MediaWiki sites. Over a quarter of people we surveyed in Nigeria who are interested in reading Wikipedia reported that they weren’t able to due to the cost of data. In a more recent phone survey in Iraq, 81% of Wikipedia readers reported using the internet less due to the cost of data. In the last few years, we’ve made great strides towards decreasing the size and load time of the site, but we believe that we can do more with a more significant architectural change.

Beyond that, people all over the world lose connection from their mobile phones for any number of reasons - they go into a tunnel, leave a wifi access point, or the power goes out. New technologies can enable us to continue to support people in those situations and more - we could even imagine providing access to articles completely offline.

Supporting varied audiences
Our users cover the spectrum of almost every device and browser, yet our list of fully supported browsers is limited. The content and user experience we currently provide to these browsers is often faulty and the level of specificity of the fixes so high that we often let users live with the bugs rather than spending the effort of fixing them on a per-browser, per-bug basis.

Cost of development and design
Our current approach often relies on duplicating efforts on the backend and frontend, as well as balancing adding functionality to mobile and desktop separately on the same stack. This has lead us to large amounts of tech debt and increased risk when making changes to support new and existing users. These risks increasingly slow down development over time, while increasing the amount of cleanup we are accountable for. It’s inefficient.

Creating a responsive experience for larger screens
Currently, it is difficult to experiment and test ideas for an improved tablet or desktop experience without creating large changes for all of our users.

Technical Issues
Below is a summary of the main technical issues identified with our current mobile website: https://phabricator.wikimedia.org/T156259 https://phabricator.wikimedia.org/T156263

Identifying Potential Solutions
Next steps
 * Team set identifying solutions as a goal for Q3 of the fiscal year 2016-2017
 * Over the course of the quarter, two solutions were proposed - a refactor of the website and the building of a new website
 * Each solution was weighed against the problems identified above
 * Each proposed solution was discussed in terms of pros and cons within the reading web team as well as other WMF teams
 * The rough formulation of this proposal was drafted
 * We would like to reach out to our communities for thoughts and ideas on the proposal, including alterations and additions

= Proposal =

We propose to rebuild the mobile website with a focus on:
 * Optimization for a modern browsing experience
 * Connection management - smooth transition for short bursts of low connection
 * Data efficiency
 * Providing the ability for a fully offline experience
 * Creating an architecture that would inform decisions across Wikimedia platforms in the future

High-Level Requirements

 * We are proposing to build an offline first application, which focuses on users with low connectivity and intermittent connections. This means that, while browsing and reading articles on Wikipedia, users will have a smooth transition when they experience intermittent connectivity - they will be able to continue reading articles and to navigate within their session.  However, they will not be able to access any articles they have not previously viewed within that session.  In particular:
 * Readers must be able to read articles when in conditions with low connectivity or no connectivity
 * Readers must be able to navigate through the articles they have viewed within a session in conditions with low connectivity or no connectivity
 * Readers must be aware when articles do not load properly due to low connectivity
 * Readers must be able to access the menu when not connected
 * When users attempt to select articles while offline, the system must display the appropriate messaging indicating that the user has no/low connectivity and might not be able to access the article


 * The mobile website must be optimized for reading on screens of all sizes, including all tablets and desktop screens:
 * The mobile website must be modular and responsive


 * Standardizing our service layer for content consumption
 * Sharing infrastructure and efforts with Apps teams
 * Using services to improve performance of pages


 * We will be working editing team to create a smoother mobile editing experience:
 * All editing feature currently available on the mobile website will be available on the new mobile website
 * The goal of the new mobile website would be to allow editors full access to all editing functionality.


 * We would like to allow users to flag and save articles of interest for later consumption. Ultimately, our goal is to allow these articles to be accessible through all platforms, with the possibility of allowing the articles to be accessible offline:
 * Saved articles will not be available for offline reading upon first iteration
 * Users will be able to flag articles for later consumption
 * Users will be able to download articles in PDF format
 * Users will be able to access their saved articles when logged out or logged in
 * Users will be informed that their list of saved articles when logged out may be lost


 * Efficient with user’s data (i.e. more efficient than currently)
 * Account creation - focus on the reader as a logged-in user
 * Reading lists syncing will require more users to create accounts, which will necessitate a reevaluation of the account creation workflow

Lite Experience
While the above solution is fitting for many users with low connectivity, it can only be implemented on modern browsers. We would like to explore creating a lite solution for browsers which will not support the new mobile website. This lighter experience must:
 * include all relevant content
 * be available to users based on their connection and preference
 * be opt-in
 * be fast and cost-efficient
 * be stylistically consistent with the full-featured experience

Technical Requirements
We will be building out the technical requirements for the project over the next few months. Check back for updates!

Future Offline Functionality
After building list functionality, we would like to test and explore the opportunity to deliver content while users are fully offline:
 * The mobile website must provide offline support for user selected articles
 * Users may access offline articles by flagging each article they would like to read offline from the article page
 * The article will be saved to a list of saved (offline) pages
 * Users must be prompted to save a link to their offline articles to their home screen
 * Offline support must be available for all browsers that support service workers

Roadmap Outline
Q3 (March 2017): Product plan and architecture decisions Q4 (Apr-Jun 2017): Initial development stage Q1 - Q2  (Jul 2017 - Dec 2017): Q3 (Jan-March 2018): Q4 (Apr-Jun 2018):
 * Development plan
 * Requirements for first iteration
 * (if time) requirements for additional/new functionality
 * Define MVP features
 * Setting up initial Phabricator tasks
 * Set up development infrastructure
 * Repo
 * Test infra
 * Deployment
 * Scaffold
 * Start development towards MVP
 * User testing on new features
 * Beta and small wiki test
 * Open question: New domain and user testing or full rollout over m.wiki...
 * Continue developing extended feature set
 * Large wiki test (TBD)