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.

Summary
When a user follows a link to a wiki page that has ?campaign=someName in it, if someName is a valid campaign identifier then this a) this logs a Campaign event, and b) if the user shortly thereafter signs up then the account creation is associated with campaign someName.

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 page(s) (not necessarily the Create account form). We'd like to know how many people followed it, and associate any account creations with the campaign.


 * C. Present special material during and after account creation and/or login.
 * 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 of design
implemented an earlier version of this as an addition to extension EventLogging, with lots of TODOs.

On any wiki page request, client-side JS
 * Notices URL parameter ?campaign=someName (apsiw, PhilippinesOutreach2013, fromredlink, fromtutorial, etc.)
 * Logs this a simple event according to the Campaigns schema:
 * campaign someName (campaign's an enum, so must match).
 * user session token (if anonymous) or userId (if logged-in)
 * the namespace and title of the page.
 * (Analytics code could process this to apply usertagging)
 * If the campaign event validated, then store the campaign someName in a mediaWiki.campaign session cookie.

When a user creates an account, the existing ServerSideAccountCreation event will log the mediaWiki.campaign cookie, along with token and new userId, so we can directly relate account creations to the most recent campaign the user clicked.

Discussion
Names for the project, for the query string, for the cookie
 * For now RoCA (Return of Campaign Awareness), ?campaign, and mediaWiki.campaign. We considered and discarded ?c=foo, ?camp=foo and scamp™.

Why always set a session cookie?
 * It's the easiest way to associate a campaign that lands users on some wiki page with later account creation, and this is the most common and important use case.

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.

Is enumerating all the currently valid campaign values in the Schema a good idea?
 * + stops people fabricating Rickroll links that set campaign cookie to troll values
 * + forces people to think about the campaigns they want in advance
 * + lets us invalidate campaigns
 * + [View history] provides a history of campaigns
 * + Adds a campaign gatekeeper, WMF staff can't just add ?campaign=SFMeetupHackers to their URLs.
 * - updating the schema rev in PHP will be constant busy-work
 * any group who cares can add an automated workflow
 * - a lot(?) of churn in the schema, there will be a new Schema table each time.

What about multiple campaigns?
 * If the user follows one link with ?campaign in it and then clicks another link with ?campaign, the second replaces the first in the session cookie; only the most recent is associated with the account creation. This is OK since the thing that encouraged account creation is the "closest" campaign, but it means we can't abuse ?campaign to track all the ways users arrive at the Create account form. We could enhance the cookie to store multiple campaigns, but YAGNI.

Question: should we log campaign cookie contents in case there's already something in it and we overwrite?
 * No, nobody 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.

Question: do we heed the user's "Exclude me from experiments" preference?
 * Yes. Note that it's moot for new users, since they haven't expressed a preference.

Question: should the camp cookie be prefixed with "mediaWiki" or the wgDbName (enwiki.camp, dewiki.camp)?
 * Just mediaWiki.campaign

Idea: put this in a general-purpose session cookie with other session info.
 * YAGNI for now.

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.

Question: do we enable this for mobile?
 * Sure, why not?

Use cases vs. sketch
A. External calls to action that link directly to account creation work great, they just append ?campaign=fundraiserCTA5.

We could append ?campaign=redlink, ?campaign=WikipediaTutorial, etc. to each of the internal links to signup. However, since the campaign session cookie only tracks one campaign, this would overwrite any campaign that brought the user to some page on the site (see Use case B).
 * Maybe the link by which users arrive at the Create account form should be separate from campaign. Each of the links to create an account has a via={searchRedLink,WikipediaTutorial, topNavLink, etc.) query string parameter, and account creation stores this in a hidden field that ServerSideAccountCreation later logs.

B. Add ?campaign=PhilippinesOutreach to the links to the target pages, and anyone who follows them will be logged. For any users that create an account during the session, their m:Schema:ServerSideAccountCreation event will log the campaign.

C. Umm, we can offer a custom on-wiki message and/or modify GettingStarted to present something different based on campaign session cookie. Steven Walling cautions that reshaping experience based on campaign by redirecting the user and manipulating pages has NOT worked well in the past (see Account Creation Improvement Project).

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