Talk:Account creation user experience

Previous ideas or stuff for the future

1. Remove clutter of MediaWiki messages MediaWiki:Fancycaptcha and MediaWiki:email-help(-others) messages (ala [1]) and include mention of username policy
   1. Show asterisks next to required fields instead of optional
   2. Auto-focus the first field in the registration process
   3. Move CAPTCHA field below account creation fields
   4. Implement naming and password guidelines as tooltips on Field Names (or beside fields)
2. Language tweaks with a very short word budget (list currently in Google Docs, needs to be wikified) Coordinate with Mobile team, as they will also be using tiny word budgets.
3. Add benefits of signing up in place of removed User Policy
4. Require email address to create an account, in the interests of increasing the "quality" of registrations over quantity

Additional variants

1. Replace CAPTCHA with a honeypot. See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=5309
2. Utilize password recovery icon
3. Login/signup detatched from Special page, probably via a test of mw:Extension:SignupAPI.
4. Integrate create and login on the same page (Prerequisite is the above. This is not the design, but illustrates the idea: [2])
5. Log in without leaving the page you're on - utilize modal window (Requires work on previous two tasks. Similar to this design.)
6. Log In / Create Account order on every page
7. Request password only once
8. Allow for password unmask

Post account creation tests

1. Adjust landing page (MediaWiki:Welcomecreation). Test at least two variants of text on that page aimed at driving certain actions, as opposed to simply dumping documentation on the lap of a new Wikipedian. This will be the next experiment once the registration process is sufficiently improved.
2. Return user to the page they came from instead of taking them to a welcome landing page
3. Add a 'return to previous page' link on the welcome landing page to take the user back to the page where they clicked the login button
4. Ask people to do things upon completion (a whole world of microtasks available)

Form Features

The following is a laundry list of parameters of the account creation UI that can be modified:

• message content.
• captcha
• form field dimensions
• Honeypot vs CAPTCHA
• email address field
• form field autofocus
• password unmask is availability
• password is only entered once vs twice

Events on form completion (future iterations)

• previous page link appear
• Microtask suggestions

Other experiments where we haven't yet defined data needed (future iterations)

• Login/signup detatched from Special page, probably via a test of mw:Extension:SignupAPI.
• Integrate create and login on the same page (Prerequisite is the above. This is not the design, but illustrates the idea: [2])
• Log in without leaving the page you're on - utilize modal window (Requires work on previous two tasks. Similar to this design.)

Browser matrix

We have discussed limiting the group of users with a test for browser compatibility, likely allowing the following set:

• Firefox 12+
• Chrome 19+
• IE 8+
• Opera 11.64+
• Safari 534.47

Browsers that fail to meet the minimum requirements will probably be ineligible for the experiment (rather than letting them in possibly with degraded experience). Steven Walling (WMF) • talk 20:04, 24 August 2012 (UTC)

Non en.wiki-specific stuff

I'm trying to understand what of the new mockup could affect all mediawiki, i.e. what are the changes to the core signup page. The blog post, commenting previous attempts, says: «basic limitations in the core functionality still plagued that project».
If I see the mockup correctly, what we're basically doing is rearranging input fields and making fields and buttons larger/more visually appealing. The space on the right, already usable with the current system message, is made easier (?) to use, or anyway to be used by design, with many new messages which by default are taken by "account creation ads". On top of that, all en.wiki-specific warnings are removed on en.wiki. Am I missing something? --Nemo 23:21, 3 November 2012 (UTC)

Mostly, yes that's right. Note that, if possible within our time constraints, we want to redesign desktop login to match this new style and the mobile login, which is in beta. As for non-English specific stuff: one thing this mockup doesn't include are the alternative language links (Arabic Wikipedia as an example) on signup or login. Also note that it's not just English that adds cruft to the MediaWiki messages in the page, the Arabic example I used and many others do as well. Steven Walling (WMF) • talk 18:11, 5 November 2012 (UTC)

Thanks. Sure, such warnings are used more or less on all wikis (although en.wiki has the nastiest ones), I was wondering how this project will affect/help them. Unless the test will prove that they're completely useless, some sort of replacement will be needed; and in any case wikis will want (and try) to adjust the text displayed in those boxes on the right, so this has IMHO to be taken into account too (at some point).

As for the language links, if you mean links to current wiki in another language, that will be taken care of by ULS so it's probably been wise not to include them in future developments. --Nemo 23:51, 5 November 2012 (UTC)

We're planning to make ULS a default feature, right? Daniel Friesen (Dantman) (talk) 00:46, 6 November 2012 (UTC)

Yes. --Nemo 11:04, 6 November 2012 (UTC)

One possible replacement for the warnings, if necessary, are additional heuristics on the username validation. I wrote up some ideas at Account creation user experience/Usernames. Steven Walling (WMF) • talk 09:41, 6 November 2012 (UTC)

Thank you, I'll reply there. --Nemo 11:04, 6 November 2012 (UTC)

Joining Wikipedia is "free"

This is an English-only issue, but I'm somewhat worried that the "Joining Wikipedia is free" text across the top is going to further confuse the "Wikipedia, the free-as-in-freedom encyclopedia" issue for new users. --Yair rand (talk) 13:02, 2 January 2013 (UTC)

The point was to experiment with pointing out that an account is in fact free-as-in-beer. This is a pretty classic technique for increasing conversions to registered users of a web service. Ultimately it is probably so obvious that it's not really a big help, but I certainly don't think it hurts. Steven Walling (WMF) • talk 20:20, 2 January 2013 (UTC)

I don't understand, is that the result of the experimentation or an assumption you made? Will you evaluate this choice in some way? --Nemo 08:17, 14 February 2013 (UTC)

Become a part of the Wikipedia community

«Become a part of the Wikipedia community: Logging in means all your contributions are attributed to your username, and lets you connect with other Wikipedia contributors.» This wording is rather weird for many reasons:

1. you don't become a part of the community because
   • technically, by registering one doesn't join the community but the project,
   • socially, one enters meatball:GuestRole, not automatically meatball:CommunityMember,
   • by policy, being considered a member of the community often requires some number of edits and days to fully participate in discussions and votes (on en.wiki, even to create an article!),
   • finally, there are very active editors who never feel part of the wiki's community because they believe in meatball:ContentOverCommunity (this is the dominant position in our projects; most extreme opposers advocate for collaboration first, but never for community first);
2. it's not true that you register to "connect" with other contributors because
   • you can edit their (or the article's) talk pages anyway, and it's very bad to give the impression that we are not an open system,
   • registering allows the others to contact you more easily and in general is a way to keep track of your contributions and their followups via the watchlist which is the main feature of registering.

Ok, now I wrote this down even though I know it was a waste of time. I previously refrained because not only resistance is futile but I suppose there is some reasoning behind all this, but today I thought that maybe I could get at least a one-line response "yes we're aware of all this and have considered it in our tests and this is the best solution", if not a real explanation. As I already said ages ago, I hope the choice of the icons, headers, sublines etc. will be easy to customise when this will be implemented properly. --Nemo 08:17, 14 February 2013 (UTC)

We're actually going to ditch that iteration on the benefits entirely, because it's not very well suited to MediaWiki core and because testing suggested that its presence really made no discernable difference. The icons and text could of course be made easy to change on a local basis, but it seems like the wrong approach to roll out something we know most wikis that weren't English Wikipedia would need to customize. There's a whole list of ideas at /Benefits of signing up, and the one we are going to finish mocking up for the first permanent rollout is the one with the community stats. Those are much more easy to use and be meaningful across wikis, and the only Wikimedia project I can think of that doesn't care much about edits, content pages, and active editors is maybe Commons (which obviously cares more about uploads etc.). Anyway, I do appreciate the feedback, even if we often disagree. It's nice to have anyone paying attention. Steven Walling (WMF) • talk 08:55, 14 February 2013 (UTC)

Citation needed

I asked for a citation of the claim that the specific font choice affected the effectiveness of the UI. This was not trolling, and to call it such is not helpful. I and others are genuinely interested in seeing what supports that claim - specifically, I suppose, what the research was that was done on that specifically, and what the particular results were. -— Isarra ༆ 22:57, 31 March 2013 (UTC)

I removed the cn tag because this isn't a neutral description of the world. It's a product spec, where we describe what we want for the future and why, as a team. It's supposed to be partial, biased, and not necessarily something where each argument is based on verification from another source. We can talk more about the issue, but the text is a description of our opinion, based on the controlled testing we did and our own design goals. Steven Walling (WMF) • talk 23:18, 31 March 2013 (UTC)

Removing the {{Cn }} is all very well and fine, but effectively calling me a troll is not - nor should be basing your forward progress on unsubstantiated claims that have already been called into question on other fora. If you have done specific research into the fonts themselves, then please, we would be very interested to see the results as well (and I say 'we' in the sense that there is another guy here holding a cactus, not in the sense that I am trying to speak for some grand vague cabal or something), but if not, please do not claim to have done so. -— Isarra ༆ 00:23, 1 April 2013 (UTC)

The claims aren't unsubstantiated. When you test two versions but you don't control for each individual variable of a design, you don't change fundamental parts of the winning design post-facto unless you are forced to. You especially don't change them when it's a simple font declaration. Specifying use of more legible, modern fonts for those systems that support them, while retaining the same font support for those that do not, is a good design decision even if we hadn't done a controlled test to confirm that the redesign did not cause problems for the majority of users. The claim that's unsubstantiated is that specifying an ever-so-slightly better font for most MediaWiki users is a bad decision likely to cause harm. Steven Walling (WMF) • talk 01:14, 1 April 2013 (UTC)

I'm sure that Isarra isn't the only person here who would like to see some raw research data to back up the claims made here. I could claim that "Microsoft's operating systems are way better than whatever *NIX distibution you're using", but that wouldn't make it true — it'd be just an unsourced claim with no evidence supporting it. It'd essentially change the claim a lot if I could back it up with neutral third-party research data or if you could claim something totally opposite of my claim.
It seems to me that you feel strongly about this issue — which is understandable, since according to the parent page, you're a member of the team involved in these experiments, but when you're asked to provide the raw research data upon which you based your claims on, I fail to see the problem here. You provide the data and everyone can see that there's a reason why the decision(s) were made like that. --Jack Phoenix _(Contact) 15:32, 1 April 2013 (UTC)

The raw data and conclusions around each of our account creation tests is linked from the document, and it's mostly in the Research namespace on Meta. To reiterate what I said above more clearly: we didn't A/B test the new version with and without the font changes. But we know that changing elements of a design post-hoc is a very poor practice that can invalidate a connection between testing results and the reason why you're rolling out a final product.

Beyond the basics of good experimental design and the way it informs the end result you should shoot for, all of design understanding and typography, from the beginning of time until the present moment supports the idea that it is advantageous to specify good fonts that are more legible and properly typeset. It's a ridiculous waste of a week-long A/B test to try and develop quantitative measurement of the advantage of specifying fonts. When you don't specify a reasonably decent font and use it appropriately, you have no idea what you're delivering to users, that's how you get unintended effects like Lucida Grande mysteriously applied to the inputs on ACUX, while normally OSX users would see Helvetica as the default sans serif. If design is about making informed decisions to provide a great experience to users, then not making a choice by failing to specify font families is even worse than choosing a typeface improper for the context. Our assumption, and the assumption of pretty much every product on the Web other than MediaWiki (including other FOSS projects like Ubuntu, WordPress, Drupal etc. if you look at their stylesheets) is that specifying font families is advantageous for users. If you want to make the claim that it's not, you'd need to be the one to show up with some proof to the contrary. If you want, I can provide you citations to good texts about design which reiterate the wealth of details and peer-reviewed research which support these principles. However, this product spec is primarily for the team, as a record of what we want to do and why, so my instinct is not to clog it up with myriad citations about basic design thinking.

As evidenced by my rant above, I think it should be obvious why specifying font families is a good Web design principle to imitate. I think the actual substantive discussion we should and can be having is how to do that. On code review for the login patchset, for instance, Krinkle makes the compelling argument that we shouldn't specifying outside skins. Specifying the font for Vector, but not for all skins, is a useful piece of feedback. The truth is the ideal way to do this would be change Vector everywhere, but practically speaking we do not have bandwidth to do that simply to try and wrap up this project. Our solution, based on feedback from Trevor and others, is to do it in a way where we apply the desired styles to signup/login, and make them available for use in other areas as warranted. That way we can minimize the enormous cost in time, energy, and donor dollars that it would take to make a wholesale change to something even as simple as one line in a stylesheet to specify font families, and approach the problem of managing change slowly but surely, starting with one interface where we know that overall, specifying font families was one part of a redesign that users preferred. Steven Walling (WMF) • talk 18:38, 1 April 2013 (UTC)

You seem to be suggesting having the entire site not specify a font-family and then specifying a font-family only on the user login/signup form (mostly because your team likes this particular styling better than the default font). Is this a correct interpretation of your comments? If so, I think it's pretty clear why this type of inconsistency would make the site look amateurish and idiotic, but I'm praying I'm simply misunderstanding what you've written here. --MZMcBride (talk) 22:28, 1 April 2013 (UTC)

I don't accept your premise that we're introducing new inconsistency in to a site where none existed, cf. the state of things as noted in bug 46437. Furthermore, I'm saying that it's logistically not reasonable to say that change has to be all or nothing on Wikimedia projects. It's very easy to say that, if you'd much rather default to no changes being made ever, regardless of their merit and whether it was based on our opinion or whether we'd tested the font stack specifically. It frankly blows my mind that, the first time someone offers to improve even the most basic aspects of the design of core interfaces like signup and login, the reaction is so hostile, despite the fact that we've spent months carefully testing the redesign to ensure that we're not introducing changes that introduce measurable problems for users. If your beef is really that volunteer contributions in this same area (ala https://gerrit.wikimedia.org/r/#/c/27022/) are not getting enough review and support, as your comments on IRC seem to suggest, that's a different point of debate (which I'm happy to talk about separately here or elsewhere, without muddying the two). Steven Walling (WMF) • talk 23:26, 1 April 2013 (UTC)

ACUX for mediawiki.org

Will mediawiki.org also get ACUX? If so, how can we get involved producing the content specific to this site? (and translate it, if it's ready for multilingual sites). We could start working on this right away in the context of Project:New contributors. --Qgil (talk) 05:11, 8 April 2013 (UTC)

Yes. The relevant patches to this spec (such as [3]) are to MediaWiki core. MediaWiki.org would be among the earliest to get the new version when it's soft launched and when it's turned on by default. Steven Walling (WMF) • talk 18:39, 8 April 2013 (UTC)

Is this version including the "Why create an account?" text as seen at File:Screenshot_of_test_account_creation.png or another type of "informative" content as seen as File:Account-Creation-Mockup-ByTheNumbers.png? How is or will be that content created / edited? Just willing to work whether we should start working on content adapted to mediawiki.org.--Qgil (talk) 21:15, 8 April 2013 (UTC)

The latter option. There is more discussion/description at Account creation user experience/Benefits of signing up which is linked in the spec. TL;DR: the stats included are generated by MediaWiki magic words, so they will work out of the box here and everywhere else AFAIK. Steven Walling (WMF) • talk 21:35, 8 April 2013 (UTC)

Ok, this is indeed less customization work for wikis. Looking forward... and moving on to GettingStarted & GuidedTour. See you there.--Qgil (talk) 01:14, 9 April 2013 (UTC)