| • bzimport | |
| Dec 31 2012, 11:42 PM |
| F10281: Screen_Shot_2013-01-02_at_12.31.37_PM.png | |
| Nov 22 2014, 1:14 AM |
Author: swalling
Description:
Since December's move to Swift for our CAPTCHA generator, the readability of the images (for humans) has suffered a little bit. This has led to an increase in account creation requests, so by improving the readability of CAPTCHAs even just a little bit, we should be able to help keep the queue of account requests (and unhappy new users) down to more normal levels.
Version: unspecified
Severity: normal
Changing storage back-ends shouldn't have done anything like this AFAIK? Can you provide examples?
Could these requests be correlating with when the actual CAPTCHAs were broken and not loading?
swalling wrote:
I should have explained: I corresponded with Aaron and RobLa over email prior to filing this bug, and they confirmed that images were regenerated recently. It all correlates pretty clearly with the bump in requests, which went from under 70/day, to between one and two hundred a day since the 20th.
swalling wrote:
Comparison of test2 and enwp
Comparing the test2 and current CAPTCHAs on English Wikipedia, the former seems much easier to handle. (See side-by-side screenshot.)
Attached:
It looks like maybe the font used by the regeneration script may have changed? Or the ttf definition on the server changed?
(In reply to comment #5)
Created attachment 11582 [details]
Comparison of test2 and enwpComparing the test2 and current CAPTCHAs on English Wikipedia, the former
seems
much easier to handle. (See side-by-side screenshot.)
These are ones I made today. I added more so there are 10K. I assume it's fine to switch to these when the other wikis go back to swift (they were reverted to nfs after some 401 errors).
Attached:
swalling wrote:
Seems good enough for now. Will monitor stats such as account creation requests and we can check in again if necessary.
99% of these requests would be unnecessary if we had a 'load another CAPTCHA' button like most sites have. Even the 'good' CAPTCHA images are unreadable a large percentage of the time. This problem also deters new editors who have to fill in CAPTCHAs to save their edits.
swalling wrote:
99% of these requests would be unnecessary if we had a 'load another CAPTCHA'
button like most sites have. Even the 'good' CAPTCHA images are unreadable a
large percentage of the time. This problem also deters new editors who have to
fill in CAPTCHAs to save their edits.
A refresh button is definitely one of the options E3 is willing to try as a followup. This was a stop gap measure.
(In reply to comment #12)
99% of these requests would be unnecessary if we had a 'load another CAPTCHA'
button like most sites have. Even the 'good' CAPTCHA images are unreadable a
large percentage of the time. This problem also deters new editors who have
to fill in CAPTCHAs to save their edits.
This is bug 14230, for reference.
Is this really fixed? I run into captcha issues all the time. I'd argue they are still extremely difficult to read..
(In reply to comment #15)
Is this really fixed? I run into captcha issues all the time. I'd argue they
are still extremely difficult to read.
When Littlefoot's mother died in the original 'Land Before Time,' did you feel sad?
swalling wrote:
(In reply to comment #16)
(In reply to comment #15)
Is this really fixed? I run into captcha issues all the time. I'd argue they
are still extremely difficult to read.When Littlefoot's mother died in the original 'Land Before Time,' did you
feel
sad?
A less hilarious/sarcastic interpretation of this answer would probably be: readability is relative. Yes, our CAPTCHA is still not particularly legible, but that's of course partially by design, and it's better than it was before Aaron kindly regenerated the images. Plus, now we serve a refresh button with the CAPTCHA, so if you can't read that one you can cycle through them.
In terms of pressing items with our CAPTCHAs, I would rank readability far below the following two items:
There are probably bugs for both those items that I'm too lazy to dredge up right now.
Thank you Steven for your useful and constructive reply about an issue that effects our users and project.
(In reply to comment #17)
(In reply to comment #16)
(In reply to comment #15)
Is this really fixed? I run into captcha issues all the time. I'd argue they
are still extremely difficult to read.When Littlefoot's mother died in the original 'Land Before Time,' did you
feel sad?A less hilarious/sarcastic interpretation of this answer would probably be:
readability is relative.
It was a lighthearted joke. Try not to be so dour. :-)
In terms of pressing items with our CAPTCHAs, I would rank readability far
below the following two items:
- Support for the visually impaired. Currently the blind or those with
severely poor vision are shit out of luck, and have to request an account (if
they're lucky enough to be on a wiki where the community does this).
This would be bug 4845.
- Non-English CAPTCHAs. For a project that prides itself on broad i18n
support like MediaWiki, it is particularly embarrassing that we make everyone
fill out a CAPTCHA generated from an English dictionary.
And this would be bug 5309.
(In reply to comment #18)
Thank you Steven for your useful and constructive reply about an issue that
effects our users and project.
s/effects/affects/
(In reply to comment #15)
Is this really fixed? I run into captcha issues all the time. I'd argue they
are still extremely difficult to read..
Why do you run into CAPTCHA issues all the time? Established users almost never are presented with them (which consequently is at least partially responsible for the low priority of improving/eliminating the CAPTCHA experience). What behaviors are you engaged in that trigger CAPTCHAs so frequently?
I spend a lot of time creating test accounts on my local wiki... if I'm struggling with captchas other must be and data in account creation event logs seems to support that (I assume that's what ImpressionError refers to...)