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
The landing page, Special:GettingStarted, is delivered to users immediately after they register for Wikipedia. We have designed and tested a few basic types of landing page:
 * 1) A list of suggested articles (iterations 1, 2, and 3)
 * 2) A list of first editing tasks (iteration 4 and 5)
 * 3) A generic call to action (mockup 1)
 * 4) A single suggested article and task (mockups 1, 2)

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