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.

Use cases

 * A. Why is someone creating an account?
 * There are lots of paths into creating an account but we can't tell which is effective.


 * B. Invitation to participate in a project, e.g. PhilippinesOutreach
 * We have a promotion that goes to on-wiki pages (not necessarily the Create account form). We'd like to tag the people who followed it.


 * C. Special presentation after users create an account.
 * If we know someone created an account or logged in to participate in the PhilippinesOutreach, then we can do better than present them the default GettingStarted page, we can give them special messaging.

Sketch
On any wiki page request, client-side JS
 * Notices URL parameter ?camp=something (apsi, fromredlink, fromtutorial, etc.)
 * Logs this to a simple Campaign schema:
 * campaign value something (it's an enum, so must match).
 * user session token (if anonymous) or wgUserId (if logged-in)
 * page title (and params)
 * Server-side code can process this for later usertagged later
 * If some campaign wants to change wiki behavior according to a campaign (the classic example is mw:Extension:CustomUserSignup showing a customized CreateAccount page), then the URL parameter is ?camp-s=someValue. If the campaign event validated, then remember the campaign value in a mw.camp cookie that expires in 30 days.

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 ?camp=re-edit on the URL.

Why "camp"? It's shorter and friendlier.

Why the camp-s automatic behavior? Make clients think about whether they need to set a cookie, don't make it to be the default. For analytics we have the event logging the campaign, there's no reason to keep the information in the user's browser.

Why client-side JS? we could log this on the server.
 * client-side already has code to set user session token. Also bots and people who don't want it to be known that they participated in a campaign have some overlap with people who disable JS.

Unresolved questions
Question: Is enumerating all the valid campaign values a good idea?
 * + tight control, can avoid setting campaign cookie to troll values
 * + forces people to think about the campaigns they want
 * - updating the schema rev in PHP will be constant busy-work
 * - a lot(?) of churn in the schema, there will be a new Schema table each time.

Question: Should account creation remember the campaign through to the end page (without having to set a session cookie)?
 * Depends on what kinds of different behavior we want. If we just want to show a different GettingStarted the very first time a user creates an account, then no need to set a cookie, just remember the campaign in a hidden form field, and check it on final form submission.

Question: Does the cookie need to support remembering that the user is in multiple campaigns? E.g. someone responds to one campaign to join the Archaeology signup, another noting that she created an account from the Wiki tutorial page, another inviting her to try VisualEditor. If all of these campaigns affect wiki interaction, then we could enhance the mw.camp cookie to store the last 4 campaign values set on a FIFO basis, expiring in 1 month. .
 * But YAGNI.

Question: should we log camp cookie contents in case there's already something there and we overwrite?
 * Who has time to puzzle out this crap!

Question: do we overload this to handle userbucketing for A/B tests?
 * No, we have mw.user.bucket for that.

Note 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". I'm proposing to log campaigns anywhere, any time.
 * Note the usertags table is already associating e.g. e3_ob4b_returnto_page-impression which happens shortly after account creation.

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

Question: should the camp cookie be cross-wiki (mediaWiki.camp) or per-wiki (enwiki.camp, dewiki.camp)?

Issue: If someone lands on login with a campaign and instead creates an account, or vice-versa, might want to pass the campaign in the link to the other form.

Use cases vs. sketch
A. Just add ?camp=redlink, ?camp=WikipediaTutorial, etc. to each of the links to signup.

B. Add ?camp=PhilippinesOutreach to the links to the target pages, and anyone who follows them will be logged. If those target pages in turn invite users to get started by logging in or creating an account, those links too can have a ?camp

C. Umm, we can offer a custom on-wiki message and/or modify GettingStarted to present something different.

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.