Reading/Web/Projects/Mobile Page Issues

Currently details about content issues do not display on mobile Wikimedia sites. This leaves readers unaware of the reliability of the pages they are reading. Hiding this information from users can be problematic. This is especially true in cases where imporant issues, such as hoax articles or articles considered for deletion, is hidden.

The Reading web team would like to improve the treatment of page issues on the mobile website. The goal is to include a description of the nature of the issue itself, as well as the severity of the issue. These changes will help users make better judgements on the reliability of the pages they are reading. Showing these issues could also make readers curious about how Wikimedia projects work. This could potentially increase the likelihood of their involvement as contributors.

Introduction
When articles have issues, 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 inserted into the content of the article. Each notice in the article has it’s own template, and each template uses a meta-template called (Article message box). Ambox uses a Lua module called Module:Message box. Other MediaWiki namespaces 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. Contributors maintain these notices. Every language community is free to adopt or invent their own notices, specific to the needs of their project. For example, Commons has a wide array of licensing notices while Wiktionary uses entirely different notices.

The broad range and diversity of these notices makes them hard to standardize. One happened in 2007 on the English Wikipedia.

This refresh occurred before the modern mobile web even existed. 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 that based on the template.

Current mobile treatment
On the current mobile Wikimeida sites we don't render the entire template. Instead we display 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. When available, only the text for the compact version is displayed.

Limitations
The current implementation depends on modifying the HTML generated by the templates. Slight changes to the template HTML can break this feature on mobile. The current implementation doesn't work on all wikis. Templates are different across languages. For example, French Wikipedia refreshed their message boxes in 2016. They now use different templates than English Wikipedia. Here is a list of their maintenance modules. Because of this change, French alerts are not visible on mobile Wikipedia.

There was a proposal on the English Wikipedia in 2016. The proposal argued that the the small "page issues" link doesn't convey the importance of certain notices.

English Wikipedia Village Pump proposal
In September 2016, the community approved a proposal to expose page issues on the mobile website. There was 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...""

Objective
The goal of this project is to improve awareness of particular issues within an article on the mobile web. This will be accomplished by changing the visual styling of page issues.

The team will work with communities to provide guidelines for for styling templates. This work will result in the optimal formatting of issues on mobile site without changing the formatting on desktop.

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) A user visits a page with a page issue.
 * 2) The user interacts with a "Page issue" element.
 * 3) The user is directed to details on the page issue.

General
Mobile page issues will display the following:
 * Issue description
 * Short descriptions for the issue will be used where available.
 * If no short description 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 will be set according to 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 a custom appearance and position within the page.
 * If an issue contains links to other pages, the links will be removed. The links will appear on the page issue detail modal.

Single issue

 * For pages that have a single issue, severity will be derived from the template as defined above.
 * An example. If template has severity level "Medium", the article will have a single page issue appear at the Medium level. (example).

Multiple issues

 * Issue severity levels will be derived 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.
 * For example, if template has level "High", the article will have issues appear at High level. (example).
 * 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
Ultimately we want to understand what effect increasing the awareness/prominence of page issues on the mobile website has on the reading experience, specifically on the perceived quality and reliability of pages. Our goal is to help readers better gauge the reliability and quality of the article they are reading, and our hypothesis is that making them more aware of page issues will contribute to this goal.

We'd like to answer the following questions:

Does the new treatment for page issue notices increase the awareness among readers of page issues?

 * Qualitative research:
 * Do readers notice the new page issue treatment more than the current treatment?
 * Do readers notice version B (with titles) of the new treatment more than version A (without titles)?
 * Do readers notice page issue notifications located after the lead paragraph more than if they are located at the top of the page?
 * Quantitative research:
 * Is there an increase in click-through based on the new issue treatments (from the article page to the issues modal)?
 * Is there any correlation between severity of the issue and click-through rate?

How do users feel about being informed of page issues? How does awareness of page issues affect their perception of Wikipedia?

 * Qualitative research:
 * Do page issues make sense to readers?
 * Do readers care about page issues? Do they find them useful? Important?
 * Are readers familiar with page issues already? Have they seen them on other articles?
 * Do readers understand how page issues work, i.e. how they appear on a page?
 * Does becoming aware of page issues change readers’ perception of Wikipedia?

Additional research questions:

 * How do readers form opinions about the quality and reliability of Wikipedia pages in general?
 * Do readers care more about issues considered by Wikipedia to be of higher severity than issues considered to be of lower severity?
 * What feedback loops (if any) get activated as a result of increased awareness of page issues? E.g. do mobile edits increase with page issues as referrer? Does the new issue treatment changes affect issue removal rates?

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.