Anonymous editor acquisition/Signup invites

This document describes proposed workflows for inviting anonymous editors to sign up for an account.

Implementation
The feature has been added to Extension:GettingStarted and is being expertimented on Wikimedia projects, see 2014/05/16/anonymous-editor-acquisition/.

Current user experience
Currently, there are very few explicit invitations made to anonymous editors to sign up for an account. Not including help page documentation and other content that a reader would need to actively seek out, we know of only a few widespread calls to sign up for an account on Wikipedia:


 * 1) On every page view, links to "create account" or "log in" are present. These are persistent and highly visible, but do not make it clear why a user would want an account.
 * 2) On the login page, there is a call to register if you do not already have an account. This makes up a surprisingly large chunk of registrations on some wikis.
 * 3) On many Wikipedias, there is a notice delivered on the edit mode (in VisualEditor and wikitext editor) which directs you to log in or sign up for an account. It also typically informs the user about exposing their IP as an anonymous editor, and in English it links to a page documenting the benefits of signing up. This on notice makes up a significant number of registrations on the largest Wikipedias (between 9-15%).

Proposed desktop user experience
These two options will be tested against a control.

Rationale
If we think it is advantageous for users to log in or sign up, then we need to ask users to do so. Passive "create account" links (in the personal toolbar or in static MediaWiki messages mid-edit) are not ideal as calls-to-action. We also know that, using methods like tooltip-based guided tours, actively asking users to complete an action and showing them how works for increasing completion rates within a funnel. This effect comes not just from actively asking users to do things, but through asking them to complete actions that align with a clear mental model about what they're being asked to do and why.

For Option 1 in particular, we believe that this may increase registrations by essentially requiring the user to make a choice to stay anonymous or sign up/log in if they wish to proceed with editing. While this choice causes an increase in the steps pre-edit and cognitively in general, it may actually cause less frustration than the current user experience, because it does not require the user to load the edit page and then abandon their edit if they want to log in. While this is an interruption, users on the modern web are very used to being asked to authenticate to take certain actions, like contributing content.

For Option 2, we believe that this interface change would increase the number of anonymous editors who register, because it targets users who successfully saved an edit anonymously and thus are likely to be high-value acquisitions. This workflow is also less of an interruption or barrier to editing anonymously. The disadvantage of this workflow is that it could potentially annoy anonymous editors by showing them multiple calls to register. It may also increase confusion over why they would be asked to register after editing instead of before, if we are suggesting that it is better for users, since they usually see signup invitations prior to performing an action.

One of the risks we run in either option is that we will significantly increase the number of registrations, but that users acquired will not be driven to contribute as much as the signups we already acquire via more passive calls to register. If this occurs, then the alternative is to increase acquisitions by improving CTAs or creating new ones that are not direct suggestions to register, but which are instead more closely tied with improving content. For both options (but particularly option 1) there is a risk that the dialog will cause friction that reduces productivity; for example, someone seeing the pre-edit CTA may neither signup nor edit.

Option 1: Pre-edit CTA


When an user that is not logged in clicks "Edit" or "Edit source", they will be presented with a guider that provides them two options: a primary button to go to account creation, and a secondary button to continue to the appropriate edit mode as an anonymous user. This would work the same for section editing, and regardless of how the wiki editing interfaces are configured, e.g. regardless of whether VisualEditor is enabled for anonymous editors or not. Explanatory text should be provided that warns the user that they will have their IP address saved in a page's revision history. If the user clicks edit again after the CTA appears, then the edit button will function as normal.



Option 2: Post-edit CTA


In this workflow, the user is given a call-to-action only after saving an edit anonymously. This guider would point directly to the "create account" link on the site. It provides explanation as to why we encourage prolific or repeat editors to sign up, giving the user a reason for registering and context. If they dismiss the CTA and continue to edit anonymously, the user should not be presented with the CTA multiple times.



Proposed mobile user experience
Anonymous editing does not currently exist on mobile web or applications for Wikipedia. This first experimental take on this is planned for the redesign for iOS and Android that is being undertaken by the Wikimedia Apps team. Later, the mobile web team will begin testing similar workflows. Learn more at Mobile wikitext editing.

Rationale
Both of the following workflows involve asking the user to log in or sign up in the midst of their edit, before a save. If the user completes authentication, we keep their edit and finish it. This is clearly superior to the current desktop workflow, as it prompts the user to authenticate in the midst of an edit, but does not require them to abandon their contribution. This also may be superior at converting high value anonymous editors to register than either of the proposed desktop workflows above. Basic psychology suggests that, since users will have made and previewed their edit already, they will be motivated to complete the suggested log in/sign up step in order to complete their task.

First release (MVP)
In this workflow, users will be allowed to make edits anonymously, then prompted to make a choice: either save anonymously or log in/sign up. See also: Diagram of MVP mobile workflow on apps, for anonymous editing CTAs. The user will be either redirected to a save form immediately (if the choose to continue without authenticating) or will be sent to the login and signup forms. After this, their edit will be retained and they will have the opportunity to continue with the edit.



Second release (ideal)
This second version is very similar to the MVP above, but rather than making the user choose between calls-to-action, they will be automatically presented with the login form, with an option to either sign up or dismiss this and continue as an anonymous editor. This workflow where the user may log in or sign up in place is much smoother in that it does not require a response to a CTA, and it reduces the need to redirect the user to another step. See also: Diagram of ideal mobile workflow on apps, for anonymous editing CTAs.



Testing methodology
See Research:Anonymous editor acquisition/Signup CTA experiment