VisualEditor on mobile report

This page contains a rough outline of the report that is being produced as part of the Editing team's work from the annual plan, as described at m:Wikimedia Foundation Annual Plan/2018-2019/Audiences#Outcome 3: Mobile Contribution.

Background
The 2018–2019 Annual Plan for the Wikimedia Foundation focuses on growing new contributors and content, with a major focus on mobile editing.

The number of people using mobile devices to access Wikimedia sites is constantly increasing, and there are many users who access Wikimedia sites exclusively this way. In particular, emerging Wikimedia communities have many more primary and exclusive mobile users compared to existing communities. Editing using wikitext is a barrier for many of these users, due to both the unfamiliar markup system and the additional difficulties created by the use of mobile devices, such as the smaller screens, which allow contributors to see and preview only a fraction of a page at a time, and the absence of common markup characters, such as  and , on the devices' main keyboard views, as well as many other factors.

The visual editor is available on the mobile web, and solves many of the above complexities. However, the mobile visual editor has usability, user experience, and performance issues, and is difficult for users to find in the interface. The reasons for these issues involve complex interactions between different technical-, design-, and community-based challenges. In addition to the visual editor, there is also the potential to build new visual-based forms of contribution that do not involve the visual editor itself.

The target audience for this work to improve visual-based mobile editing is new contributors, with the aim of converting these contributors into lifelong community members so that they continue to create new content.

Objective of this report
Since the official launch of mobile editing in July 2013, 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 users, from starting their first edits to becoming regular contributors.

The objective of this report is to document the current state of mobile editing, and the challenges that exist, so that improvements can be made to the highest impact areas. In particular, the aim of this report is to:


 * list what the Editing team currently believes the main use cases for mobile editing are.
 * document the end-to-end existing workflow for users.
 * document "bigger problems" not directly related to specific steps of the workflow.
 * propose some ways of improving visual-based mobile editing.
 * stimulate discussion with both senior management and the communities about ways things can be improved.

The report will be updated based on feedback, but ultimately the report is intended to be a static documentation of the current understanding of mobile editing, and not to be a moving target to document of ALL the things. Further reports and documents will be produced, and ultimately action items will go in Phabricator tasks.

A timeline of mobile editing
Mobile editing has evolved significantly over the years.


 * July 2013: wikitext editing on mobile web for registered users is released
 * October 2013: visual editing on mobile web (as non-default) is released to production
 * June 2014: wikitext editing for anonymous and registered users is released on new native Android app
 * July 2014: wikitext editing for anonymous and registered users is released on new native iOS app
 * August 2014: anonymous editing on mobile web is released to alpha


 * March 2015: anonymous editing on mobile web is rolled out to production
 * [Dmitry/Charlotte] add more about experiments with things like description editing in the apps?

Current state of mobile web editing workflow
The editing process begins when the user taps edit. Upon tapping edit, the user is taken to a modal dialogue that presents them with three options: edit anonymously, create account,or sign up.

** PLACEHOLDER FOR FLOW DIAGRAM (Jess to add)**


 * Upon choosing one of the actions and completing it, the user is immediately taken to the source editor, which shows them the wikitext for the article. On many wikis, the user's viewport is filled with template syntax for the infobox, so a new user can't immediately understand how what they're seeing now relates to what they were reading.
 * The visual editor is available on mobile web, but it is not exposed to the user in a clear way. The edit pencil at the top of the viewport allows users to switch to visual editing, and when they do so, they are presented with the mobile web version of the visual editor.
 * This version of the visual editor has stripped down functionality compared to the desktop version:
 * certain things have been disabled, such as image editing
 * some editing tasks are only available in a simpler form, e.g. math formula editing
 * add more

Evaluation of current state of Visual Editor on mobile web
Our goal is to understand the landscape of concerns and opportunities for the Visual Editor. As part of the discovery work that we are doing to explore and define the right problem to solve for with our focus on new editors in the Annual Plan. We will conduct a usability study and an expert review.

Tasks
Based on our research, this product is intended to enable a contributor to [these 5 things]. We are asking if a mobile contribute can do the following tasks:

1. Placeholder (Jess to add)

Research questions
TBD

Principles used to evaluate
Visual Editor Expert Review Framework - This framework was developed by the team designer in conjunction with the Audiences Design team. It's based on The 10 Heuristics for User Interface Design, the Wikimedia Foundation values, and design principles.

Research Methods

 * 1) Expert Review - UX, UI, Accessibility, Language and Engineering professionals will evaluate the tasks provided against the Visual Editor Expert Review Framework.
 * 2) Usability Test usertesting.com research method + demographics screener + protocol - Mobile Web Contributors will attempt to complete the tasks provided.

Findings
[ link to the slidedeck findings report ]

Personas
- who's using VE for mobile web now?

- primary persona

- secondary persona framework for user analysis:

User Journeys
Discussion of mobile-heavy wikis -- what's the % of mobile vs desktop edits on those wikis.

Mobile personas from the New Editors report.

Quantitative metrics
See T202132.

WARNING: This section is a very early draft, and metrics may be added, changed, or completely removed from this section.

Usage of common editing features
See T202133 and T202148. (sum of each item in the columns should add up to 100%) (the sum of each item in the columns shouldn't add up to 100% since an editor may use more than one feature in an edit)

Edit success rate
See T202134. (sum of each item in the columns should add up to 100%) (sum of each item in the columns should add up to 100%) (sum of each item in the columns should add up to 100%)

Breakdown of users per-platform
See T202135. (sum of each item in the column should add up to 100%)

Median time to save an edit
See T202137.

How many edits are made using the visual and wikitext editors?
See T202138. (sum of each item in the rows should add up to 100%)

Monthly retention rates
See T202146.

Which parts of the edit process cause people to abort edits?
See T202147.

Technical concerns
[Ed/Marcella]

What are the technical constraints that make the current VE mobile experience difficult to improve or change? What could we do to make that easier?

What things have been persistent challenges due to those technical constraints?

Would a different visual-based system have different technical constraints? See below -- Would it take more work to build something from scratch, and then have to maintain that as well?

Platform issues

 * On Mobile Safari (iOS) we don't know the visible viewport size, this makes it hard to do things like attach toolbars to the bottom of the viewport (which the Google Docs App does, for example)
 * Safari's webkit engine in general is considered much buggier than Chrome's blink.
 * In general we have less control over text input than in apps. For example in Mobile Safari a context menu with [B/I/U/Copy/Paste/...] is shown on text selections, which we can't suppress.
 * Mobile Safari does strange viewport scrolling when the keyboard is opened, mostly based around the assumption that you are focussing a short input field. MobileFrontend has some hacks to work around these, but they may need more tweaking, especially to work with the OOUI dialog system.
 * Some browsers don't let use read/write from/to the clipboard programmatically, so we can't make our own copy/paste buttons in the UI.
 * Mobile OSes like to unload pages from memory if you switch tab or application, especially iOS. This would result in the editor being reloaded when you return to that tab. Fortunately with auto-save this is somewhat less catastrophic, but there may be more work to remember other user state (e.g. if the user was in the middle of creating a citation).
 * Input methods can vary wildly -- there will be different different issues for different types. (Interplay with viewport scrolling and text input above)
 * There will be issues that affect particular languages and scripts.
 * Screen space constraints affect certain editing tasks, e.g. gallery editing: currently thumbnails and editing toolbars are squashed onto a small screen; difficult to solve without rethinking the workflow.

Performance

 * Mobile web is much slower than web apps, so we may need to anticipate actions not happening immediately and guard against it in the UI (e.g. prevent buttons from being clicked twice)
 * Devices are very variable, in form factor and performance. We can have a good experience on iPhones and Samsung's high-end devices, but there's a lot of underpowered Android phones out there which might not cope as well.
 * Variability in performance means that certain intensive processes (e.g. visual diffs of long documents) will have particularly variable user experience.
 * Bandwidth, latency and intermittent connections will really affect the user experience.

Tech debt

 * The existing mobile wikitext editor code is spread between two repositories (Minerva and MobileFrontend), which makes making and reviewing changes more difficult (T198765). Some code specific to mobile visual editor is in yet another repo, VisualEditor.

Target wikis
Insert explanation.


 * 1) Bangla
 * 2) Hindi
 * 3) Arabic
 * 4) Persian
 * 5) Indonesian
 * 6) Marathi
 * 7) Malay
 * 8) Malayalam
 * 9) Thai
 * 10) Azerbaijani
 * 11) Albanian
 * 12) Hebrew

Options for improvements
Two broad categories for ways to address the problem:


 * 1) Improve VE and expose it more to users:
 * 2) Look at the UX issues in the end-to-end workflow and improve (and, possibly, remove) steps
 * 3) e.g. is it correct to have the first step be a full-screen three option modal? do we have evidence that it's bad, or just intuition?
 * 4) MEASURE MEASURE MEASURE
 * 5) Look at performance, measure it, figure out how to improve it, or indeed if it can be improved to a suitable level
 * 6) Performance breakdowns by common devices, etc.
 * 7) Does section-level editing help solve these issues?
 * 8) Look at VE proper, and whether the UX is actually optimised properly for mobile
 * 9) do we remove buttons, strip functionality?
 * 10) How do we convince communities that it's something worth using?
 * 11) Most communities, including many large communities, have VE as the default experience on desktop (German, Portuguese, Russian WPs, etc.)
 * 12) Some large communities do not (English, Dutch, French WPs, etc.)
 * 13) None have VE as the default on mobile - how do we change that, and do we even want to change it?


 * 1) Come up with alternative visual-based editing experiences, and expose those to users
 * 2) Things like sentence-level editing allow a visual-based editing experience that is more lightweight
 * 3) How would such experiences be exposed to people?
 * 4) Would it take more work to build something from scratch, and then have to maintain that as well?

It's not necessarily an either-or to these options, but trying to do both simultaneously would almost certainly be a mistake...? Perhaps one could be tackled, then the other.

Next steps
List specific action items and timelines:


 * Heuristic evaluation
 * Comparative review of mobile editing UIs.
 * Usability test
 * Soliciting feedback from management in the Foundation (e.g. Katherine, Toby, etc.)
 * [add timeline]
 * Soliciting feedback from users
 * [add timeline]