Hey,
Today we (editor engagement experiments team) started an A/B test of a new account registration page on English Wikipedia.
I wanted to bring this up on mobile because, because while it doesn't impact users visiting via MobileFrontend, the design does play niceer with mobile browsers, at least compared to the current default. (See the attached screenshots of mobile Safari on iPhone and iPad. I also tested on Jelly Bean.)
When we move to productize this, we should talk more about implementing the design in a way that jives with what the mobile team is working on.
-- Steven Walling https://wikimediafoundation.org/
Thanks for the heads up Steven. I'm eager to see this go out and be successful.
Some thoughts
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
Also, what's the rationale behind *always* having a captcha? Why can't we employ what the fundraiser does with a captcha *only* being show *when* we detect the user as high risk. This yet again would make this simpler and faster for not just mobile users but everyone.
--tomasz
On Thu, Oct 4, 2012 at 5:12 PM, Steven Walling swalling@wikimedia.org wrote:
Hey,
Today we (editor engagement experiments team) started an A/B test of a new account registration page on English Wikipedia.
I wanted to bring this up on mobile because, because while it doesn't impact users visiting via MobileFrontend, the design does play niceer with mobile browsers, at least compared to the current default. (See the attached screenshots of mobile Safari on iPhone and iPad. I also tested on Jelly Bean.)
When we move to productize this, we should talk more about implementing the design in a way that jives with what the mobile team is working on.
-- Steven Walling https://wikimediafoundation.org/
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I also love the new context around why you should create a new article (attached) that you guys put in place. This should be surfaced not just there but in other places as an anonymous users moves through our workflows to explain why it would be better for them to register.
--tomasz
On Fri, Oct 5, 2012 at 12:20 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Thanks for the heads up Steven. I'm eager to see this go out and be successful.
Some thoughts
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
Also, what's the rationale behind *always* having a captcha? Why can't we employ what the fundraiser does with a captcha *only* being show *when* we detect the user as high risk. This yet again would make this simpler and faster for not just mobile users but everyone.
--tomasz
On Thu, Oct 4, 2012 at 5:12 PM, Steven Walling swalling@wikimedia.org wrote:
Hey,
Today we (editor engagement experiments team) started an A/B test of a new account registration page on English Wikipedia.
I wanted to bring this up on mobile because, because while it doesn't impact users visiting via MobileFrontend, the design does play niceer with mobile browsers, at least compared to the current default. (See the attached screenshots of mobile Safari on iPhone and iPad. I also tested on Jelly Bean.)
When we move to productize this, we should talk more about implementing the design in a way that jives with what the mobile team is working on.
-- Steven Walling https://wikimediafoundation.org/
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Fri, Oct 5, 2012 at 12:20 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
Yeah this is an issue we're discussing on the team too. The current use of it is not the best.
We may actually just remove it, since most other registration processes on Gmail, Facebook, etc. actually only offer this on login. The idea of checking it by default also hints at another good way to reduce unnecessary choice, which is to remove the checkbox but give them a persistent login session the first time by default.
Also, what's the rationale behind *always* having a captcha? Why can't we employ what the fundraiser does with a captcha *only* being show *when* we detect the user as high risk. This yet again would make this simpler and faster for not just mobile users but everyone.
I don't know how they do that, but would be willing to consider it, contingent on input from Chris Steipp and Ryan Lane.
I'd also still like to consider alternatives to CAPTCHA entirely. Cf. https://www.mediawiki.org/wiki/Requests_for_comment/CAPTCHA
On Fri, Oct 5, 2012 at 12:32 PM, Steven Walling swalling@wikimedia.org wrote:
I don't know how they do that, but would be willing to consider it, contingent on input from Chris Steipp and Ryan Lane.
My knowledge of this is circa 2009-2011 when I designed and implemented it with Arthur so i'm cc'ing Katie to correct anything that I get wrong. The extension has an internal engine that combines rule sets with a weighted threshold over *when* a user should see the captcha. The system is able to keep track of how many people are seeing captchas and it was/is actively monitored to correct any issues that cause it to go up. In a lot ways think of it in a similar vain as Abuse filter.
Case in point for the fundraiser. We *never* want to show a captcha unless were dead certain its fraud. I like this as captchas are horrible beasts of confusion for most people. They suck on a desktop and just require more typing for people that want legitimate accounts. More steps means less accounts.
I'd also still like to consider alternatives to CAPTCHA entirely. Cf. https://www.mediawiki.org/wiki/Requests_for_comment/CAPTCHA
Sure but my point is that we *shouldn't* even show a captcha unless were dead certain that the user in question has done something suspicious. Most cases do not require them.
--tomasz
On Fri, Oct 5, 2012 at 1:14 PM, Tomasz Finc tfinc@wikimedia.org wrote:
On Fri, Oct 5, 2012 at 12:32 PM, Steven Walling swalling@wikimedia.org wrote:
I don't know how they do that, but would be willing to consider it, contingent on input from Chris Steipp and Ryan Lane.
My knowledge of this is circa 2009-2011 when I designed and implemented it with Arthur so i'm cc'ing Katie to correct anything that I get wrong. The extension has an internal engine that combines rule sets with a weighted threshold over *when* a user should see the captcha. The system is able to keep track of how many people are seeing captchas and it was/is actively monitored to correct any issues that cause it to go up. In a lot ways think of it in a similar vain as Abuse filter.
That's pretty much accurate, although it would require some work to abstract out of the fundraising context. The system that I put in place for the 2010 fundraiser to help prevent fraudulent credit card transactions was a multi-layered and modular system that used a number of heuristic pieces to determine the likeliehood that an attempted transaction was fraudulent. We relied primarily on third party service offered by MaxMind called 'minfraud' that looked at various pieces of information submitted (like a user's IP address), and it would return a 'fraud score', which mapped to the likeliehood that the transaction was fraudulent. We played around with a few ideas to build on top of that likeliehood (eg IP address velocity - how many times is the same address attempting to make a transaction in a given timeframe).
The system allowed (maybe still allows?) for different actions to be taken depending on the resulting fraud score. For the 2010 fundraiser, we initially set it up so that a vast majority of transactions would never see any sort of 'challenge' (eg captcha). Then there was a second tier of fraud scores that would trigger a 'challenge' (we were using reCaptcha). The third tier was an outright rejection. Ultimately, we wound up entirely disabling captchas because a relatively small amount of users fell into the 'challenge' bucket who seemed to be fraudsters and there was a huge outcry over a) our use of reCaptcha b) use of a captcha system that was not particularly accessible outside of Western/latin character contexts c) a captcha system at all.
I suspect something similar could be implemented here. But I will warn you that cpatcha is a huge can of worms. At the time, I did a lot of research of captcha effectiveness and the only captcha solution that seemed remotely effective was reCaptcha (none of the existing captcha solutions packaged in MediaWiki extensions even came close to reCaptcha's effectiveness). We used it, but not without an awful lot of fuss (because it is not an open source solution). Beyond that though, there are many legitimate concerns around the effectiveness of captcha in general (even reCaptcha has reportedly been 'cracked') - google around for more info if you ever have trouble falling asleep or are just generally curious about it.
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
Why even have a box to keep me logged in on mobile.....? Just keep me checked in.
Also, what's the rationale behind *always* having a captcha? Why can't we employ what the fundraiser does with a captcha *only* being show *when* we detect the user as high risk. This yet again would make this simpler and faster for not just mobile users but everyone.
--tomasz
On Thu, Oct 4, 2012 at 5:12 PM, Steven Walling swalling@wikimedia.org wrote:
Hey,
Today we (editor engagement experiments team) started an A/B test of a new account registration page on English Wikipedia.
I wanted to bring this up on mobile because, because while it doesn't impact users visiting via MobileFrontend, the design does play niceer with mobile browsers, at least compared to the current default. (See the attached screenshots of mobile Safari on iPhone and iPad. I also tested on Jelly Bean.)
When we move to productize this, we should talk more about implementing the design in a way that jives with what the mobile team is working on.
-- Steven Walling https://wikimediafoundation.org/
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Fri, Oct 5, 2012 at 4:10 PM, Jon Robson jdlrobson@gmail.com wrote:
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
Why even have a box to keep me logged in on mobile.....? Just keep me checked in.
Yes! Just kill it!
--tomasz
On Oct 5, 2012, at 1:19 PM, Tomasz Finc tfinc@wikimedia.org wrote:
On Fri, Oct 5, 2012 at 4:10 PM, Jon Robson jdlrobson@gmail.com wrote:
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
Why even have a box to keep me logged in on mobile.....? Just keep me checked in.
Yes! Just kill it!
You'll note that the Mobile Sign In design document addresses this exactly by saying "ditch it because x, y, z".
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On 5 October 2012 20:20, Tomasz Finc tfinc@wikimedia.org wrote:
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
I suspect a *significant* minority sign up on shared computers in libraries, colleges and training suites.
We need to be mindful of their security.
On Sat, Oct 6, 2012 at 8:42 AM, Andy Mabbett andy@pigsonthewing.org.uk wrote:
On 5 October 2012 20:20, Tomasz Finc tfinc@wikimedia.org wrote:
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
I suspect a *significant* minority sign up on shared computers in libraries, colleges and training suites.
We need to be mindful of their security.
And almost none of these scenarios are done on a phone. Phones are personal devices that *rarely* move from person to person. Thus I ask us to get rid of it on all mobile interfaces.
--tomasz
On Tue, Oct 9, 2012 at 1:32 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Why not auto check keep me logged in? Do most people create account on public terminals? I doubt it. Most people will create them on their own computers/phone/etc. It would make the form even simpler.
I suspect a *significant* minority sign up on shared computers in libraries, colleges and training suites.
We need to be mindful of their security.
And almost none of these scenarios are done on a phone. Phones are personal devices that *rarely* move from person to person. Thus I ask us to get rid of it on all mobile interfaces.
As a followup to this: we're just going to remove the option.
On top of creating another choice that is potentially unnecessary, the request is somewhat confusing in light of the fact that creating an account automatically logs you in.
2012/10/5 Steven Walling swalling@wikimedia.org:
Hey,
Today we (editor engagement experiments team) started an A/B test of a new account registration page on English Wikipedia.
Is it a part of MediaWiki core or a completely local hack in en.wikipedia?
Is it possible to localize the messages there, like "Enter a desired username"?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
On Fri, Oct 5, 2012 at 12:31 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
2012/10/5 Steven Walling swalling@wikimedia.org:
Hey,
Today we (editor engagement experiments team) started an A/B test of a new account registration page on English Wikipedia.
Is it a part of MediaWiki core or a completely local hack in en.wikipedia?
Is it possible to localize the messages there, like "Enter a desired username"?
For this iteration it's just JS magic tranforming the old form for English Wikipedia, in order to test the impact of the new design. Second iteration we'll add a new clientside form validation API.
When we get ready to merge anything to core, we'll take the time to do proper i18n/l10n, naturally.
