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
 * Discussion of pros and cons within the reading web team as well as other WMF teams
 * Formulation of proposal
 * RfC for thoughts and input

= 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

High-Level Requirements

 * Offline-first application - back button, link clicking, refresh, menu
 * Standardizing our service layer for content consumption
 * Sharing infrastructure and efforts with Apps teams
 * Harmonizing with editing/VE roadmap on mobile
 * Working with the editing team to create a smoother mobile editing experience
 * Build saved articles with the potentially of syncing articles across devices
 * Saved articles will not be available for offline reading upon first iteration
 * Desktop and larger screen experience - focus on responsiveness and modularity
 * 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

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)