Growth/Personalized first day/Newcomer tasks

This page describes the growth>Growth|Growth team's work on the "newcomer tasks" project, which is a specific project under the larger "PFD>Special:MyLanguage/Growth/Personalized first day|Personalized first day" initiative. This page contains major assets, designs, and decisions. Most incremental updates on progress will be posted on the general Updates>Special:MyLanguage/Growth/Growth team updates|Growth team updates page, with some large or detailed updates posted here.

You can quickly see what the team is building by looking through these mockups (use arrow keys to navigate):


 * Desktop
 * Mobile
 * Topic matching

The design and planning for this project began on 2019-07-24.

The first version was deployed in four wikis on 2019-11-20.

Current status

 * 2019-07-24: first team meeting to discuss newcomer tasks
 * 2019-08-27: team meeting to go over design concepts.
 * 2019-09-09: Phabricator tasks created for engineering work
 * 2019-09-23: desktop user tests complete
 * 2019-09-30: mobile user tests complete
 * 2019-11-20: V1.0 deployed to Czech, Korean, Arabic, and Vietnamese Wikipedias
 * 2019-12-13: first variant test ("initiation") deployed to Czech, Korean, Arabic, and Vietnamese Wikipedias
 *  Next : continued fixing of bugs, and beginning to engineer on V1.1 (topic matching)

Summary


We think that newcomers should have every opportunity to succeed when they first arrive at the wiki. But frequently, newcomers attempt a task that is too difficult for them, can't find a task they want to do, or can't find ideas for how to remain involved after their first edit. This leads to many of them leaving and not coming back. There have been successful attempts in the past at recommending tasks to editors, and so we believe that the Homepage>Special:MyLanguage/Growth/Personalized first day/Newcomer homepage|newcomer homepage is a potential place to recommend relevant tasks for newcomers.

 We'll need to keep in mind a few things: 
 * Many newcomers arrive with something specific in mind they're trying to accomplish, like add a specific photo to a certain article. We don't want to get in the way of them accomplishing their goal.
 * Newcomers build up their skills over time by progressing from easier edits to hard ones.
 * When newcomers are successful early on, they are more motivated to continue editing.

Taking those things into account, we want to recommend tasks to newcomers that arrive at the right place and time for them, teach them skills they need to be successful, and relate to their interests.

A valuable tool we have for helping tasks be relevant to newcomers is the Report>Special:MyLanguage/Growth/Analytics updates/Welcome survey initial report|welcome survey, which was originally built specifically for this purpose: personalizing the newcomer's experience. We'll plan to use the optional information newcomers give about their goals and interests to recommend appropriate tasks for them.

One of the largest challenges is going to be figuring out how to gather tasks that are appropriate for newcomers to do. There are many existing sources, such as templates that call for work on articles, recommendations in the CX>Special:MyLanguage/Content translation|Content Translation tool, or suggestions from tools like [https://tools.wmflabs.org/citationhunt/en?id=bc3dae92 Citation Hunt]. The question will be which of those options help newcomers accomplish their goals.

At first, we'll focus on using the Homepage>Special:MyLanguage/Growth/Personalized first day/Newcomer homepage|newcomer homepage as the place to recommend tasks, but in the longer term, we can imagine building features that extend into the editing experience to recommend and help newcomers accomplish recommended tasks.

Also in the longer term, we'll be thinking about ways to tie task recommendations into other parts of the newcomer experience, such as the Impact>Special:MyLanguage/Growth/Personalized first day/Newcomer homepage#Impact module|impact module on the homepage, or into the HelpPanel>Special:MyLanguage/Growth/Focus on help desk/Help panel|help panel.

Why this idea is prioritized
We know from research and experience that many newcomers fail early in their editing journey for one of these reasons:
 * They arrive with a very challenging edit in mind, such as writing a new article or adding an image. Those tasks are difficult enough that they likely fail and don't return.
 * They arrive without knowing what to edit, and can't find any edits to make.

We also know that on the newcomer homepage, the most frequently clicked-on module is the "user page" module -- the only thing on the page that encourages users to start editing. This makes us think that many users are looking for a clear way to get started with editing.

And from past Wikimedia endeavors, we've seen that task recommendations can be valuable. SuggestBot is a project that sends personalized recommendations to experienced users, and is a well-received service. The Content Translation tool also serves personalized recommendations based on past translations, and has been shown to increase the volume of editing.

For all these reasons, we think that recommending specific editing tasks for newcomers will give them a clear way to get started. For those newcomers that have an edit in mind that we want to do, we'll encourage them to try some easy edits first to build up their skills. For those newcomers who do not have a specific preference on what to edit, they'll hopefully find some good edits from this feature.

Glossary
''There are many terms that sound similar and can be confusing. This section defines each of them.''


 * "Newcomer tasks"
 * The entire workflow that recommends edits for newcomers and guides them through the edits.


 * "Suggested edits"
 * The name of the specific module that the newcomer tasks workflow adds to the newcomer homepage.


 * "Task recommendations" or "Task suggestions"
 * Lists of articles that need editing work, suggested automatically to users.


 * "Personalized"
 * Software that adapts automatically to each user to fit their needs.


 * "Customized"
 * Software that the user adapts to fit their needs.


 * "Topic"
 * A content subject, such as "Art", "Music", or "Economics".


 * "Topic matching"
 * The ability to find tasks for newcomers that match their topics of interest.


 * "Guidance"
 * Features that help the newcomer complete the suggested task while they are working on it.


 * "Maintenance template"
 * Templates that are put on articles indicating that work needs to be done on them.

Recommending tasks
The core challenge to this project is: Where will the tasks come from and how will we give the right ones to the right newcomers?

The graphic below shows our priorities when recommending tasks to newcomers.

As shown in the graphic above, we would give newcomers tasks that...


 * ...arrive at the right time and place for a newcomer's journey.
 * ...teach relevant conceptual and technical skills.
 * ...gradually guide users to build up their editing abilities.
 * ...be personalized to their interests.
 * ...show them the value and impact of editing.
 * ...motivate them to participate continually.

For instance, we do not want to give newcomers tasks that are irrelevant to what they hope to accomplish. If a newcomer wants to write a new article, then asking them to add a title description will not teach them skills they need to be successful.

We're splitting this challenge into two parts: the sourcing the tasks and topic matching.

Sourcing the tasks
There are many different places we could find tasks for newcomers to do. Our team listed as many as we could think of and evaluated them for whether they seem to be achievable for the first version of the feature. Below is a table showing the many sources of tasks that we evaluated in coming to the decision to start by using maintenance templates.

Version 1.0: basic workflow
In version 1.0, we will deploy the basic parts of the newcomer tasks workflow. It will recommend articles to newcomers that require different types of edits, but it will not match the articles to the newcomers' topics of interest (version 1.1), and it will also not guide the newcomers in completing the task (version 1.2).

Maintenance templates
We're going to be starting by using maintenance templates and categories to identify articles that need work. All of our target wikis use some set of maintenance templates or categories on thousands of articles, tagging them as needing copyediting, references, images, links, or expanded sections. And previous task recommendations software, such as SuggestBot, have used them successfully. These are some examples of maintenance categories:


 * Articles needing links in Arabic Wikipedia
 * Articles needing copyediting in Korean Wikipedia
 * Articles needing references in Czech Wikipedia



In this Phabricator task, we investigated exactly which templates are present and in what quantities, to get a sense of whether there will be enough tasks for newcomers. There seem to be sufficient numbers for the initial version of this project. We are likely to incorporate other task sources from the table below in future versions.

It's also worth noting that it could be possible to supplement many of these maintenance templates with automation. For instance, it is possible to automatically identify articles that have no internal links, or articles that have no references. This is an area for future exploration.

During the week of October 21, 2019, the members of the Growth team did a hands-on exercise in which we attempted to edit articles with maintenance templates. This helped us understand what challenges we can expect newcomers to face, and gave us ideas for addressing them. Our notes and ideas are published here.

Comparative review
Our team's designer reviewed the way that other platforms (e.g. TripAdvisor, Foursquare, Amazon Mechanical Turk, Google Crowdsource, Reddit) offer task recommendations to newcomers. We also reviewed Wikimedia projects that incorporate task recommendations, such as the Wikipedia Android app and SuggestBot. We think there are best practices we can learn from other software, especially when we see the same patterns across many different types of software. Even as we incorporate ideas from other software, we will still make sure to preserve Wikipedia's unique values of openness, clarity, and transparency. The main takeaways are below, and the full set of takeaways is on this page:


 * Task types – bucket into 4 types: Rating content, Creating content, Moderating/Verifying content, Translating content
 * Incentives – Most products offered intangible incentives mainly bucketed into the form of: Awards and ranking (badges), Personal pride and gratification (stats), or Unlocking features (access rights)
 * Reward incentives – promote badges or attainments of specific milestones (e.g., a badge for adding 50 citations)
 * Personalization/Customization – Most have at least one facet of personalization/customization. Most common customization is user input on surveys upon account creation or before a task, most common system-based personalization type is geolocalization
 * Visual design & layout – incentivizing features (stats, leaderboards, etc) and onboarding is visually rich compared to pared back, simple forms to complete short edits.
 * Guidance – Almost all products reviewed had at least basic guidance prior to task completion, most commonly introductory ‘tours’. In-context help was also provided in the form of instructional copy, tooltips, step-by-step flows,  as well as offering feedback mechanisms (ask questions, submit feedback)

Mockups
Our evolving designs can always be found in two sets of interactive mockups (use arrow keys to navigate): Those mockups contain explorations of all the difference parts of the user journey, which we have broken down into several parts:
 * Desktop
 * Mobile


 * 1) Gathering information from the newcomer: learning what we need in order to recommend relevant tasks.
 * 2) Feature discovery: the way the newcomer first encounters task recommendations.
 * 3) Task recommendations: the interface for filtering and choosing tasks.
 * 4) Guidance during editing: once the newcomer is doing a task, the guidance that helps them understand what to do.
 * 5) User feedback: ways in which the newcomer can indicate that they are not satisfied with the recommended task.
 * 6) Next edit: how we continue the user's momentum after the save an edit.

Below are some of the original draft design concepts as the team continues to refine our approach.

Desktop
During the week of September 16, 2019, we used usertesting.com to conduct six tests of the desktop newcomer tasks prototype with internet users unaffiliated with the Wikimedia movement. In these tests, respondents are compensated for trying out the mockups, speaking aloud on what they observe, and answering questions about the experience. The full results can be found in usertesting-results>phab:T231951|this Phabricator task. The goals of this testing were:


 * 1) Gauge the discoverability  of the newcomer tasks module
 * 2) Identify improvements to the usability of the tasks module:
 * 3) Do users understand how to select and review article suggestions?
 * 4) Do users understand how to filter by interests and task difficulty?
 * 5) Do they know how to start editing a suggested article?
 * 6) Gauge user reactions to the suggestions and expectations about guidance through the task.


 * Summary of findings


 * All users thought it made sense and intuitive to get suggestions based on their topics of interest.
 * Similarly, the different task difficulties was positively received by all participants.
 * Overall usability of the suggested edits module was extremely high. People knew how to click to view more articles, use the filter to change topics and task levels, and knew to click on the card to open a suggestion for editing.
 * 4/6 Participants did not initially realize that they should click on “See suggested edits” as a way to help them achieve their goal of writing a new article. This seemed to be a common mental model where users separated "Editing" as different from "Creating a new page".
 * Start module is clearly the starting point for all participants. Moreover many were drawn to “See suggested edits” button as a way to follow the progression of activities in the start module.
 * Users had a clear understanding and expectation they would be shown suggested articles for editing based on the intro dialogs to add topics and introducing task levels.
 * Everyone was able to select the popular topics and add their own topic easily.
 * Everyone understood the purpose of the suggested edits module.
 * Two people were confused/assumed that they could not create a new article until completing easy and medium tasks.
 * 5 of 6 participants knew to click on the help panel button for guidance once they entered the editor mode.
 * Four people expected to be able to contact their mentor in the help panel.
 * Task tips lacked sufficient level of guidance for a couple of participants.


 * Recommendations


 * Improve copy and more over user education that creating new content is a form of editing.
 * Make updates to the Impact module as tested here to aid user understanding of suggested edits.
 * Provide good in-edit context help. It’s very important for users trying an edit.
 * Include a “checklist” for users to revise in the help panel’s task tips.
 * Provide short examples of what to do.
 * Indicate to users they do not have to copy edit for an entire article.
 * Including real-time filtering results helps users connect suggestions as article edits and encourage use of the filtering to find matching articles.

Mobile
During the week of September 30, 2019, we used usertesting.com to conduct six tests of the mobile newcomer tasks prototype. The full results can be found in usertesting-mobile>phab:T231951|this Phabricator task. The goals of this testing were the same as with desktop, but with the added goal of understanding how the mobile experience should differ from the desktop experience. Mobile user testers were prompted with the scenario of intending to add an image to Wikipedia (whereas desktop respondents were prompted with the scenario of intending to create a new article).

 Summary of findings 


 * Overall users found the start module (redesigned) clearly laid out the guided steps to begin.
 * The extra “Suggested edits” module below, while not especially confusing, was still not where users expected to go to help them with their task to add an image.
 * Suggested edits was quite intuitive to use, with participants understanding how its different elements (filtering, seeing more articles, etc) worked.  However, users do not see the value of doing Suggested edits beyond learning or boredom.
 * Several people wanted more granular topics to be available than the broad topics listed.
 * Having the detailed difficulty info was educational, but potentially discouraging. All were surprised “Adding images” was classed as hard, with varying degrees of frustration about this fact.
 * Filtering by interests is a big selling point.
 * 3 people towards the end of the test assumed there was some “verification” or requirement to do  some Easy tasks before Medium/Hard tasks could be achieved
 * Everyone understood the purpose of the Suggested edits as giving edits that would users learn to edit, and also emphasize that it showed them some edits were harder to do.
 * All users struggled to use the guidance we offered through the help panel while they were editing. This is a major area we need to think hard about designing before we begin to build it.

 Recommendations 


 * Suggested edits call to action is inside start module, not its own card.
 * Improve copy and user education imagery to better convey that there is real world value in trying suggested edits beyond learning and that task difficulty is a guide only and tasks can be tried out of order.
 * Add an overlay specifically to introduce personalized introduction to suggested edits.
 * Including real-time counting of filtered results on both task and topic filters.
 * Incorporate more granular searching by interest topics by users.
 * Reiterate when a user opens a suggestion that it is a real, impactful edit.
 * Update design of the in-task help panel so that all available help content is clearly accessible.

Version 1.1: topic matching
Past research and development shows that users are more likely to do recommended tasks if the tasks match their topical interests. SuggestBot uses an editor's past editing history to find similar articles, and those intelligent results are shown in this paper to be executed on more often than random results. The Content Translation tool also recommends articles based on a user's previous translation history, and those recommendations have increased the translation volume.

Our challenge with newcomers is a "cold start problem", in that newcomers do not have any edit history to use when trying to find relevant articles for them to edit. We want to have an algorithm that says what the topic is of each article, and use that to filter the articles that have maintenance templates.

Algorithms
There are multiple approaches with which we might find articles that match a user's stated topic of interest. While our team identified many, we built prototypes for three methods and tested them:


 * morelike: assign a seed list of articles that represent each topic area (e.g. "Art" might be represented by the articles for "Painting", "Sculpture", "Dance", and "Weaving".) Use that seed list to find other articles that are similar to those in the seed list by using a similarity algorithm called "morelike".
 * free text: instead of choosing from a set list of topics, allow newcomers to type in any phrase they want to indicate a topic. Use regular Wikipedia search to surface articles relevant to that phrase.
 * ORES: ORES is a machine learning service that can return a predicted topic for any article. Though it only works in English Wikipedia, there are ways to translate predictions from English to other wikis.

In this Phabricator task, we evaluated the three methods, and decided to proceed with the ORES model. The Growth team will work with the Scoring team to strengthen the model, and with the Search team to make the model predictions available to the newcomer tasks workflow.

Design
In designing interfaces that allow newcomers to choose topics of interest, these are some of the considerations:


 * How to make a long list of about 30 topics not overwhelming to the user?
 * How to handle multiple layers of topics (e.g. if "Science" has sub-topics of "Biology", "Chemistry", etc.)
 * Whether users can give feedback when a topic does not match what they selected?

These mockups contain our current designs for this interface. You can navigate with your keyboard's arrow keys. Below are some images of the mockups:

Variant testing
After deploying the first version of newcomer tasks, we want to start testing different variants of the feature, so that we can improve it iteratively. Rather than just having one design of newcomer tasks, and seeing if newcomers are more productive with it than without it, we plan to test more than variant of newcomer tasks at a time, and compare them. We have compiled an exhaustive list of all the ideas of variants to test -- but we will only end up testing perhaps 10 per year, because of the effort and time it takes to build, test, and analyze. Below are some of the most important ones variants to test.

Usage counts
As of 2019-12-12, 3,797 distinct users have visited their homepage since the deployment of newcomer tasks on 2019-11-20. The tables below show how far into the newcomer tasks workflow those users progressed. We see that generally a bit less than a third of users who see the call to action for the suggested edits module go to click on it. Of those, the vast majority progress through the overlays to initiate the module. Many of those use the arrows in the module to browse tasks, as expected. But most surprisingly, we see many users clicking on tasks and even going all the way through saving an edit. This is surprising because the feature does not yet contain topic matching (which would make the tasks more appealing to users) or guidance (which would help them understand how to save edits).

The second table shows percentages of the raw numbers in the first table. This is only done for Arabic because the other wikis have numbers too small to make stable percentages.