Distraction-free editing

Editing Wikipedia with VisualEditor on the mobile web

https://commons.wikimedia.org/wiki/File:Distraction-free_editing.png

The Wikimedia Foundation’s goal for VisualEditor this year is to create a frictionless environment for editing on mobile to help editors publish more frequently, with more joy. After brainstorming, the Foundation’s Editing team came up with a set of mobile design principles to apply to a plethora of possible design interventions. This post describes our thinking behind the first round of interventions.

Intervention 1: Manage Performance Expectations

Evaluating the user experience, we noticed that certain areas of the experience felt pretty slow to editors. While performance is something that we will continue to work on (and can really only manage to some degree as the other part of the equation is the user’s environmental bandwidth), we can make this moment feel less painful for the user by managing their expectations around performance.

The key issue here is that users aren’t given any kind of feedback during moments like these. Many folks click their edit button and see this blank white screen with a spinner.

https://commons.wikimedia.org/wiki/File:Blank_white_screen_with_a_loading_spinner.png

We thought of a few different ways to address this, including microcopy telling users what’s happening, skeletons and loading screens. Ultimately, we decided to address this by creating a seamless animation transition. To do this we grey out the read mode and transition it to line up with the edit mode. Then when the editor is ready we seamlessly swap it in. We combined this with a user interface refresh to provide a more reassuring throbber and instructional microcopy. In addition to reassuring contributors, the loading overlay helps editors to maintain their focus on the edit that they initiated the editor with the intention of making.

https://commons.wikimedia.org/wiki/File:Editing_Wikipedia_on_mobile.gif

Intervention 2: Improve Wayfinding through Section Editing

We believe that mobile editors can be more productive when they are able to focus on editing only one section at a time.

While the performance expectation intervention is in the realm of meeting fundamental expectations, the second issue we tackled is more unique to Wikipedia: navigating to your edit! One complaint that we repeatedly heard from editors during user testing was that they would find something to edit, click the edit button and then take a really, really, really long time to scroll to the part of the page that they intended to edit. This is acutely painful for users on mobile devices because the amount of information revealed to them at any given time is significantly smaller than on a desktop experience. What was happening in mobile was that you’d click a section editing button and get taken to the editing view but scrolled more or less in the proximity of the section you intended to edit.

Our intervention removed all of the other content so that you can focus on just that one specific part of the content. This directly relates to our mobile design principles — we are removing stimulation and setting the stage so that an editor can do one thing at a time.

https://commons.wikimedia.org/wiki/File:Way-finding_improvements_to_mobile_editing.gif

Initial Testing Results

We tested these interventions on-wiki, on usertesting.com and, at in-person editing events. The initial feedback has been quite positive. Users have been able to maintain their location within the edit and are using words like “expected” or “obvious” when describing the behavior of the interactions.

We’ve also learned that many people expected to be able to have the functionality to edit the whole page as well as choosing to dive in and edit within sections. Additionally (while unrelated specifically to this intervention, but useful for the future iteration of the product), we observed several users attempting to switch back and forth between the different edit modes without much success.

Shipping and Next Steps

These first two interventions (the loading overlay and section editing) have already shipped to Wikipedia and, in addition to the qualitative analysis efforts that I described above, we have recently concluded an A/B test thatshowed that “contributors using Section Editing are ~3% more likely to save the edits they start than contributors using full-page editing.”

The loading overlay was deployed to all Wikipedias and the same was done for section editing after we analyzed the test results.

What’s next for VisualEditor on Mobile?

Although 3% seems like such a small increase, we are banking on lots of incremental interventions having a large collective impact. The Editing Team analyst, Neil Patel Quinn said, “Considering the difficulty of making it possible to contribute to an encyclopedia on a four-inch screen, a 3% increase from a single tweak to the interface is a real accomplishment.” The next three interventions that we are tackling are:

1. Make VisualEditor default for new users on mobile. All of our testing suggests that there are just too many steps for an editor to get into VisualEditor, which in theory, is the more new-contributor-friendly experience. Let’s lessen the burden and make VisualEditor more discoverable by openly testing out this hypothesis.

2. Make it easier to edit context items (links, citations, images, infoboxes, templates, etc.) on mobile. Editing these items is an unnecessarily complex activity. We’re creating a new part of the interface that will show additional details about, and actions related to, editable elements within articles. These interventions will help editors to focus on one thing at a time while simultaneously creating more structured workflows around specific editing tasks.

3. Make a single state toolbar. Contributors are confused about what steps to take to publish their changes, how to undo a mistake and go back without losing all of their changes, and how to get back into editing mode after “accepting changes”. That combined with the fact that contributors are confused about why the toolbar behaves in unexpected ways is why we need to refine the toolbar so that it can be used as a guidepost during editing.

A few things that you can do to help

Excited? Great! So are we. We want to collaborate with you to make this a great mobile editing experience. Here are three things that you can do right now.

Edit Wikipedia using your smartphone via the mobile web

The best way to help with this effort is to try editing on your phone. Don’t focus on the new features, just make some great additions to the encyclopedia.

Share feedback

After you’ve made edits or contributed in some other way on mobile, tell us about it by posting on our product page.

Incorporate user testing into an upcoming event

Do you organize events for editing Wikipedia articles? If so, we would love to collaborate with you to learn how Wikimedians are editing directly from you, so drop us a note on the Talk page.

Thanks to Ed Erhart, Peter Pelberg, Sherry Snyder, Bartosz Dziewoński, Carolyn Li-Madeo, and Ed Sanders for proofreading and feedback. Thanks again to all those who have participated as testers.

?? David Chan, Bartosz Dziewoński, Ed Sanders, and Peter Pelberg for working on the implementation of the Wikipedia editing features described here.

Originally posted by Jess Klein to Down the Rabbit Hole on 22 July 2019.