This tasks holds the work of running a controlled experiment to evaluate the impact of enabling people on mobile web to edit any article section, regardless of which edit icon they first tap (T387175).
Deployment timing
| Milestone | Target completion date | Ticket | Responsible | Status | Notes |
|---|---|---|---|---|---|
| Implement UX | ✅ | T409990 | @Esanders | DONE | Team will consider further refinements after usability testing is completed |
| Draft Tech/News announcement | ✅ | T409112 | @Quiddity | DONE | |
| Review Tech/News announcement | ✅ | T409112 | @ppelberg | DONE | |
| Complete usability testing (1st Round) | ✅ | T410614 | @bmartinezcalvo | DONE | Run first round of usability test; Key decision: what (if any) UX issues will we address before start of A/B experiment |
| Complete usability testing (2nd Round) | ✅ | T410614 | @bmartinezcalvo | NOT NEEDED | This will only be run if/when we come to learn aspects of the initial test protocol or user experience needs revision |
| Publish usability testing findings | ✅ | T410614 | @bmartinezcalvo | DONE | |
| Finalize UX refinements (if any) | ✅ | T410614 | @ppelberg | DONE | We've prioritized one refinement: T411669 |
| QA instrumentation and experiment set-up | ✅ | T410800 | Experiment platform | DONE | |
| Complete button QA | ✅ | T410319 | Editing QA + @MNeisler | DONE | |
| Implement instrumentation and experiment set-up | ✅ | T410800 | @MNeisler | DONE | |
| Conduct pre-deployment QA of UX | ✅ | T411669 | Editing QA | DONE | |
| Start test | Thursday, 11 Dec | T409112 | Editing Engineering | DONE | |
| Complete test | ✅ | T409112 | Editing Engineering | DONE | |
| Turn off experiment | Editing Engineering | ||||
| Complete analysis | @MNeisler | ||||
| Decide on path forward | @ppelberg | ||||
UX
| First section | Middle section | Last section |
Hypothesis
If we enable people on mobile web to edit any article section, regardless of which edit icon they first tap, then the newcomer mobile edit abandonment rate will decrease by 1% because they will be able to more more easily locate the content they tapped edit seeking to change.
Decision to be made
What – if any – adjustments to the mobile web {nav Edit] button UX need to be made before we can be confident all of the following are true?
- Newcomers and Junior Contributors are less likely to abandon edits they initiate using the visual editor on mobile because they will be able to more easily locate the content they tapped edit seeking to change.
- Newcomers and Junior Contributors will be more likely to publish a constructive edit b/c they will have an easier time locating the content they tapped edit seeking to change
- Newcomers and Junior Contributors who encounter the new {nav Edit] button UX are NOT more likely to make changes that are disruptive
KPIs
The main outcomes we are trying to impact through this feature. These are what we are primarily using for evaluating the hypothesis and deciding whether to deploy an intervention more widely.
| ID | Hypothesis | Metric description |
|---|---|---|
| KPI | If we enable people on mobile web to edit any article section, regardless of which edit icon they first tap, then the newcomer mobile edit abandonment rate will decrease by 4% because they will be able to more more easily locate the content they tapped edit seeking to change. | Proportion of all editing sessions by users with ≤100 cumulative edits or logged-out users that are started on a mobile web Wikipedia main namespace (user clicks that the edit button (action = ‘init’) that are not saved (action = ‘saveSuccess’). Overall and by edit init type (page or section). |
| KPI | Constructive edits by newcomers will increase because more people acting in good faith will have an easier time locating the content they tapped edit seeking to change | Proportion of all published edits[i] on mobile web by users with ≤100 cumulative edits or logged-out users that are constructive [1] |
| Curiosity #1 | Users spend less time in the editor before starting to type their edit because they will be able to locate the area of the article are intent on editing with less confusion and/or friction | Time between the editor loaded (action = ‘ready’) and a user starting to type (action = ‘firstChange’). Overall and by edit init type (page or section). |
[1] Constructive edits = edits to pages in any Wikipedia main namespace that are not reverted within 48 hours of being published.
Guardrails
Used to make sure that the new checks presented are not negatively impacting an editor’s experience completing an edit or causing disruption on the wikis. The scenarios named in the chart below emerged through T325851.
| Guardrail Name | Metric description | Notes |
|---|---|---|
| Constructive edits decrease | Proportion of published edits that are reverted within 48 hours. | By making it easier for people tapping edit on mobile web to change larger portions of the article, we may reduce the friction to publishing destructive edits |
| Edit quality decreases | Proportion of published edits that are reverted within 48 hours. | |
| Edit completion rate drastically decreases | Proportion of all editing sessions by users with ≤100 cumulative edits that are started (user clicks the edit button (action = ‘init’) and are saved (action =‘saveSuccess). Overall and by edit init type (page or section). (This should be the inverse of edit abandonment rate metric) | |
| Editor load time increases | Time between the user clicking the edit button (action = ‘init’) and the editor being ready for input (action = ‘ready’). Overall and by edit init type (page or section). | |
| Edit abandonment rate increases | Proportion of all editing sessions by users with ≤100 cumulative edits that include at least one click to the new "Edit full page" button on mobile web and abandon the edit prior to editor being fully loaded. | People who tap the “Edit full page” button T409990 will introduce will not abandon before the full article is loaded in an editable state |
A/B Test: Decision Matrix
| ID | Scenario | Indicator(s) | Plan of Action |
|---|---|---|---|
| 1 | The new {nav Edit] button UX is disrupting, discouraging, or otherwise getting in the way of volunteers | ≥20% decrease in any of the the following metrics in edit sessions where the new {nav Edit] button UX is is activated relative to edit sessions where it is not: edit completion rate, editor load time, edit abandonment rate, revert rate | Pause scaling plans; investigate changes to the UX. |
| 2 | The new {nav Edit] button UX is increasing the likelihood that people will publish destructive edits | Increase in the proportion of published edits where the new {nav Edit] button UX was shown and are reverted within 48 hours relative to edits where it was not. | Pause scaling plans, Review edits to try to identify any patterns in abuse and propose changes to UX to mitigate them. |
| 3 | The new {nav Edit] button UX is effective at lowering the rate at which people abandon edits and the edits people publish are reverted at higher rates | Decrease in the proportion of all editing sessions by users with ≤100 cumulative edits or logged-out users that are started on a mobile web Wikipedia main namespace (user clicks that the edit button (action = ‘init’) that are not saved (action = ‘saveSuccess’) and the proportion of published edits that are reverted within 48 hours. | Pause scaling plans; analysis and manual review of reverted edits to understand why those edits are being reverted. |
| 4 | The new {nav Edit] button UX does not show a statistically significant impact on any KPI, curiosity, or guardrail metric | See metrics above | Move forward with scaling plans |
| 5 | The new {nav Edit] button UX is effective at increasing the likelihood that people publish constructive edits and/or decreasing the rate at which they abandon the edits they start without a meaningful change in any guardrail metrics | See above | Move forward with scaling plans |
Announcements
Experiment Start
Later this week, a controlled experiment will begin for editors on the 100 largest Wikipedias who are editing a section in the mobile website Visual editor. 50% of editors will notice a new "Edit full page" button that will enable them to expand their editing session to the whole page. The experiment will last ~4 weeks. This feature is intended to make it easier for people on mobile web to edit any article section, regardless of which section-edit icon they tapped to begin. Please visit T409112 to see more details about the project.


