User Story:
- As a new Wikipedia account holder on mobile, I want editing workflows that are broken into a series of easy steps, so that I can successfully contribute.
- As a new Wikipedia account holder on mobile, I want editing support that is surfaced in the moment that I need it, so that I can successfully contribute.
Task Scope:
Taking second iteration designs, T371731, we should now build out interactive prototypes that we can utilize for user testing.
We should incorporate learnings from:
- Growth Ambassador discussions & Growth & Editing team brainstorm sessions.
- Wikimania prototype testing & survey feedback.
There wasn't a clear favorite design (or least favorite) among the Wikimania survey participants, but here are a few participant insights worth highlighting:
- "I think suggesting edits for people who have never edited or are idle in editing mode can help increase participation in Wikipedia editing."
- "If we use this with new editors, we should probably explain briefly the principles on what should or should not be linked (e.g. salient connected topics, but not on every occurrence of the given word in the article)."
- "If there were a better way to surface approach 2 that'd be awesome."
- "In the first approach, using the name "structured tasks" in the message right away might be confusing for a reader. It doesn't happen in approaches 4 and 5, because in those cases structured tasks get juxtaposed to the regular editing and the meaning of "structured" is a bit more intuitive in that context."
- "Repeated discoverability seems a challenge here. How can u not annoy returning editors, have initial discoverability and also explain to ppl how to get back to those flows in subsequent edit sessions"
Design ideas we plan to move into design prototype testing. These are the ideas that best serve our Structured Task strategy, and align with community and stakeholder feedback, and allow us to explore three very different moments in which a suggestion could be surfaced.
Moment | How might we... | User targetting | UI | Logic |
---|---|---|---|---|
Pre-edit moment | How might we encourage and support new account holders to make successful first edits? | logged-in account holders with zero edits | Follows the "Check Sheet" Edit Check UI, and the suggestion should load async after the article has loaded. | The suggestion is dismissible, and after dismissing a suggestion (x) times we should refrain from further suggestions. |
Mid-edit moment | How might we encourage and support new account holders to make successful first edits? | logged-in account holders with zero edits | UI follows the "Check Sheet" Edit Check UI, and the suggestion should load async after the article has loaded. | If the editor starts typing before the suggestion loads, then suggestion should not display. The suggestion is dismissible, and after dismissing a suggestion (x) times we should refrain from further suggestions. |
Post-edit moment | How might we motivate newcomers to make another edit? | logged-in account holders with less than 10 edits | Post-edit dialog that offers a suggestion for Structured Task on a related article. | The suggestion is dismissible, and after dismissing a suggestion (x) times we should refrain from further suggestions. |
Open questions:
- Design approach 2 (Suggestions available from the "editing mode" drop down menu) is too hidden, but it might make sense in combination with one of the other approaches?
- After dismissing a suggestion (x) times we should refrain from further suggestions. x = ?
- Many open technical questions remaining: T371733: Research Spike: surfacing Structured tasks - How can we populate enough suggestions to ensure new account holders are likely to encounter one?
Background
- Project page: Constructive activation experimentation
- Related epic: T368187: [EPIC] Constructive activation experimentation (Growth work related to Wiki Experiences 1.2)
- Related work: Structured tasks & Edit check
Current full-page editing experiences require too much context, patience, and trial and error for many newcomers to contribute constructively. To support a new generation of volunteers, we will increase the number and availability of smaller, structured, and more task-specific editing workflows (E.g. Edit Check and Structured Tasks). The Growth team will primarily focus on Structured Tasks, while working closely with the Editing team to ensure our work integrates well with Edit Check.
This project aims to address the following user problem: Getting started editing on Wikipedia is difficult and especially frustrating on mobile devices. I want the editing interface to provide the in-the-moment policy and technical guidance I need, so my initial efforts aren't reverted.
This project aims to achieve the following user outcome: As a new Wikipedia volunteer, I feel confident and enthusiastic about contributing to the Wikimedia movement by editing Wikipedia articles. The tools provided guide me step-by-step, limit distractions, and allow me to learn progressively so I can successfully contribute on my mobile device.
Growth team hypothesis
As part of the Growth team 2024/2025 Annual Plan, the Growth team will explore various ways to increase constructive activation on mobile. This is part of the Wikimedia Foundation 2024-2025 Annual Plan, specifically the Wiki Experiences 1.2 Key Result
Wiki Experiences 1.2 Key Result
Constructive activation: Increase in the percentage of newcomers who publish ≥1 constructive edit in the main namespace on a mobile device.
Wiki Experiences 1.2.3 Hypothesis:
If we conduct user tests on two or more design prototypes introducing Structured Tasks to newcomers within/proximate to the Visual Editor, then we can quickly learn which designs will work best for new editors, while also enabling engineers to assess technical feasibility and estimate effort for each approach.
Acceptance Criteria
- Iterate on Figma designs based on stakeholder feedback
- Create English version of prototype test for three design concepts
- Learn about setting up unmoderated studies.