As you may know from Sue’s March 2011 update, the Wikimedia Foundation has made it one of our highest priorities to improve the experience of new editors, and we thought we’d start right at the beginning: from when a potentially new editor makes an account.

The Wikimedia Foundation’s Community Department has been studying how we can more effectively invite users who create new accounts to actually start editing. Since February, the Account Creation Improvement Project (ACIP) has been experimenting with different user interface messages and landing pages in the account creation flow (see their results and testing content to-date).

We didn’t have an A/B testing infrastructure that supported this work, so while ACIP has performed the first tests sequentially, we’ve now deployed a modification to our ClickTracking extension to English Wikipedia which will allow us to run multiple tests in parallel and record the results.

You’ll notice the “Log in/create account” link on the English Wikipedia will send you to several possible randomized log in screens, recognizable by the “ACP” identifier in the address.  This is from the newly created CustomUserSignup extension. Over the next few months, we’ll be varying the look and messaging of these screens to see what kind of impact that has on new editors, and sharing our findings. Our testing framework will allow us to bucket-test small tweaks to the interface and measure the number of accounts created and edits made by users (in aggregate or on a per-session basis) who have gone through different flows.

What data we are storing

We are storing a new cookie upon visiting the “Log in/create account” page, with a lifetime of three months.  This cookie will be used to track the following information:

• Which account creation messaging group the user was placed in (identified as ACP1, ACP2 or ACP3 for now)
• What version of the account creation campaign they recieved
• Whether the particular user made it to the end of the account creation process, or whether they dropped off after reaching the login screen or the account creation screen
• If (and only if) the user creates a new account, the number of edits or previews during the course of the trial

The information is associated with browser sessions (each of which has an individual unique identifier), not with an individual user or user account.

Anyone visiting the login page or the account creation page for English Wikipedia will have this
cookie set.  This is to make sure that we always provide the same wording to a particular visitor, so as not to invalidate our test.  We will stop setting this cookie at the conclusion of this work, though we will likely perform other similar tests in the future.

Because of the privacy-sensitive nature of the system, we have a limit on the level of granularity of our findings. For example, we won’t be able to create a plot of users vs edits, because we don’t have user-level data.

We look forward to the findings of the Account Creation Improvement Project, which will ultimately help us create a better sign-up experience for all users. Independent of this project, the CustomUserSignup extension may also prove useful to other outreach projects, by making it possible to create customized sign-up forms (e.g. for student workshops or e-mail invitations).

Nimish Gautam

Based on several usability studies, the usability user experience team has identified that template text and syntax is a major hindrance to new users, making them feel less comfortable editing pages.

As such, one approach that we’ve been experimenting with is collapsing templates into expandable “capsules”. This improves the readability of the wikitext.^[1]

The full wikitext of the template is available with the expansion arrow. Additionally, a more user-friendly template editing form is available by clicking on the template name or the ‘pop-out’ symbol to the right of the name.

Since this is an experimental feature that is largely proof-of-concept, it does have a few limitations:

• Currently only works on Firefox with the editing iframe enabled
• Pasting content into the expanded template (or inserting a newline in Linux) can break the template, depending on the source of the content.
• The implementation is relatively slow, so slower and older computers can appear to hang, especially on pages with large templates
• Templates are not converted into capsules as you type; only templates that were there on initial page load are wrapped

We’re still working on these, but in the meantime, test it out on our sandbox^[2] and let us know what you think!

^[1]We’re working on making the displayed name more customizable on a per-template basis so the collapsed version more accurately summarizes what it’s collapsing, ie displaying the title of an infobox rather than the word “infobox”.

^[2]This is currently prepopulated with some articles about large US cities. For some good examples, check out:
New York City, Boston, or Chicago

After many a hearty SQL battle, we finally have click tracking deployed on the wikimedia projects!

Data on button usage

What’s being tracked?

Which buttons are clicked on the toolbar during editing

What information is being recorded?

The button clicked, the time of the click, total edit count of the user clicking, and edit count for the last 1, 3, 6 months

What information is NOT being recorded?

Individually identifiable information of any sort (eg who exactly clicked what) and anything that would violate our privacy policy in general

Why?

As we revamp the UI, rather than randomly throwing buttons up there we think are pretty (we think they’re all pretty), we thought we’d put buttons up and features that people actually use. Novel, right?

What about the edit history and stuff?

We figure the way a novice editor uses the toolbar is different form a ‘power’ editor, and that there’s probably some gradation in between. Is there? Well, that’s what we hope to find out…

–Nimish