Goal

Enabling app editors to easily choose between Visual Editor and wikitext for editing articles

Problem statement

Anyone who currently opens an article to edit in the app is confronted with raw wikitext, which resembles code and leads many newcomers to assume editing requires technical knowledge. This perception actively discourages contribution before it begins. VisualEditor was consistently described by our study participants as faster and more intuitive. Its absence in the app is, for many, the primary reason they do not edit there. Creating a native Visual Editor for the app would be a huge undertaking, so we are directing app users to the mobile web Visual Editor when they choose to edit in this way. We hope the process will be straightforward and will encourage more app users to become editors.

Hypothesis

DE3.4.1 - If we show app users a prompt to choose between the mobile web Visual Editor and the native wikitext editor when they tap Edit on a page within a Wikipedia main namespace*, edit completion rate among new editors* will increase, with no statistically significant increase in revert rate.***

*Note we will be instrumenting and tracking for all namespace edits
*As defined as registered users who have published ≤100 cumulative edits
***As defined as an edit that is reverted within 48 hours of being published//

In Scope (MVP)

Platform & Audience
Platform: Android and iOS apps

Audience:
Primary audience - Engaged app users (both logged-out and logged-in)
Secondary audience - New app users who have just installed the app with goal of converting some of them to active users and editors

Presentation
https://docs.google.com/presentation/d/17r0EEZlB3f4Z9Ac0eUqoHigQma_Nq9dHdd8YsBMe5Rw/edit?usp=sharing

Experimentation & Instrumentation

Link to designs in Figma: https://www.figma.com/design/ZhMT1jiTjWfDhKB713cDfX/Visual-Editor-Hand-off?node-id=742-140&t=hJUMmGL9CiNYZZBk-0

Questions for instrumentation:

• Does the introduction of this option result in higher abandonment rate of edits?
• Do we see more ‘newcomers’ becoming successful editors?
• What % of people who are sent to web to edit come back to the app again afterwards?
• Attribution of the edit - how will we track that the person who made this edit originated from the app?

Out of Scope

We are planning to launch a basic flow as phase one, ensuring we instrument to understand user behaviour, any drop off points and how we might optimise for any future iterations of editing articles from the apps. With that in mind, the following is not in scope:

• Visual Editor capability / prompts / tips fully within the native app experience
• Account login credentials linked between web and apps
• Auto-switch back from mobile web to native app upon edit completion

Success Metrics & Guardrails

Primary Success Signals

5 Day Leading Indicator:
5 days post-release - what is the distribution of edit method selection made by app edit initiators when presented with Source/Visual edit popup?

Key Results

*KR 1.1: Visual Editor/Mobile Web edit completion rate will increase 5% above current Source edit baseline completion rates (Android, iOS)
Android 14.1%, iOS 16.3% (Source: editattempstep, 2026-05 - 2026-07 avgs)

*KR 1.2: Edit revert rate does not increase from baseline (baseline is not 48 hour revert rate, if we need that will need to collect data specifically, 48 hour revert will be lower than what’s indicated here)
Android Revert rate 7.0%, iOS Revert rate 7.3% (Source: mediawiki_history 2026-06)

[*These depend on us being able to link app edit starts with Visual Editor/Mobile Web completed or abandoned edit data. ]

Supporting Signals

Curiosities:

• What percent of edit start uniques select Visual Editor when given choice?
• What percent of edit start uniques select Visual Editor as default edit method?
• *What % of app Visual Editor users who initiate an edit, then abandon the editing interface without making a change?
• *What % of app Visual Editor users who initiate an edit go on to publish an edit?

Also need Mobile Web Visual Editor Success Rates - SN can pull data

Qualitative Signals
An April 2025 study on reading and editing in the iOS app surfaced consistent patterns across both new and experienced editors: without VisualEditor, wikitext becomes the barrier. Some direct quotes from the study: “On PC, you can choose between source and visual editing, which makes it much more intuitive. On the app, visual editing seems unavailable, which is unfortunate. If added, it would make editing more accessible to beginners.” And... “There should be the feature to edit without looking at wiki code like on desktop. Visual Editor — there should be something like that for the app. I think that will make things a lot more convenient. I wouldn't add a reference at all because I feel intimidated by all these symbols here. It's really cumbersome to do substantive research-driven editing on here.”

Guardrails
GR 1.1 Percentage of contributors who return to publish at least one edit (any namespace) during their second week (day 7-14 ) after their initial edit on a main namespace
Similar to https://phabricator.wikimedia.org/T432293
SN to get Baseline

Deliverables

When a user taps edit from an article screen within the Android or iOS native app experience, feature an overlay screen asking the user which is their preferred way to edit, allowing them to choose between:
Edit like a document: Make changes directly to the page you see. Opens in your browser.
Edit using wikicode: Make changes using markup. Stays in the app.
If the user taps the ‘Edit like a document’ option, they are taken to mobile web to edit

If the user has not already logged in previously once on web, the user will need to log in again at this point by entering their username and password
If the user has set up additional verification they will go through this after entering their username and password
If the user has never created an account with us, they will need to select the ‘Sign up’ option rather than ‘Log in’ & go through our account creation process prior to making any page edits
There is also an option to edit an article without logging in

Once the user has logged in (or if they’ve already been logged in through previous web journeys) they will be able to edit the page using mobile web

We are working with the Editing team to gather a clear view of this part of the user flow

When a user has edited their article and tapped ‘Publish’ they will be taken back to the app and will receive a pop-up message informing them ‘Your edit was published’ from within the app

We are clarifying and resolving any nuances of this journey to ensure people who have downloaded the app but want to use mobile web don’t end up in a strange loop between the two experiences

Shallow dive slide deck: https://docs.google.com/presentation/d/17r0EEZlB3f4Z9Ac0eUqoHigQma_Nq9dHdd8YsBMe5Rw/edit?usp=sharing

Link to designs in Figma: https://www.figma.com/design/ZhMT1jiTjWfDhKB713cDfX/Visual-Editor-Hand-off?node-id=742-140&t=hJUMmGL9CiNYZZBk-0