Account creation user experience

Group:	Editor Engagement Experiments
Start:	2012-08
End:	2013-06
Team members:	Munaf Assaf, S Page, Steven Wallling
Management:	Terry Chay

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 short, a substandard signup process is a confounding factor in many, if not most, of the potential experiments to increase engagement, and will likely lower conversion rates overall.

Testing strategy and results

With the above rationale in mind, we A/B tested three iterations on designs for new account creation user experience on English Wikipedia, in October and November 2012. The results of these three tests were promising, with each one producing small but statistically significant increases in the number of new registrations. We also conducted remote user testing, and the videos, text answers, and conclusions are available.

To help us contextualize these results and make a final product decision, we set targets for launch to help us decide whether the more ambitious parts of the new interface, like the client-side validation and associated API, would be built out as a part of MediaWiki core. The requirements for a new account creation user experience that follow are a result of the testing results to date and how they reconcile with the targets we set previously.

The first test release. The second release removed some extraneous elements such as the benefits, "remember me" feature, etc.
The third and final version tested, including an alpha client-side validation API

User experience

The following describes what users we're focusing on and what their experience should be.

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 account creation experience

The current English Wikipedia signup page

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 on en.wiki also 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
Language links. Many Wikipedias include the option to view the form in another language. Which languages are present differ from project to project.

Note that many Wikipedias use MediaWiki messages to add warnings, disclaimers, and help text to augment the account creation process.

Proposed account creation experience

See also: Related bugs or additional feature requests that we have deferred for now are available in a public EtherPad.

Mockup of the proposed new account creation page.

Our redesign of the registration page (Special:UserLogin/signup) aims to ease the signup process through the following changes.

making the fields and labels larger, and increasing the size of the submit button
more clearly indicating what is required and what is optional
making the copy, including error messages, more concise and clear (e.g. simply calling the page "Create an account" rather than "Log in / create account" )
removing the excess instructional text that has accrued over the years
judicious use of color to call out important elements, in line with currently proposed guidelines
suggesting to users the core purpose and benefits of having an account on a MediaWiki project. (While we previously tested a literal list of benefits, this cannot be easily localized across projects, and thus we're focusing on using statistics about the community and project as a form of social proof to persuade people.)
letting users refresh the CAPTCHA, to reduce the annoyance of an unreadable test image
specifying font family. The default norm in MediaWiki core is to not specify any font family beyond sans serif, and to let skins specify fonts. In the new interface, we specifying consistent use of more legible fonts available to the widest possible number of users, while retaining sans serif fallbacks for the minority who do not have the relevant fonts. Specifying these font families in this way means that they will only appear for those systems which already can display them, and merely applies them more consistently to these forms (for example: making sure inputs, errors, and field descriptions all use the same font family). We've opted to specify these font families to one part of the MediaWiki core UI, with the styles available to all forms going forward, but only applied where appropriate, so that we may move related forms to this style where warranted in the future to ensure long term consistency.
removal of the "Remember me" checkbox on the form, to reduce unnecessary choices. We assume that the user wants to be remembered for their first login session, but do not set a cookie for long term persistence of the session.

To ensure a unified user experience, we will also be completing a simple redesign of the login page. (Requirements and designs are at the preceding link.)

Technical documentation

Userlogin.php and Usercreate.php in MediaWiki currently use QuickTemplate to generate their HTML forms. We will be building off this current system to first get our UI enhancements to function as desired. Separately, we will be supporting patches already in progress to convert to the HTMLForm class.

In addition to the direct user experience requirements listed above, we will be supporting tracking of campaigns associated with users, when appended to the account creation URL as ?campaign=foo. This campaign support will not yet include presentation of custom landing pages or generating MediaWiki tags for users who signup as part of a campaign, though these and other features may be considered for the future.

Also key to note is that we will be rolling out the first version of the new account creation experience in core as a hidden option, which can be revealed via appending a URL parameter such as ?useNew=1. This will allow us to test the interface in production.

See also: engineering notes and Testing