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.

Personas
We've created four personas to represent the kinds of people creating accounts that we want to help. In addition, established editors (esp. sysops) who want to prevent accounts that violate community policy are a stakeholder in this process, if not a persona for those actually registering.

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
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) (Note: the first iteration of this test won't yet include client-side form validation, though it is still a requirement and will be added later.) All form fields are validated after the user finishes typing each field and 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. We also will test a version of this form without benefits.

Other ideas and future work

 * Add a login popover which features a call-to-action to create an account
 * The password field includes a strength indicator.
 * 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.
 * Make email required, instead of optional (controversial for Wikimedia, standard everywhere else on the Web)
 * Add a gender field along with real name. (Gender is already public data collected in preferences, but few users note their gender.) Related:
 * Have a "refresh" button for the captcha to get a new captcha like reCAPTCHA does.
 * Tidy up the email confirmation on English Wikipedia - it's horrible, unfriendly and could also be made to be more visually appealing.

Technical documentation
See /Engineering 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: These punt at handling a CAPTCHA.
 * an old proposal from 2007 for API:Account creation,
 * Extension:SignupAPI from 2011: in order to implement its Special:UserSignup form with an AJAX-y interactive validation, this extension also implements action=signup and action=validatesignup APIs.
 * Tyler Romeo proposed an API in the thread "[Wikitech-l] How to create account by API?" in 2012: implements an action=createaccount API that calls the existing  $loginForm->addNewaccountInternal; it requires changes to SpecialUserlogin.php to return a status object.

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/ The extension kind-of works but has problems, some comments in subpage /SignupAPI.

Data collection and analysis
See Meta

User testing
We did remote user testing, via the Foundation's account with usertesting.com. The following are notes and video from users who were comfortable sharing their tests with the Wikimedia community.

Standard experience
Tested with two users ACUX_control on English Wikipedia. The second of these tests included the only user who had registered and edited in the past.

The Good:


 * All users were able to quickly find the “create account” button.
 * All users were able to create an account.


 * In both forms, several people noticed and appreciated that email was optional.

The Bad &amp; The Ugly:


 * Presence of username policy and other content definitely slowed down users. Even when they said they would ignore it, they had to scroll past it, and it increased the length of the tests. Choice quote: “A lot of stuff to ignore.”
 * One of the testers thought it was strange that there was an asterik next to the option email field, since usually required fields are marked that way.
 * Only one user got validation errors, but was clearly annoyed by it. Choice quote: “This could be a pain.”
 * Users did actually read the landing page post-registration, and noticed the call-to-action regarding preferences. One woman spent the majority of her 8:41 test changing her preferences, tab by tab. This was very painful to watch.

ACUX
Tested with four users on ACUX_3 on Piramido.

The Good:


 * All users were able to create an account.
 * It was very fast to get through ACUX_3. The minimum time to create an account was 1:13. This may be helped by doing it on a test wiki where there are no username collisions, but still good news. Choice quote: “Much quicker than I expected.”
 * Users clearly read the instructional text in the fields.
 * Users noticed and appreciated client-side validation and the ui for confirming their choices.

The Bad & The Ugly:


 * The form used default field border styling, which looked inconsistent depending on the operating system. This will be fixed in Agora Login.
 * All of the users got the error about username being blank before entering text. Thankfully though, they ignored this error.
 * The CAPTCHA was the biggest hurdle to users in ACUX_3. They hated it. Choice quote: “This is ridiculous. I can’t even see this.” “I feel like it’s a little hard to read.”
 * When a user was stalled by the CAPTCHA, she read the “we can create an account for you” and was clearly confused by it.
 * In both forms, the fact that field content isn’t remembered on refresh frustrated users. On ACUX_3: “That’s irritating. Now I gotta go all the way back and do it again.” A second user didn’t even see that she had to go back. Could we consider adding something like garlic.js ?
 * One user was able to skim the benefits, but had to read the "Community" benefit more closely. Likely because the headline was not descriptive enough - it may need to be changed.
 * One user was hovering over benefit headlines, likely assuming they were links. These possibly need to be restyled.