Wikimedia Apps/Short descriptions

A "short description" is a description of an article topic that can appear underneath the article's title, in a number of useful circumstances:


 * In a list of search results, a short description can provide some quick context of what each article is about.
 * The same is true for a list of reading suggestions (e.g. a list of trending articles)
 * If a list of titles contains two or more identical (or nearly identical) results, the description can serve as a disambiguation between each title.
 * When navigating to the article itself, the short description can provide a high-level overview, before the user starts reading the article.

This style of displaying a "title + description" combination has been a very successful pattern in the native apps, and is now also done in search results on mobile web. We therefore want to give users a simple way to edit these descriptions.

These descriptions are stored in Wikidata, and are moderated/administered by the Wikidata community.

A feature to edit existing descriptions and add new ones was added to the alpha version of the Android app in late 2016. In February 2017 it was also made available in the app's beta version for three languages (Russian, Hebrew and Catalan) and later in the same month in the production version. After positive results, it was rolled out to more languages in mid-April.

Motivation
We'd like to create more ways of engaging with our readers, especially ways in which casual readers can be encouraged to make contributions. Giving them the ability to edit these descriptions is a viable starting point to experiment with whether our readers can be converted to meaningful contributors. In addition, since the description is intended to be very short and limited to plain text, it can be handled very nicely in a native mobile editing interface.

In addition, we're interested in reinforcing the idea in our readers' minds that Wikipedia is an encyclopedia that anyone can edit. Part of the workflow of editing these descriptions is an encouragement to edit additional portions of the article itself.

Workflow designs
An earlier mockup of the editing interaction is here.

The description editing workflow consists of the following elements:


 * A relatively prominent call-to-action to edit the description when browsing an article.
 * An even more prominent call-to-action to add a description if an article doesn't have one yet.
 * A brief but instructive onboarding screen that describes the purpose of the description to the user.
 * A very clean and minimal editing dialog.
 * A status indicator when the edit is saved, with additional encouragement for the user to edit additional descriptions, or edit other aspects of the article.

Filtering and/or limiting low-quality contributions
We understand that presenting this feature to all of our readers will expose the descriptions to possible vandalism, and we want to do all we can to minimize nonconstructive edits. Here are some ways this is being done:


 * For some of the worst forms of vandalism, the edits will be caught by the AbuseFilter extension.
 * We are currently limiting the number of description edits that can be made anonymously (5) before requiring the user to log in.

Future considerations

 * Should we hide descriptions entirely for certain types of articles, such as lists?
 * Would it be possible to integrate with ORES and preemptively obtain a "score" for the proposed edit, and approve/reject it before submitting it?
 * Would it be possible to take the Wikidata properties of the item in question, and see if the user mentions any of the properties in the description? (i.e. the more properties are mentioned in the description, the higher the score of the edit)

Feedback for the user
Although the app itself currently does not support any moderation or administration features, the editing experience for the user is not totally "blind", meaning that the user will receive a notification if their edit is reverted. For our current MVP, this is in the form of a native system notification that informs the user of the revert, and gives them the option to navigate to the Wikidata page in question (via mobile web), or to the talk page of the user who did the revert (also via mobile web). However, the kind of notification shown in the above screenshot is only possible for a logged-in user (it's not possible for anonymous IP edits). Therefore, we implemented the following behavior:
 * Limit the number of anonymous edits from the current device to 5 before requiring the user to log in.

Another future possibility for feedback to an anonymous user might look like this:
 * The user makes an edit to a description.
 * The app remembers the article and the description that was made.
 * The app starts a background service that periodically checks the description of that article. If it detects that the description is no longer the same as what the user edited, it shows a notification for the user.
 * This service would need to have a lifetime (e.g. 1 day?) after which it will stop polling for changes, to conserve data usage.

Product questions

 * What percentage of users go through the entire workflow of making an edit to the description?
 * What percentage of description edits made through the app are reverted?

Implementation considerations

 * Any edit to the description that's made from the app will be tagged with the "mobile app edit" tag, or possibly another unique tag, so that it will be easy to query edits based on this tag.
 * The feature will have a master "kill-switch" option which, when enabled server-side, will entirely hide the feature from users, if necessary.

Relevant Phabricator tasks

 * T90765
 * T97566
 * T101719

Research

 * /Research