Wikimedia Apps/Short descriptions

Start:	Sep 2016
Backlog:	#android-app-feature-description-editing

Tracked in Phabricator
Task T172246

Future updates to short descriptions:

Starting from Jan. 2023, a new page was created to this project that was changed to the name of "Article Description" which you can find here for further following.

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

A mockup of how the Wikidata descriptions currently appear on the Android app. iOS app has a similar treatment.

In a list of search results, a title 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 title description can provide a quick high-level summary, before the user starts reading the article.

This style of displaying a "title + description" combination has been a very successful pattern in the native Wikipedia 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. It has reached all languages except English in July 2017, and may reach the latter in September 2017.

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

A 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.
Brief but instructive onboarding screens 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.

Description editing onboarding

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.

Patrollers who want to monitor Wikidata description edits in their own language may be interested in the following tools that facilitate this:

reCH (click "terms" and then enter a language code)
https://tools.wmflabs.org/dexbot/tools/changed_descriptions.php

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).

A mockup of how a user might be notified that his or her edit was reverted.

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 is 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 has a master "kill-switch" option which, when enabled server-side, will entirely hide the feature from users, if necessary.

Relevant Phabricator tasks

Research

Initial heuristic evaluation

One key piece of feedback was renaming the feature from "short descriptions" to "title description".

Usability test results

Results from UserTesting.com evaluation of the feature.

Wikimedia Apps/Short descriptions/Research

Quantitative results from the deployments since early 2017