Onboarding new Wikipedians/Engineering

Overview

For most of June and July 2013 we (the Editor engagement experiments team) have been serving the "test" of presenting Special:GettingStarted after account creation to 100% of new users on enwiki. We've iterated on the appearance of Special:GS, we've improved the guided tour when you choose a page, and added a taskbar to the top of the page if the user chooses a page to edit. We've updated this to work with the change of CentralAuth to "SUL2" behavior.

With OB6,

• test is the new proposed workflow of presenting a Call to Action overlay
• control is showing GettingStarted.

URLs and query strings

Test (new overlay CTA)

Successful anonymous Create account redirects back to original "returnTo" page, but with

?postCreateAccountGettingStarted=true

so page knows to load special JS. Too long

Control behavior (Special:GettingStarted)

Successful anonymous Create account redirects to Special:GettingStarted with

?postCreateAccount=true

so the special page knows it

&returnTo = original Page

so the special page can provide its [No thanks ] link back to the "returnTo" page.

If the user clicks the [No thanks, return to Article] link, the openTask JS sets up a cookie for that Article and logs a returnTo task funnel.

If the user chooses a task, the openTask JS sets a cookie so is he same

Page display triggers

Issues

• More issues in m:Schema talk:GettingStartedOnRedirect

TODO

• Need to bring back firstedit tour for 'editable-editing' (there's one in Gerrit change 64981).
  • the 'editable-editing' tour should start by pointing to edit button (probably VE) then section edit
• It's possible that openTask cookie and ?postCreateAccount and first-edit tour could all be firing on the same article view, JS overload!
• choosing 'Find pages that need easy fixes' leads to Special:GettingStarted/task/copyedit&source=gettingstarted (just like clicking the "Fix Spelling & Grammar" task in Special:GettingStarted), which finds a random page in the appropriate category and redirects to it with &source=gettingstarted.
  • probably need to use a different source= parameter nominating the task funnel, e.g. postsignup-editable-editpage
• The openTask cookie handling checks for a "gettingstarted" prefix on the front of the page in self::getUnprefixedGettingStartedTask(). There will now be others flows besides that on the front of the cookie.

• need to expose inTest to the JavaScript and use it to, e.g. not show the '◄ Back to list' in task toolbar.

• if user revisits the return page, we shouldn't re-display the CTA, so we should hack the browser state to remove the ?postCreateGettingStarted=true.

Naming

Maybe just call it return

• the new test OB6 flow is "return to the returnTo page after create account form". I'm currently naming this "postSignup" in files, tasks, and funnels , but that's bad because Signup is a synonym for CreateAccount and much of existing GS applies to that state.
  • "onPage" ? Communicates the key idea that stuff is happening on the page rather than in Special:GettingStarted. Only problem is it sounds like an event/hook handler.
  • Pau's mockups call it "directToPage" I like it! A bit long for files like ext.gettingstarted.directToPage.js or the funnel directtopage-editable-fixpages.
  • "onTheReturnToPagePostCreateAccount"... is too long
  • "postCreateAccount"... is already the query string for being post-account and like postSignup applies in other cases.
  • "returnTo..." is a key concept, but is so overused in this codebase and CentralAuth and UserLogin. And the name is already used for the returnto funnel and task when the user clicks the returnTo link on Special:GettingStarted.
  • "postCreateCTA" is no good because some states don't present CTA

UI elements

• the Call To Action is a page overlay dialog with buttons and dismiss text. There are two flavors with different buttons, not sure of a good idiom.
  • sounds like jquery.ui dialog, but that wants to add a heading area and a button area for the buttons (like e.g. Thanks). Unclear how best to hack this.
  • The mockups call for a two-line button with icon, looks like jorm's 2011 ; Kaldari says he built this in jquery.ui

Decided

• OB6 is a test of a radical change to user behavior and how it affects edit rates; it is not perfecting a new onboarding flow, there are lots of good ideas.
• We don't show anything on return to other namespaces or return straight into editing. Those users gets the Echo welcome new user notification, and that's it.
• We're not doing the additional workflow states on Pau's File:Direct-to-page_onboarding workflow overview.pdf (e.g. a guider pointing to "Contributions" after "No thanks"), for now.
• We'll stick with GS checks the openTask cookie for the current page to decide whether to load its task toolbar. We'll stick with this, with some adaptations, rather than use query string.
• It's OK that the task toolbar will continue to be hidden if screen at < 850px. We'll continue to log isNavbarVisible.
• We're not worrying about behavior when user chooses [Try fixing some pages] and there are no pages in the copyedit category.

Schema/logging decided

• OB6 will log to new schema with some changes and new actions.
• We don't need to log the page kind, can reconstitute the conditions by looking at the page.
• test user seeing task toolbar uses the gettingstarted-copyedit funnel.

Bugs

• SpecialGettingStarted.php's wfFindFile( $task['image'] ) is doing a commons lookup and can fail. spage has a fix, should file a bug and split it out.
• On local wiki when logged in as a new user, http://localhost/wiki/index.php?title=A%20restricted%20page&postCreateAccountGettingStarted=true has wgIsProbablyEditable = true, even though the page is protected with [edit=autoconfirmed] (indefinite).
• GS/resources/*.js files should all have a header summarizing what they do and when loaded.