Anonymous editor acquisition/Signup invites v3

This document describes proposed workflows for inviting anonymous editors to sign up for an account or log in to one they already have.

The problem

Previous A/B tests we have tried prompted the user to sign up either before or after editing (v1, v2). While these were successful at encouraging a significant number of new registrations, the most successful version (asking pre-edit) also has so far caused a decrease in anonymous editor productivity overall. We think that asking a user to signup after they make their edit but before they save may alleviate this issue.

Research hypotheses and data analysis

Read our hypotheses and research questions at Research:Asking anonymous editors to register.

Proposed solution

Workflow description

The proposed workflow is as follows:

1. An unregistered user clicks [edit] on either the page or section level
2. The user is allowed to proceed to the edit screen, and make their changes, as normal
3. When the user clicks Save, a call-to-action is triggered. This CTA includes options to...
   • Create an account and save their edit. This requires the user to complete the signup form successfully, and then will post the edit under their new username.
   • Log in and save their edit. This requires the user to complete the login form, and will post the edit under the relevant username.
   • Save without registering
   • Dismiss, which places the user back in editing mode

• Design options for step three
• 
• 

Implementation

This section is a draft.

Allowing the user to log in or sign up in place, rather than sending them to the full separate form, ideally requires both JavaScript and for the user to be on a secure (HTTPS) connection. As a large proportion of readership still reads Wikimedia sites using vanilla HTTP, this is a significant problem. Several potential solutions are possible:

1. All readership is redirected to HTTPS. This is an undertaking far beyond the scope of this feature experiment.
2. All users are directed to HTTPS on clicking edit. This presents fewer scaling problems, but merits futher discussion still has external dependencies in Operations etc.
3. Users on insecure connections are provided the same choices as those on HTTPS, but instead of the form, they are given only calls to action that link to the secure login or signup forms. This is easily accomplished, but since most readers are still not on on SSL, could present a serious confound for testing the efficacy of providing the forms via AJAX.