Reading/Web/Projects/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. Furthermore, we hypothesize that exposing the nature of these issues will make readers more curious about the inner workings of Wikimedia projects, potentially increasing the likelihood of their involvement as contributors

Introduction
When Wikipedia articles are hoaxes, considered for deletion, missing citations, or don’t meet Wikipedia standards, they often feature a large coloured box above the article notifying readers and editors of the issues at hand.



These notices are actually special templates that are inserted into the content of the article. Each notice in the article name-space has it’s own template, and each template is based on a meta-template called (Article message box) which in turn is based on a Lua module called Module:Message box. Other MediaWiki name-spaces (like categories and talk pages) have notices that are specific to their name-space as well.

These notices have existed for over a decade and have many conventions around their usage. Because these notices are maintained by editors, every Wikipedia language community is free to adopt or invent their own notices, specific to the needs of their Wikipedia or MediaWiki project (Commons for example, has a wide array of licensing notices, while Wiktionary uses entirely different notices altogether).

The broad range and diversity of these notices makes them hard to standardize (however, such an effort successfully in 2007).

This refresh occurred before the modern mobile web even existed, and despite later efforts by the WMF to bring these notices into the mobile web, they are still not very mobile friendly. As a starting point, this proposal will focus on improving notices in the article name-space, based on the template.

Current mobile treatment
Currently, instead of rendering the entire template, mobile Wikipedia shows a small grey link with the text "page issues" below the title of an article. When clicked, an overlay with a list of the issues appears. Some notices have text for a "compact" version of the template, If available, only text for the compact version is rendered.

Limitations
As pointed out in the Village pump proposal below, the small "page issues" link doesn't convey the importance of certain notices, such as the "hoax" notice, which is prominently visible on desktop.

Technically, the current implementation depends heavily on modifying the HTML generated by the templates. Even slight changes to the template HTML can break this feature on mobile. Also, because these templates differ across languages, the current implementation doesn't work on all wikis. French Wikipedia for example, refreshed their message boxes in 2016 and now uses entirely different templates than English Wikipedia ( Liste de bandeaux de maintenance d'articles). Because of this change, French alerts are not visible on mobile Wikipedia.

English Wikipedia Village Pump proposal
In September 2016, a proposal to expose page issues on the mobile website was approved with the clear consensus that some warning templates should be visible on mobile.""If an article is up for AfD and flagged as a possible hoax with insufficient medical sourcing, any reader visiting that article on a computer is greeted by three large red and orange boxes at the top of the page, one with a cautionary stop sign... If a reader instead visits the same hoax medical article on their phone... they just get two tiny grey words "Page issues" under the article title..."" Link to English Wikipedia Village Pump proposal

Objective
The goal of this project will be to change the visual styling of page issues on the mobile website to improve awareness of particular issues within an article. We will also be dedicating time to working with our communities to provide best practice guidelines for styling templates in a way that will result in the optimal formatting of issues on mobile site without changing the treatment on desktop site.

This goal maps to Program 2, Objective 1 of the annual plan for Readers: Enable readers to gauge the quality and reliability of an article during their reading experience

Workflow

 * 1) User goes to page with page issue
 * 2) User selects page issue
 * 3) User is navigated to page issue details

General
Mobile page issues will display the following:
 * Issue description
 * Short descriptions for the issue will be used where available
 * If no short description for the issue is available, we will display the beginning of the long-form issue description
 * Issues length for both short and long descriptions will be restricted based on the space constraints
 * Issue severity
 * Severity - severity will be set according to ambox type( https://en.wikipedia.org/wiki/Template:Ambox#type ) as follows:
 * Severe: type=speedy, type=delete
 * Medium: type=content
 * Low: type = style
 * Notice: type = notice, type = move, type = protection
 * All other templates will display with normal severity
 * Each severity level will have custom appearance and position within the page
 * If an issue contains links to other pages, these links will be stripped from the page. The links will appear on the page issue detail modal

Single issue

 * For pages with single issues, issue severity will be derives from the template as defined above
 * Example: if template has level medium, the article https://en.wikipedia.org/wiki/Free_China_(Second_Sino-Japanese_War) will have a single page issue appear at medium level

Multiple issues

 * Issue severity level will be derives from the severity levels of the individual issues
 * If an article contains the template, the issue level of the article will be the highest issue level available
 * Example: if template has level high, the article https://en.wikipedia.org/wiki/Chinese_unification will have issues appear at high level
 * Each multiple issue level will receive unique copy, appearance, and position within the page

Section issues
For the initial implementation of this project, we will not be displaying issues with individual sections on the mobile website. We will come back to this once we have completed the remaining changes.

Updates to the page issue modal
In addition to the changes proposed above, we will also be making the following changes to the page issue modal. These will be the first changes we plan on making for the project and should be available the week of March 26. The goal of these changes is to expose more detail about the page issue itself, as well as to provide information on how users can fix these issues.

Feature Evaluation
To prove the success of these changes, we would like to consider the following questions:
 * Is there an increase in clickthrough based on the new issue treatments (from the article page to the issues modal, from the issues modal to details about issue type)?
 * Do edits increase with page issues as referrer?
 * Does the new issue treatment changes affect issue removal rates?
 * Does clickthrough depend on the severity of each issue?
 * What coverage do we have for specific issues over time - i.e. how many issue templates contain short descriptions, how many issues templates contain severity?

Technical challenges to improving Ambox “mobile friendliness”
The technical challenges of improving Ambox templates can be grouped into a few buckets (as described below), but they all boil down to inconsistency. The output of 's is inconsistent across languages, inconsistent across different types of templates, and inconsistently placed inside the article content, without a consistent machine-readable way of extracting the template content.

Areas of concern

 * Text length
 * The text of many Ambox messages is very long and not suitable for mobile devices.
 * Desktop specific HTML
 * The templates make heavy use of tables for layout, which doesn't work on mobile.
 * Language specific HTML
 * The  HTML output is different across languages, making it nearly impossible to consistently extract the message content and repurpose it for mobile.

Use the TemplateStyles extension to create mobile friendly template CSS
For future iteration

Use Page Content Service to display page issues
https://phabricator.wikimedia.org/T172002

Modify MobileFrontend/Minerva CSS to accomodate existing template markup
This solution would work within the existing template structure and probably only on English wikipedia.

Many templates contain a CSS class that marks text as. Using CSS, we could hide this extra text and only present users with the "summary" text. This is the same text that is currently presented in the page issues overlay. Many templates, notably deletion templates, do not have this CSS class, so the issue of text length would have to be address on a per template basis.

A demo of what modifying the CSS might look like is available here https://people.wikimedia.org/~jdrewniak/page_issues_css/index.html.

Add structured HTML attributes to Ambox templates
This solution requires modifying templates

As mentioned above, the HTML produced by the templates varies widely. It can change at any time and in any language. However, we shouldn't hinder these changes, but rather ensure that they can be adapted to new contexts, such as mobile. Adding semantic attributes to the HTML could provide us with the necessary "hooks" to extract the Ambox content and present it in an appropriate way on mobile. We could provide a standard set of attributes that template editors can insert into their templates, across any template or language. These attributes could be "machine readable" which means they could be consumed by parsers or extracted into APIs like the Page Content Service, for consumption by the mobile apps. These semantic attributes would be invisible to end-users, and would not effect the appearance of existing templates.

Semantic HTML attributes fall into the category of "microformats" which are considered part of the semantic web. The vision of the semantic web is to extend HTML with the ability to express very specific types of data, in a way that is machine readable. In this scenario, we could extend the Ambox HTML with attributes that would identify the templates as "message boxes" with various properties, like their priority, date, and actionable steps. This information could then be parsed by the mobile site or app and presented to end-users in a mobile friendly fashion.

We could invent our own standard for how to create these semantic attributes, but there already exists a W3C recommended specification called RDFa which standardizes on how to use attributes to add rich meta-data to HTML.

The RDFa spec defines rich data structures as "vocabularies" (sets of properties that define an data structure). We can define a custom vocabulary that describes the properties of a "message box", and use those properties in the HTML attributes.

As an example, RDFa uses HTML attributes such as            that can be added to templates in the following way:

Inventory of mobile-friendly page issues
While the changes proposed above will improve most page issue templates, templates with defined short descriptions (contain text marked as "hide when compact") and templates with defined ambox type will receive specialized treatment (the shorter more mobile-friendly form of the text will be displayed as well as visual indicators for the severity of the issue).

Hide when compact
We performed an inventory of templates that contain text marked "hide when compact" to determine coverage for these changes. The following were our results (documented in T189132)

Method

An extensive inventory of "page issue" templates was taken across a variety of languages using the mediaWiki API and this script. The script essentially parses templates that belong to a specific category. On English Wikipedia for example, it parses all the templates that are members of the category Category:Article message templates. The templates are then rendered in an HTML table with CSS added to see which can be made compact or not. A sum of the compact templates is also generated.

Disclaimer

This method works for languages that actually have a category for all "page issues". Not all languages do, some only have more specific categories. Also, only the top-ten wikis were used in this report.

Findings There were no hidable selectors found for templates from Wikipedias.
 * On English Wikipedia - 364 out of 377 templates had hidable elements. (92%)
 * hiding with a  selector.
 * From category: https://en.wikipedia.org/wiki/Category:Article_message_templates
 * On Chinese Wikipedia - 115 out of 124 templates had hidable elements. (93%)
 * hiding with a  selector.
 * From category: https://zh.wikipedia.org/wiki/Category:條目訊息模板
 * On Russian Wikipedia - 157 out of 207 templates had hidable elements. (76%)
 * hiding with a  selector.
 * From category: https://ru.wikipedia.org/wiki/Категория:Шаблоны:Предупреждения
 * On French Wikipedia - 78 out of 113 templates had hidable elements. (69%)
 * hiding with a  selector.
 * From category: https://fr.wikipedia.org/wiki/Catégorie:Modèle_de_bandeau_d%27article
 * On Japanese Wikipedia - 4 out of 19 templates had hidable elements. (21%)
 * hiding with a  selector.
 * From category https://ja.wikipedia.org/wiki/Category:記事メッセージボックス
 * a larger sample size should be investigated.
 * Spanish - https://es.wikipedia.org/wiki/Categor%C3%ADa:Wikipedia:Plantillas_de_contenido
 * Italian - https://it.wikipedia.org/wiki/Categoria:Template_di_avviso
 * Polish - https://people.wikimedia.org/~jdrewniak/page_issues_inventory/pl.index.html
 * Portuguese - https://people.wikimedia.org/~jdrewniak/page_issues_inventory/pt.index.html
 * German - https://de.wikipedia.org/wiki/Kategorie:Vorlage:Wartungsbaustein

Conclusion

Half of the top-ten Wikipedia had hidable elements, and the other half didn't. On the wikis that did have hidable elements, they were hidable for a majority of the templates.

Sources

This script which generated these tables.