Account creation user experience/Engineering


 * This page is for engineering issues of productizing (moving into MediaWiki core and enabling on multiple wikis) the experiment to improve Account creation. See /Experiment for details of the Experimental change to Account creation implemented on English Wikipedia in Extension:E3Experiments.

The general approach is to add new versions of the "Log in" and "Create account" forms, with reduced clutter and Agora styling. Users can try these forms by adding  to the query string in the browser URL. The new forms can run alongside the current form until each wiki elects to change over, and eventually the old versions will be retired. The current form is completely unchanged, with the following exceptions:
 * 'userlogin-resetlink' text is changed in old and new forms.

Form changes

 * The login form invites users to join the project with 'userlogin joinproject'.
 * The create account form does not link to Log in, as this is in the top right corner of every page.
 * The create account form has a benefits section (not shown in narrow screens) extolling the benefits of creating an account.
 * The forms have separate titles instead of sharing "Log in / create account"

Reduced clutter
The new forms don't show the loginstart, loginend, loginend-https, signupstart, signupend messages.

enwiki crams a massive amount of text in fancycaptcha-createaccount message. The new form hides this in JavaScript. Each wiki should reduce or eliminate this message.

Instead:
 * Login provides a "Help with logging in" link ('helplogin-url')
 * Create account provides a "Help me choose" username policy link ('usercreate-helpusername-url')next to Username.

Other message changes
The new forms position labels vertically, and hence they use a new set of messages for labels that do not end in ':'.

'userlogin-helplink' provides a centered "Help with logging in"

How the forms affect existing CSS and HTML
The new forms apply styles prefixed with "mw-ui-" to present the "Agora" appearance, for more details see Agora/Engineering. They keep most styles and element IDs from the old forms. This means that wikis that customize the CSS of the old forms, such as fr and commons adding styles to Common.css and Vector.css respectively, may apply unwanted styles to the new forms. To avoid this, the selectors in per-wiki CSS can be made more selective:
 * insert td in selectors, since the new "vertical stack" forms use divs rather than tds, for example change
 * to
 * include #userlogin to target only the old create account form
 * use  to target only the old login form (both exist in the new login form, but there's not a direct child relationship).
 * include #userlogin to target only the old create account form
 * use  to target only the old login form (both exist in the new login form, but there's not a direct child relationship).

The new forms put any CAPTCHA HTML inside inside a tag so that its labels and divs won't get restyled by the form.

Campaign support

 * notice URL parameter ?campaign=something (apsi, fromredlink, fromtutorial, etc.)
 * log this to some simple schema
 * so that it can be usertagged later

This feels like a generic service we should implement everywhere, e.g. a campaign to get wiki editors to participate in edits might invite users to visit the watch list with a ?campaign=re-edit on the URL. Usertagging says it's limited to "associate an arbitrary set of metadata (or tags) to a user_id at the time of the account creation for analytics purposes". However the usertags table is already associating e.g. e3_ob4b_returnto_page-impression which happens shortly after account creation.

Question: Do this on server-side, or client-side JS? Either way should have a config variable defaulted off for it.
 * server-side would be added to every single Web request, or just certain page requests we care about
 * client-side could be a small amount of JS downloaded on some (all) pages.

Question: do we heed the user's "Exclude me from experiments" preference?
 * Moot if campaigns are only for new users, since they haven't expressed a preference.

In order for campaign to affect what's presented to user, we have to remember it in a cookie or added to a hidden form field?
 * Don't want to do it automatically, only in some cases.
 * I think url parameter should indicate the behavior, e.g. ?campaign-sess=redlink will trigger setting a ?campaign session cookie.
 * if user already has a campaign, note in logged event.

Related
Adding  to the query string is a common idiom
 * Extension:UploadWizard/Campaigns
 * Extension:CentralNotice uses it but I think only in its campaign management interface.