Wikimedia Research/Design Research/Reading Team UX Research/Wikidata Title Description Editing

Study authors: Sherah Smith, Rita Ho

Stakeholders: Android team

Phabricator ticket: https://phabricator.wikimedia.org/T151828

Study Plan

Background

A "short description" is a description of an article 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.

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 translate very nicely into 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 will be an encouragement to edit additional portions of the article itself.

Goals

Usability: ensure that this feature is usable, engaging, enjoyable
Exploration: consider things to add to the experience, observe expectations and see if there are areas where more help could be useful

Research Questions

Are users able to easily add a new title description to a Wikipedia article that doesn’t already have a title description?
Are users able to easily edit an existing title description?
After adding or editing a title description, a user may receive a revert notification. Is this notification understood by the user?
Are there any opportunities around the title descriptions flow, or editing in general, that are commonly desired by users engaging with the feature?

Methodology

This study will involve six participants in a remote moderated usability test. Each test will run for a maximum of one hour. They will be asked to step through a prototype build, which will be provided by the Android team. This build will be provided to each participant for installation on their phone.

The tasks participants will be asked to do will include:

Add new description to a Wikipedia article with no description
Edit an existing description
Experience a revert notification

Areas for observation include:

Any privacy concerns?
Any concerns/comments around logging in or staying logged out?
What do participants think about being able to edit anonymously 5 times, then having to log in?
Do participants know/care what a revert notification is?
Do participants want or expect other types of editing notifications/messaging around the title description editing experience?
Do participants understand edit history?
Are there reactions/opinions around character limits for descriptions?
What kind of control do participants want to have over their editing experience? Should the description be posted immediately? Moderated?
What kind of help do participants want?

Participants

6 participants, readers or editors who are not power-editors. All participants must be Android users using Android Jelly Bean 4.1.x or higher. The build will also require 100 MB space. Ideally there would be a good distribution of male/female across a variety of geographical locations.

To participate, a laptop computer or desktop computer with a webcam is required in order to be able to see the participant using their device. The laptop or webcam must be able to be turned in such a way that both of the participant’s hands are free to use the device in front of the camera. The participant must also have high-speed internet access for sending high-quality video so that we can see their screen and hear their voice for the duration of the test.

Schedule

Recruiting request: Nov 29
Receive prototype: by Dec 2 (estimated by team)
Study/interviews day(s): Dec 12-16
Analysis/Synthesis: Week of 19th. This is around the holidays so all stakeholders will not be present, but I will send out a report and set up a time for questions if needed.
Results delivery date: no later than December 22 (dependency: prototype delivered on time, successful recruitment)

Protocol

TBD.

Study Results

Study is currently in progress. Check back soon.