VisualEditor on mobile
|
From mid-2018 to the end of 2019, the Editing team improved the editing experience for contributors using theVisualEditor on the mobile browser.
The end result was a significant increase in the use of the visual editor on the mobile site. Before this work started, fewer than one million edits had been published with this software. After this work, the rate of use increased significantly. As of March 2020, more than four million edits had been published on the Wikipedias and other WMF-hosted content wikis.[1]
In April 2024, the Editing team worked on the deployment of the visual editor asthe default editor for new accounts and logged-out users.
We had several projects, 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.
The Editing Team made its way to Stockholm, Sweden to attendWikimania 2019. From testing new features in the mobile Visual Editor with contributors, to leading two sessions in theCommunity Growth space and presenting during Sunday'sHackathon Showcase, the team was actively involved throughout the five-day conference.
At a high level, the team arrived at Wikimania seeking to learn and understand:
In our efforts to answer these questions, we ended up in many interesting conversations and sessions which left us with a few takeaways and many more findings and new questions (See: "Wikimania Stockholm: Findings" below).
Wikimania Stockholm:Takeaways
You will be able to read more detailed write-ups of our findings and questions as they are linked below.
A couple members of theEditing Team were at theWikimedia Hackathon in Prague last weekend: hacking, helping and doing some user testing on an early iteration of theEdit cards we are working on this quarter. You can read more about the findings from this round of user testing on the project page:/Edit cards#User testing
We have 4 new projects for this quarter! All of them are part of our continuing efforts to simplify mobile editing for contributors using the VisualEditor. Project pages for each of these four new initiatives are up and the table below will hopefully give you a brief introduction to each one.
| Project | Description | Get involved |
|---|---|---|
| Edit cards | Give contributors more space and guidance to complete edits | Learn more |
| VE as mobile default | Make mobile editing more accessible | Learn more |
| Usability improvements | Make VE behave in ways contributors expect | Learn more |
| Toolbar refresh | Make it easier for contributors to find the tools they need | Learn more |
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 deployedSection Editing tohalf of contributors on all wikis.*
Both of these interventions fit within our team'sbroader 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 theheuristic 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. OurMarch 29, 2019 Section Editing update has more information about how the experiment was designed and what the preliminary data has shown.
Following up on ourNovember 21, 2018 update, work on the first iteration ofSection Editing is nearly complete. In fact, here is theprototype. 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 aroundSection Editing's current implementation, there are some active threads on theVisualEditor on mobile/Section Editingtalk page.
As an early effort to understand howSection Editing impacts contributors seeking to make quick edits on the go, we are running atest that we'd value your participation in. Instructions for how to get involved can be found in theTesting Instructions section of theVisualEditor on mobile/Section Editing page.
In the coming weeks, we will synthesize and address relevantfeedback en route to the beginning of the phased rollout ofSection Editing that will start before the end of March, 2019. Also: if this update is the first you're hearing ofSection Editing, or if you're interested in learning more about why and how it's intended to improve the mobile editing experience, theVisualEditor on mobile/Section Editing page is a good place to start.
In addition to the work we've been doing onSection 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 (theEditAttemptStep 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 ourNovember 21, 2018 update), some of whom reported going as far as to abort their edit as a result. TheLoading 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.
TheLoading Overlay is almost ready for an initial rollout planned to start before the end of March, 2019, around the same time the first iteration ofSection Editing will go live. More detail about the research, design and development of theLoading Overlay will soon be live on a dedicated project page that we'll link here.
Jess publishedApplying 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.
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 adesign 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 toisolate 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 reassuringthrobber, 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.
Jess has done aheuristic analysis of the mobile editing experience, and identified pain points for us to target in the editing process.
The team has put togethera 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 adraft framework (not public doc yet) for how we think about this work. There are four core pain points:
With this guide, we can categorize which pain points the intervention ideas will relate to:
The team will meet this week to discuss next steps.
SeeVisualEditor 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%.
| desktop | mobile | |
|---|---|---|
| visual editor | 12.6% | 15.8% |
| wikitext editor | 24.6% | 2.6% |
| overall | 22.5% | 2.7% |
Breakdowns by experience level can be found in theMobile 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.)
The2018–2019 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 producea 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:
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 onthe talk page. Please pingUser:DannyH (WMF) andUser: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.