Reading/Web/Projects

Below is a list of our current and past projects. For direct feedback on a particular project, please visit the associated project page.

Current Projects


Desktop Improvements
Our desktop interface has been changing over time, yet since the introduction of the Vector skin, most of these changes have been led by volunteers and consolidated into prototypes, user scripts, gadgets, and volunteer-led skins. We think it's time to take some of these ideas and bring them to the default experience. Over the next couple of years, the readers web team will be researching and building out improvements to the desktop experience based on research and existing tools. Our goals are to make Wikipedia more welcoming to new readers and editors, and easier and quicker to use for all (both newcomers and veteran editors). The new skin is named "Vector 2022" 

Advanced mobile contributions
The mobile skin "Minerva" causes certain editing and contribution workflows to be unavailable. The skin hides certain pages as they were not optimized for mobile devices and increased the complexity of the interface. Their absence prevents contributors from being able to edit and moderate from the mobile web. The Readers Web team has listened to requests from communities and has an increased focus on contribution workflows for the upcoming year. The team is working on exposing currently unavailable pages to provide better editing functionality on the mobile web. Our plan is to build this as an opt-in feature which editors can enable. We believe this will decrease the necessity of switching between the desktop and mobile sites while on a mobile device and provide a better mobile editing experience.

Invest in the MobileFrontend & MinervaNeue frontend architecture
The mobile website (specifically MobileFrontend and MinervaNeue codebases) is technologically dated and has accumulated technical debt through the years. We will be paying down technical debt, improving the frontend tooling and code, and completing the MinervaNeue split from MobileFrontend to finally make them better participants in the MediaWiki ecosystem.

Search Engine Optimization
We began exploring schema.org markup within our articles as a means of providing search engines with more confidence within the context of ambiguous queries as well as with the general goal of increasing the amount of structure data across our sites overall. We began by adding the sameAs meta property to Wikipedia articles which pointed to the corresponding Wikidata entity. To determine the success of the changes, we ran an A/B test on 50% of articles across most of our projects (phab:T206868).

Offline Content Generation and Printing
Our current PDF rendering service, the offline content generator, is no-longer maintainable. We are working on selecting a suitable replacement for the service that allows for expanded functionality, such as the ability to print tables, as well as new print and PDF styles for the desktop website, which focus on increased readability.

We are also working on improving our print styles for desktop with a focus on better readability.

Mobile Page Issues
Currently, details about issues with page content do not display on the mobile website, making readers unaware of the reliability of the pages they are reading. Restraining this information from users can be problematic, especially in cases of more severe issues, such as hoax articles or articles considered for deletion. We would like to improve the treatment of page issues on the mobile website to include a description of the nature of the issue itself, as well as the severity of the issue. Our hypothesis is that these changes will help users make better judgements on the reliability of the pages they are reading.

Page Previews
Note: while we are not currently working on expanding the functionality of page previews, Previously known as hovercards, the page previews feature allows users to gain context on the subject they are currently without requiring a new page to be opened. With Page Previews, whenever a reader hovers over a link to another article, a short summary of the subject and an image (if available) is displayed. The user can then decide whether they wish to visit that subject more thoroughly before continuing with the current article.

Mobile PDFs
Based on the findings of the New Readers team, we learned that users are increasingly getting information online, and then sharing or consuming it offline. In terms of mobile devices, this often means that users are taking screenshots of useful information, or saving an article as a PDF to read later on their phones. Our older print styles did not account for reading on mobile devices - they focused on paper printing. Over the course of the next few quarters (Q4 (Apr 2017 - Jun 2017) and Q1 (July 2017 - Sept 2017)), we will be working on the following:
 * Updating our print styles for mobile devices to account for offline consumption, making them easier to read and navigate, as well as accounting for missing crucial information such as article title and branding.
 * Focusing on mobile PDFs - allowing users to download PDFs of existing articles directly from the article page

Mobile Web Settings
The settings page on the mobile website did not previously have a consistent template or layout. In addition, the descriptions for many of the features which beta mode enabled were not displayed on the old settings page making users unaware of the impact in functionality that enabling beta mode entailed. We improved the page design, added descriptions to our beta features and improved and promoted the font changer and expand features by default settings options.

Related Pages
Related pages direct users to content related to the page their are currently reading. Our hypothesis is that when readers are offered suggestions similar to the topic they are reading about, they will gain further exposure to a subject of interest or a larger perspective on a new subject.

Lead Paragraph Move
Unlike the desktop website, where infoboxes have secondary placement to article text, on the mobile website infoboxes appeared in primary position prior to the beginning of the article content. This placement exposed readers to details on a subject prior to gathering an introduction to the subject. We will be working on moving the lead section of an article to appear prior to the infobox, allowing easier access to context.

Improving Site Awareness and Branding
Based on research from the New Readers program, we've learned of a lack of brand awareness in certain parts of Wikipedia's audience - people were reading Wikipedia without realizing it. Currently, the MediaWiki MobileFontend UI does not contain obvious clues for identifying the name of the project being accessed. For instance, if you are viewing the mobile-formatted German Wikipedia article on Demut, the only indication you are on Wikipedia is the light gray placeholder text in the search box and a single reference in the page footer. This project intends to inform the readers that content is coming from Wikipedia.

In-page Navigation
On the mobile website there is currently (often) a lot of scrolling required to move between sections. For example: if I scroll halfway into a long section (e.g. China#Geography), and I want to get into a different section, I have to scroll either to the top of the section to collapse it, or to the bottom of the section (if I happen to know the section I want to go to next is below it). The goal of this project is to help readers navigate between different sections of pages more easily, so that they can target the content they are most interested in with less navigational scrolling. This could be achieved either by providing an easily accessible table of contents, or some other UI component that enables readers to easily move between sections.

Reimagining the mobile website
The mobile web version of MediaWiki has been around for 6 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. We are launching an effort to adapt and reimagine our mobile website to allow for improving the experiences of existing readers and accounting for the needs of new readers, focusing on performance and offline support.

Updates by Quarter
Quarter 4 (Apr 2017 - Jun 2017) Quarter 3 (Jan 2017 - March 2017) Quarter 2 (Oct 2016-Dec 2016) Quarter 1 (July-Sept 2016)
 * Quarterly Goals
 * Quarterly Goals
 * Reading/Quarterly planning/FY2016-2017/Q2
 * Reading/Web/Projects/New Readers 2016-17 Q2

✅ Improve in-article language switching on mobile web

✅ Lazy loaded images to stable ( Reading/Web/Projects/Barack Obama in under 15 seconds on 2G )

Roll out of Wikidata description taglines (on all but top 6 wikis)

Quarter 4 (April-June 2016)

Make Wikipedia more accessible to 2G connections with fast API-driven web experience in mobile web beta Quarter 3 (January-March 2016)
 * This will continue and finalise the work of Reading/Web/Projects/Barack Obama in under 15 seconds on 2G with the goal to start making tangible impacts on the page load time for users on 2G connections.
 * Improve in-article language switching on mobile web
 * A few changes need to be made relating to user research.
 * Hovercards to production on certain wikis

The focus of the reading web team in this quarter was primarily on the following two tasks:
 * Make Wikipedia more accessible to 2G connections with fast API-driven web experience in mobile web beta
 * This continued the work of Reading/Web/Projects/Barack Obama in under 15 seconds on 2G with the goal to start making tangible impacts on the page load time for users on 2G connections. The progress made during this quarter is documented.
 * Improve in-article language switching on mobile web
 * ✅ Wrap up the user page improvements begun at the end of quarter 2.

During this time we plan to support teams that want to use the QuickSurveys extension - the research and data team would like to identify segments in the Wikipedia reader population   and the discovery team would like to generate a model for user satisfaction with search results based on qualitatively-validated quantitative data (see phabricator).

If time allows we would like to explore the following stretch goals:
 * Rolling out related pages to mobile stable.
 * Rolling out Hovercards to desktop stable

We are experimenting with tracking our work in the Phlogiston tool.

Quarter 2 (28th Sept-December 2015)

The focus of the reading web team in quarter 2 is primarily on the following three tasks: Quarter 1 (July 6th -Sept 25th 2015)
 * Related pages
 * Reading/Web/Projects/Link preview
 * Reading/Web/Projects/Barack Obama in under 15 seconds on 2G
 * We created Extension:QuickSurveys to allow us to run surveys on our projects and learn more about our readers.
 * We ensured that the first paint on the mobile site was better than it was on desktop.
 * We got browser tests running on a per-patch basis for all our projects.
 * We removed the alpha experimental mode of the mobile site, to simplify our experiments.
 * Reading/Web/2015 Q1 Feature stabilization

Projects in previous team incarnations
Quarter 4 (2014) Quarter 3 (2014)
 * Extension:Gather
 * The Browse experiment
 * Extension:WikiGrok
 * Extension:WikiGrok

Experiments
Experiments from the Reading Web Team.