Anonymous editor acquisition/Signup invites

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

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.



Rationale
Learn more at Mobile wikitext editing

First release (MVP)
(See also: Diagram of MVP mobile workflow on apps, for anonymous editing CTAs)



Second release (ideal)
(See also: Diagram of ideal mobile workflow on apps, for anonymous editing CTAs)



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