Account creation user experience

This is documentation for the editor engagement experiments team's work on the account creation process.

Background and rationale
The goal of the editor engagement experiments team is to gather data about how to attract and retain new Wikipedia editors. While improvements to the account creation process are not strictly experiments – we are not testing a hypothesis – they are nonetheless necessary precursors for any attempts to run experiments that require new contributors creating an account. If people interested in contributing have a frustrating experience during registration, then any attempts to encourage them to become Wikipedians may fail even if we provide better editing tools. In more scientific terms, a substandard signup process is a confounding factor in many, if not most, of the potential experiments to increase engagement. Moreover, improving the usability of the registration process is certain to have positive effects on other Wikimedia engineering projects, if not the encyclopedia as a whole.

User stories
As an anonymous editor, I want to know what the benefits are to registering an account, so that I can decide whether I need one.

As someone who has decided to join Wikipedia, I need to be able to register quickly so that I can move on to contributing.

As a Wikipedia administrator, I want to make sure that new accounts registered don't violate our community policy on user names.

Current


In addition to a CAPTCHA and fields for username, password, email, the MediaWiki messages that are currently part of the Create Account page include:


 * Fancycaptcha-createaccount, which includes extensive descriptions of the policies and practices around account creation
 * Prefs-help-email, which describes the optional email field
 * Prefs-help-email-others, also describes the optional email field
 * Signupend, links to Help:Logging in

Proposed (version 1)
The new version which will be A/B tested against the current English Wikipedia account creation page (described above) should strive to make it easier to register by...


 * removing or reducing text wherever possible
 * aligning and restyling page elements to indicate their function and importance (e.g. by increasing the size of the "create account" button)
 * more clearly indicating what is required and what is optional
 * rewriting text to be easier to understand (e.g. simply calling the page "Create Account" rather than "Log in / create account" )
 * reducing the number of MediaWiki messages used in the page


 * Requirements
 * 1) Text describing required fields is no more than 12 words in length (the arbitrary word budget may be optimized in future tests)
 * 2) Color usage matches the currently proposed guidelines
 * 3) All form fields are validated before the user is allowed to submit their account details for registration. If validation fails, the error is indicated on the page without the need for refreshing or resubmitting the entire form.
 * 4) Users who do not have JavaScript enabled or who are visiting from an unsupported browser will be served the current registration page rather than the test.
 * 5) Users who are already logged in are excluded from the test and are served the normal experience.
 * 6) A concise list of the benefits of registration is present on the page. See /Benefits of signing up for content.


 * Other
 * 1) The password field includes a strength indicator.  (Optional enhancement)
 * 2) The chosen username is tested against several qualitative heuristics outlined in the local Wikipedia username policy (e.g. contains a brand name or notable person's name). See /Usernames for requirements. (Nice to have only, unlikely to be included for now)

Technical documentation
This A/B test is an experiment, but with an eye toward permanent improvements to the account creation process. The following infrastructure has been used or can be used to refactor the registration page, and should be considered when choosing how to implement the user experience described above.

Description
One way or another the user winds up seeing index.php?title=Special:UserLogin&type=signup SpecialUserlogin.php detects type=signup and creates new UsercreateTemplate, implemented in templates/Usercreate.php, to build the HTML form. This is not documented anywhere on MediaWiki.org. We will be ignoring this template as part of this test, but may choose to refactor or replace it later. The form can be modified by $wgAuth->modifyUITemplate, and then wfRunHooks( 'UserCreateForm', array( &$template ) ) is called, so hooks can modify the form. This is where we come in.

When the user clicks [Create Account], the form posts to self with action=submitlogin&type=signup and the button adds wpCreateaccount. If info was posted and wpCreateaccount is set, then the PHP code runs addNewAccount, which in turn calls addNewAccountInternal, which does things like If any of these goes wrong it immediately returns by calling mainLoginForm with its error, which triggers redisplay. This makes it hard to reuse addNewAccountInternal from an API call, as it wants to redisplay a form rather than return a useful set of errors. Finally if none of these failed it calls to addUser, which may may itself fail.
 * check if wiki even allows creating new accounts
 * validate a createaccount token that should be present in the form (hidden field wpCreateaccount)
 * check if request comes from blacklisted IP
 * check if username is OK
 * check if username already exists
 * check if password and retyped password match
 * check password validity (mostly, minimal length?)
 * check valid email address (if supplied)
 * allows hook point AbortNewAccount to kill account creation
 * throttles account creation

(There is also CreateaccountMail, creating an account by mail.

$wgUseCombinedLoginLink controls whether to output a combined login / create account link in the personal bar, or to output separate login and create account links. wmf-config/CommonSettings.php sets it to false (separate links) for WikiMedia wikis.

Related software efforts
See the /Engineering sub-page for full requirements and Todos.

Account Creation Improvement Project / CustomUserSignup extension
Extension:CustomUserSignup was developed in 2011 to A/B test changes as part of the Account Creation Improvement Project. It presented different pieces of text on the signup page to different users. As of July 2012, this extension was still active on enwiki, but only for the user flow ''Log in > Don't have an account? Create one''. One could append  to the URL query string, replacing the number to see the different campaigns.

Since this extension duplicates functionality of Extension:E3 Experiments and the code is not best suited to our needs for this project, it was turned off and removed in August 2012 (in, https://gerrit.wikimedia.org/r/#/c/18201/ ). The alternative text that users in the different buckets received is still on en-wiki, see messages starting with "Customusertemplate" and a table of the messages in en:User:S_Page_(WMF)/ACIP_messages.

The ACIP results concluded that the "ACP1" set of changes increased the number of newcomers who make 1 edit by 15% and increased newcomers who make 5 edits slightly.

Account creation API
A server API to validate each field of account creation as the user types is needed. Even without one, it may be possible to post incomplete Account Creation form info and infer from server responses if the user input is OK.

There have been attempts at a signup API:
 * an old proposal from 2007 for API:Account creation,
 * Extension:SignupAPI described below
 * and recently Tyler Romeo proposed an API in the thread "[Wikitech-l] How to create account by API?",

SignupAPI extension
This was a Google Summer of Code project to improve the signup experience and develop an API, per the description at Requests for comment/Account creation. It's in Extension:SignupAPI; the code was recently blanked out in git for code review, there are code review comments in https://gerrit.wikimedia.org/r/#/c/8002/

TODO: Evaluate current status of Signup API, develop spec for it. In process in subpage /SignupAPI.

Data collection and analysis
See Meta