VisualEditor on mobile

In 2018/2019, the Editing team is improving the editing experience for contributors using the VisualEditor on the mobile browser.

Problem statement
See VisualEditor on mobile report for a complete report on the current status.

Our core metric for this project is the edit completion rate. An edit session starts when a user clicks the edit button, but most sessions don't result in a saved edit. The edit completion rate gives the proportion of sessions which do result in a save, out of all those where the editor has a chance to fully load. This metric can help us figure out which platforms are more difficult for users to use, and will help us track the impact of our work.

The edit completion rate varies based on three factors -- how experienced the editor is, whether the edit is made using VisualEditor or the wikitext editor, and whether the edit is made on a desktop or a mobile device. The analysis of these factors is somewhat complicated by the fact that the visual editor is the default editing experience on desktop, and wikitext is the default experience on mobile. This means that on desktop, brand-new editors are mostly using visual editing, and on mobile, new editors are mostly using wikitext.

Overall, the edit completion rate is lower on mobile than on desktop, 2.7% to 22.5%. On desktop, where new editors are mostly using the visual editor, the VE completion rate is 12.6%, compared to the wikitext rate of 24.6%. On mobile, where new editors are mostly using the wikitext editor, the wikitext completion rate is alarmingly low, at 2.7%.

Breakdowns by experience level can be found in the Mobile editing report. (Note for the team: Danny has some questions for Neil about the breakdown; we'll fill this out a bit more when we can clear it up. We're going to choose the number that we most care about -- probably 0 edits + 1-9 edits, using VE on mobile -- and then that's the number that we're trying to change with our work this year. We're also interested in the drop-off in the editing funnel; we need to understand those numbers a little better too.)

Nov 21, 2018
We've been working this week on determining our first interventions for the project, based on the first of the four core pain points: Focus. Jess put together a design proposal deck that highlighted two important goals: Wayfinding, and Managing performance expectations.

Wayfinding means orienting users to help them understand where they are, so that they can focus on the task of making an edit. We discussed a couple of different ideas to help users with wayfinding, including a small pulse-animation that would flash to show users where the content starts, but decided that the most impactful change we can make is to isolate section editing. This will make the experience of section editing the same with both VE and the wikitext editor -- you click the section edit icon, and when the edit window opens, all you see is the content in that section. This helps you to focus on the content that you want to edit, without getting distracted or lost in text that's outside the section. We're now starting the technical work to build this feature.

Managing performance expectations: Another way to help people to focus is by improving the page loading experience. Loading VisualEditor can cause a couple seconds delay even on a good phone connection; for users with older phones or on intermittent connections, this could be a sizeable delay. We're considering several ideas for improving the experience, including: a more reassuring throbber , a translucent modal so the user can still see what they've clicked on, and text that indicates the section the user has clicked on (e.g., "loading Etymology and taxonomy..."). However, the most recent stats indicate that drop-off on mobile is relatively low -- just 4.6% of VE edits on mobile drop out before the page is ready, and 3% of wikitext edits. We're going to talk about the priority of optimizing this stage of the process.

Next, we're going to look at the toolbars, and see what we can improve there.

Nov 12, 2018
Jess has done a heuristic analysis of the mobile editing experience, and identified pain points for us to target in the editing process.

The team has put together a set of seven ideas to improve mobile editing, and posted it for user feedback. The ideas are: Section editing, Toolbar improvements, Remember my scroll position, Table of contents, Differentiating modes with UI, Figure out whether you're done, and Improve copying and pasting.

Danny and Jess talked today about how to choose the interventions we'll work on, and came up with a draft framework (not public doc yet) for how we think about this work. There are four core pain points:


 * Focus -- when the user clicks edit, they know that they're in the right place, and they're not distracted from their task by competing stimuli
 * Affordances -- the user can easily understand how to use the necessary tools to complete their task
 * Completion -- the user is able to successfully submit their edit
 * Evaluation -- the user gets feedback from the system about whether the edit was saved or not

With this guide, we can categorize which pain points the intervention ideas will relate to:


 * Focus: Section editing, Remember my scroll position, Table of contents, Differentiating modes with UI
 * Affordances: Toolbar improvements, Improve copy and pasting
 * Completion: (none yet, this would be an intervention aimed at keeping people from dropping out during the save process)
 * Evaluation: Figure out whether you're done

The team will meet this week to discuss next steps.

Background
The 2018/19 Annual Plan for the Wikimedia Foundation focuses on growing new contributors and content, with a major focus on mobile editing. Over the years, improvements to the mobile editing experience have been done by multiple different teams at the Wikimedia Foundation and by multiple different groups of volunteer editors and developers. Due to the piecemeal nature of the mobile editing improvements, there is little understanding or documentation of what the experience is for a user from starting their first edit to becoming a regular contributor.

During the first quarter of 2018, the Editing team in partnership with the Apps teams, will leverage data and community feedback to produce a document outlining the current state of mobile editing, social challenges, define where and how the visual editor is available and define use cases the product will support. Based on the team’s findings, we will prototype and experiment with visual-based mobile editing workflows, such as paragraph level editing.

In the last two quarters of the fiscal year, the team plans to use A/B testing of visual-based mobile editing workflows and release new features as a result of the prototypes from the first two quarters. Feedback will be solicited and incorporated throughout the entire process, however, the earlier we receive community insight, the more time we will have to test as we create and refine features.

Beyond enhancing the mobile editing experience, our goal is to increase:


 * Edit success rate per period for mobile visual edits
 * Number of edits per period via mobile visual editing by newer editors (within their first 6 months after registration)
 * Number of editors per period using mobile visual editing feature(s)

These metrics are not set in stone, and may change and evolve over time. Individual improvements may also be evaluated with metrics specific to that improvement, in addition to the above metrics.

We will track the progress of this project in the status updates section to encourage a two-way dialogue as this project develops.

Feedback
We would like to hear from anyone interested in mobile visual editing. If you have any feedback about this project please leave them on the talk page. Please ping User:DannyH (WMF) and User:JTanner (WMF) on your posts to alert us.

If there’s a Phabricator task you’re interested in—and if you feel the task is consistent with the goals described above—then feel free to file it and tag it with the VisualEditor tag. That will bring it to the team’s attention, and we’ll consider whether it can be prioritized for action as part of this project. (We may have a more specific tag for this project in the future.)

We can also be reached by the #wikimedia-editing IRC Channel.

Design documents

 * Presentation on Heuristic Analysis Process
 * Q1 Research Snapshot - results of the heuristics analysis and usability testing.
 * Process for Brainstorming - to add
 * Share-out from Brainstorming Sessions - to add