Onboarding new Wikipedians/archive

This is an archive of old mockups, user experience notes, etc.

Proposed onboarding
The following workflow is a summary of the current approach we're taking, with more detail about each major step -- landing page, task, and the experience post-task completion -- detailed below.

Pre-onboarding
 * 1) The user arrives at Wikipedia, either through one of the main portals (wikipedia.org, Main Page) or a specific article.
 * 2) The user visits the account creation page.

Onboarding
 * 1) The user successfully creates account, is redirected to a landing page including...
 * 2) * a welcome message (new welcomecreation message),
 * 3) * a prominent link to return their internal referrer,
 * 4) * a list of tasks to try,
 * 5) The user either goes back to reading/editing their referring page, departs, or chooses to accept one the tasks presented to them.
 * 6) If the user accepts a task, they are given a guided tour of how to complete it the first time. This tour will educate them about...
 * 7) * how to accomplish the task
 * 8) * how to edit the page
 * 9) * how to save their edit
 * 10) When users complete a task, they are show where to find more to do, including how to return to such a task list at their leisure.

Landing page
Our goal for this landing page is to get users to accept a first editing task, with the secondary goal of supporting those who just want to get back to the task they already have in mind. The spectrum on which we can play with the contents of this landing page is to either optimize a single task, or increase the diversity of task types and articles available.

Our first iteration provided a list of tasks to entice new editors focuses on delivering articles of a single type of task -- basic copyediting -- in a list updated on an hourly basis. The tasks delivered as part of our onboarding process are real Wikipedia articles, as opposed to test cases or simulations. This has two advantages: it avoids creating a shock when users who have "made an edit" encounter the realities of wikitext on real tasks, and it counts as real edit. One disadvantage to this choice is that we are exposing these articles to vandalism or other malefactors.

Future work and alternative ideas

 * As an alternative to the landinge page approach, we could redirect users to their internal referrer, then provide relevant calls to action, such as in a modal. Whether we return users to their referrer automatically or not, that workflow may merit additions: for instance, work on the article creation workflow and helping users who want to contribute to pages that are semi-protected.
 * Future versions will ideally detect when a user is referred by an edit window, and skip onboarding in favor of returning them to editing. (The flow above would deal with this use case as well.)
 * The current design of the onboarding page has the primary goal of encouraging the user to complete an edit. Depending on the funnel analysis, it may be necessary to reduce the number of choices directed at new users by providing only a single task at a time. (See mockups below)
 * For either multiple or single task flows, it may help users choose an article if there is a refresh or skip action.

Task page (i.e. article)
Our goal when users have accepted a task is to help them complete it. Though we are not completely controlling the user experience with a simulated task, we can provide extra help to users on the articles they choose to interact with as part of the onboarding process.

To do this, we first experimented with a simple guided tour of the edit interface, using the following steps...
 * Guided tour

See also: user tests of this tour, including upcoming usability enhancements


 * Navigation bar

Post-onboarding
Currently this flow emphasizes helping users complete a first edit. We might consider this the most basic form of onboarding completion, but in reality it is simply getting users over the hurdle of making that first contribution, learning to navigate the editor interface, etc. Users are not considered active contributors until they reach their fifth edit milestone.

Currently, we have used two methods to help users go beyond their first edit:


 * 1) The guided tour described above has a final step, where after completing an edit, users are notified that "Getting Started" is updated with more to do regularly.
 * 2) We will be working to build relevant on-site and email notifications to draw back users who edited, and activate those who did not. See requirements