VisualEditor on mobile
In 2018/2019, the Editing team is improving the editing experience for contributors using the VisualEditor on the mobile browser.
We have several projects underway, all intended to help make mobile editing a simpler and more focused experience. Watching this page is a great way to stay updated about each.
- Edit cards
- Section Editing
- Usability improvements
- Toolbar refresh
- VE as default mobile editor
- Loading Overlay
May 1, 2019
The two interventions we had been building are now live. On March 14th, we deployed Loading Overlay to contributors to all wikis and on April 2nd, we deployed Section Editing to half of contributors on all wikis.*
Both of these interventions fit within our team's broader effort to simplify mobile editing and more specifically, to help contributors maintain their focus throughout the full course of their edits. As part of our work this quarter, we will be publishing a report here that will show whether Section Editing and Loading Overlay has had the impact we intended them to.
In addition our recent deployments, Jess published a post detailing the heuristic analysis we performed, the results of which continue to influence what parts of the mobile VisualEditing experience we focus on improving: Report Card: Editing Wikipedia on Mobile with Visual Editor.
*Half of contributors: we are running an A/B test to help measure Section Editing's impact on edit completion. Our March 29, 2019 Section Editing update has more information about how the experiment was designed and what the preliminary data has shown.
March 1, 2019
Following up on our November 21, 2019 update, work on the first iteration of Section Editing is nearly complete. In fact, here is the prototype. Ideally, it will give you a sense for how this first iteration will look and feel once it's live. If you're curious about the more real-time conversation happening around Section Editing's current implementation, there are some active threads on the VisualEditor on mobile/Section Editing talk page.
As an early effort to understand how Section Editing impacts contributors seeking to make quick edits on the go, we are running a test that we'd value your participation in. Instructions for how to get involved can be found in the Testing Instructions section of the VisualEditor on mobile/Section Editing page.
In the coming weeks we will synthesize and address relevant feedback en route to the beginning of the phased rollout of Section Editing that will start before the end of March, 2019. Also: if this update is the first you're hearing of Section Editing, or if you're interested in learning more about why and how it's intended to improve the mobile editing experience, the VisualEditor on mobile/Section Editing page is a good place to start.
In addition to the work we've been doing on Section Editing, we've been investigating and refining the transition between reading and editing. More specifically, the [sometimes] multi-second delay between when a contributor taps "Edit" and the article being ready for them to start editing it (the EditAttemptStep schema offers some technical detail about how we measure the steps of this transition).
Addressing this delay – and the way in which it is visually communicated – became a focus of ours after uncovering it as a source of confusion for contributors (see our November 21, 2018 update), some of whom reported going as far as to abort their edit as a result. The Loading Overlay is an attempt to alleviate this confusion, reassure contributors and help them maintain their focus on the edit they initiated the editor with the intention of making.
The Loading Overlay is almost ready for an initial rollout planned to start before the end of March, 2019, around the same time the first iteration of Section Editing will go live. More detail about the research, design and development of the Loading Overlay will soon be live on a dedicated project page that we'll link here.
December 4, 2018
Jess published Applying the Wikimedia mission to product design methods. The post details the framework for how the Visual Editing team is using the Foundation mission to evaluate the success of the product.
November 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.
November 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.
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.)
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.
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.