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
 * DECIDE: do we bother with a client-side password strength meter, when 'a' is a valid password?
 * Check for matching password fields


 * 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.

Deferred features

 * If you enter "john", with current signup MW will actually create username "John" and welcome "John".
 * StevenW says: OK to leave current behavior. In future iteration may provide heads up: your actual username will be John feedback.
 * Note Akshay Agarwal is adding this to Extension:SignupAPI's validate API (see IRC log)

Validation
Proposed approach with icons in Style guide/Error handling and validation, jorm comments "is a conversation point", and he doesn't think any code uses it as is.

Related software efforts
In AFTv5, if you browse enabled pages anonymously and claim "I am highly knowledgeable about this topic" and enter an e-mail, the e-mail field's background switches from pink to green (style changes from invalid to valid) as you enter an e-mail address. It's driven by ArticleFeedback/modules/jquery.articleFeedback/jquery.articleFeedback.js

On Special:ChangeEmail, if you enter an invalid address, it shows a pink half-rounded error label ( Enter a valid e-mail address ) or a green half-rounded "E-mail address appears valid". It's driven by resources/mediawiki.special/mediawiki.special.changeemail.js adding behavior to the field #wpNewEmail. The localized message text is

Each has a similar updateMailValidityLabel that calls mw.util.validateEmail and adds CSS class valid/invalid accordingly. Neither uses resources/jquery/jquery.validate.js

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. Not sure what "userids generated by funnel" means.

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? It seems it doesn't make sense to create a userToken in addition since at the beginning of account creation the user is guaranteed anonymous (logged in users creating additional accounts are excluded from ACUX). At submit time the would-be username is known, and later upon success the username is known.

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.