Last modified: 2014-02-20 02:10:19 UTC
ENWP had a nice little JS feature that checked the username and password against existing usernames and bad passwords. This was already written & isn't that hard to do, so it should be implemented into the ACUX deployment.
The new forms are now in core, but these checks were not included in the initial version.
This was a part of our testing, but was expensive to build at the time. If you read the spec (https://www.mediawiki.org/wiki/Account_creation_user_experience/Launch) you can see why we made this call. This enhancement is nice, but even with the work on the account creation API by Brion, is not simple to design, test, and build. To be frank, this project has gone on a looong time, and it may be time to just defer this change in favor of more pressing experimental work.
I'm removing this as a blocker. As Steven said, it's good functionality we would like to have at some point. However: * It does not block rolling out to Commons. It's already at https://commons.wikimedia.org/wiki/Special:UserLogin?useNew=1 as opt-in, and this doesn't block making it permanent (though there are other things that need to be confirmed). * It is not on English Wikipedia any more (when it was, it was temporary code in an extension), so it's not an enwiki-only enhancement.
Bumping priority. Having to re-enter the passwords and solve a captcha for each attempt to find a good username is not very user-friendly. I observed somebody giving up registration because of that very recently, and suspect this is not that rare. We want those new editors, so lets not make it harder than necessary.
(In reply to comment #4) > Bumping priority. Having to re-enter the passwords and solve a captcha for > each > attempt to find a good username is not very user-friendly. I observed > somebody > giving up registration because of that very recently, and suspect this is not > that rare. We want those new editors, so lets not make it harder than > necessary. To explain more... The version Mono refers to was a test version of clientside validation. The A/B test results were pretty good (+4% bump in registrations, which on enwiki alone would be 2-3,000 additional registrations a month). However, this wasn't good enough for the targets we set (https://www.mediawiki.org/wiki/Account_creation_user_experience/Launch). We set a high standard for how much improvement we wanted in conversion, because with one developer on the project our time was limited. S Page can chime in more, but the main thing that made creating complete clientside validation a major pain was the presence of extensions like AntiSpoof and Titleblacklist. More at bug 40648. If it wasn't for the blockers in that bug, we could have potentially implemented a simple but effective username/password validation system already.
I think this is a duplicate of 17544? *** This bug has been marked as a duplicate of bug 17544 ***
