Account creation user experience/Engineering/Experiment

Out-of-scope

 * logged-in users creating accounts &mdash; only anonymous users are candidates for the experiment
 * users without JavaScript &mdash; E3 experiments "bucket" users in JavaScript code
 * variations of account creation that aren't enabled in En-wiki's specific configuration
 * It's even OK to fail in various edge cases on en-wiki TBD.

Front-end API

 * Ensure that API conforms to WMF JavaScript guidelines and effectively uses jQuery over the DOM API for consistency and cross-browser compatibility
 * check if username exists (-> server-side API call)
 * Research real-time username checking in accordance with our Username Policy (e.g. check for notable names, usage of the word "bot," etc.)
 * check if password meets requirements
 * this is just a $wgMinimalPasswordLength server variable which is 1 on En-wiki
 * Check for matching password fields
 * Conditionally check if email is valid
 * Note client-side code is already provided a JavaScript  function.
 * Do not store password length or any other security configuration variables to window, add it to the mw API.
 * Insert CAPTCHA into the correct location

Issues
If the AJAX-y thinks the form isn't acceptable, should it disable [Create account] or allow the user to submit anyway?
 * it could be wrong about acceptability
 * if client-side warns that password is weak, but En-wiki accepts a single-character password, should allow submission despite warning.

Server requirements

 * Respond to AJAX-y front-end validation requests with parse-able errors
 * either need a new API
 * or client or server could make fake submissions to Special:Userlogin?action=submit and parse the results (see next section)
 * Actually create account upon submission
 * the client can simply submit to the existing Special:Userlogin?action=submit URL and hope for success. But a big reddish error message box is incompatible with the nice AJAX-y interactivity. Ideally if there's a failure, the client needs to make sense of it, either redisplay or
 * CAPTCHA ??!
 * hard to integrate with AJAX-y interaction. Neither Extension:SignupAPI's API nor TylerRomeo's createaccount API handles this.
 * "mail an account" feature -- is this active on en wiki?

Parsing server errors
Existence of &lt;div class="errorbox"&gt; is evidence of error, and the set of possible errors (in English) is somewhat manageable e.g. Login error Username entered already in use. Please choose a different name.

Likewise "Passwords must be at least 1 character", etc. Tyler Romeo's gerrit changes to SpecialUserlogin.php internals would make this easier to parse.

Maybe client JS could just have a div in which it presents any server errors and not try to figure out what they mean. Trick is, when should it blank out the server error box?

Client (or dummy server API) could validate individual fields by crafting various fake requests that are perfect apart from the one field and one last test that stops an unintended account creation.

OR, client just submits everything it has and shows the current server error. Maybe it doesn't contact server until the end, so it only does client-side processing. Biggest problem is you don't get told your username is taken until you submit.

Seems the only part of Special:UserLogiin to care about is DIV#content.mw-body. Don't know how to request only this part from MediaWiki.

arbitrary messaging and campaign bucketing
The now-disabled Extension:CustomUserSignup showed different messages based on the URL parameter ?campaign=somevalue. This allowed links to present arbitrary messages to users during and after account creation, e.g. http://en.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup&returnto=Main+Page&campaign=apswi would show messaging including en:MediaWiki:Customusertemplate-apswi-welcomecreation.

The same feature could/did also set the user in an ACP bucket named e.g. apswi, for future analysis.

Data collection

 * See m:Research:Account creation UX


 * E3 Experiments is already disabled in August tracking Account Creation impressions including the referring page, named "userLoginImpression" (slightly misnamed as these are only for type=signup).  E.g.
 * E3 Experiments is already disabled in August collecting what Account Creation submit button clicks, named "userloginSubmit",

Similar to Post-Edit Feedback, the account creation page will log:
 * user bucketing: assignment-bucketname (whether the user is bucketed for ACUX as "control" or "acux_1"). Note that everyone arriving at the "Create account" page during the experiment gets bucketed.
 * when the experiment (the modified account creation form) is shown: ACUX-bucketname (this should always be "ACUX-acux_1") TODO: should instead always log form display and bucket:

Each time the user reloads, or submits the form, some of these events will log again:
 * userbucketing assignment should only happen first time unless user disables cookies.
 * form reload or redisplay will log ACUX-bucket
 * Dario: would be nice to know if and when the form is redisplayed with an error, but StevenW points out this was not part of the original spec.

TODO: Then need to log, per Research page
 * Successful account creation events, including userids generated by funnel.

The Research page comments "(This means that we need to set an anonymous token in a session cookie, to be able to match impressions and successful accounts created.)"
 * Will the clicktracking-session cookie suffice?

Description of current program flow
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.