[flagged]
Doom Captcha (2021)
81–90 of 136 posts
Re: Doom Captcha (2021)
#82Earlier quoted context omitted.
You don't actually need much, for a form I used to get spam in I just added a "write 42 here" so anyone who actually cares to read would be able to fill it. spam fell to 0. (for a site with a slightly higher profile this wouldn't be enough, but for a minor corner of the internet with no ill intent actually aimed at it that turned out to be enough to block the fuzzing "fill all the forms" spam)
Similarly an empty input field that is css'd to be outside the viewport is often filled by spambots but not humans. But I like the edge case UX of your idea more.
Just watch out that Chrome’s autofill doesn’t fill it in. Cost us a huge chunk of new signups until we found out. Chrome ignores autofill directives under some circumstances.
Re: Doom Captcha (2021)
#83Who else is clicking "click to start" like me? It turns out you have to choose one of the buttons. I thought they are there to allow me to enable/disable the sound, but they also both act as start buttons. Didn't know a simple interface with a sound switch and a game start button can be designed this badly.
Who else is missing the forest for the trees? It turns out you have to focus on the merit of the contribution instead of inconsequential UI design optimization. Didn’t know a simple demo (with disclaimers) from someone who is clearly doing something novel could be commented on this badly.
I'd argue that if it confuses the user it's not inconsequential. And also, something can be both innovative and at the same time have room for improvement. Companies are literally chasing down user feedback.
A user's feedback is one of the best things that can ever happen to your program, the worst is to never ever get used by anyone, and the second worse is to have the users walk away with no idea why.
Re: Doom Captcha (2021)
#84Earlier quoted context omitted.
>inconsequential UI design optimization I certainly was confused and had a hard time starting it. If a significant amount of people can't even figure out how to start the game, the problem isn't inconsequential.
I agree with you, but this is distracting from the merits of the demo. Also, this is currently #2 on the front page so clearly many people are able to navigate the demo UI, even if it is suboptimal.
I decided to leave only a secondary comment at the bottom of the thread for the same reason as yours and still got 14 ups (i.e. thanks) in a short time before this branch bubbled up. People definitely get confused and that's worth talking about before the merits of the demo, cause you have to run it somehow. I almost left too thinking it's broken, hugged or something. It is distracting and we'll live through it :)
Re: Doom Captcha (2021)
#85Earlier quoted context omitted.
I think the easiest way to fix would be to add a colon, so that you see you have to pick an option: Click to start: [sound on] [sound off]
Or have the "click to start" text cliclable and start the game with sound. Anyone who wants it muted will make sure to first click the mute symbol and then the ambiguity resolves itself anyway.
MathDoku does that and I hate it, because sometimes cookies expire and it plays loud music in the middle of the night when I start it. What's wrong with
[ CLICK TO START ]
[x] Allow sound
Re: Doom Captcha (2021)
#86Earlier quoted context omitted.
Similarly an empty input field that is css'd to be outside the viewport is often filled by spambots but not humans. But I like the edge case UX of your idea more.
Just watch out that Chrome’s autofill doesn’t fill it in. Cost us a huge chunk of new signups until we found out. Chrome ignores autofill directives under some circumstances.
It's also visible for users with CSS overrides and/or other browser inpairments. The more I think about it the more strongly I prefer the "type 42" explicit input field.
Re: Doom Captcha (2021)
#87Who else is clicking "click to start" like me? It turns out you have to choose one of the buttons. I thought they are there to allow me to enable/disable the sound, but they also both act as start buttons. Didn't know a simple interface with a sound switch and a game start button can be designed this badly.
skill issue, literally filtered by two buttons on the screen
Re: Doom Captcha (2021)
#88Earlier quoted context omitted.
Or have the "click to start" text cliclable and start the game with sound. Anyone who wants it muted will make sure to first click the mute symbol and then the ambiguity resolves itself anyway.
MathDoku does that and I hate it, because sometimes cookies expire and it plays loud music in the middle of the night when I start it. What's wrong with [ CLICK TO START ] [x] Allow sound Keep it simple
I think most people would agree your solution is preferable, but the spirit of this subthread was "what's the smallest change that would improve things" rather than "how could it be redesigned from scratch?"
I would also argue the MathDoku problem is different. That sounds like a mode confusion type issue, where the user expects a certain level of automation but it has been disabled by the system without adequate feedback.
Re: Doom Captcha (2021)
#89Who else is clicking "click to start" like me? It turns out you have to choose one of the buttons. I thought they are there to allow me to enable/disable the sound, but they also both act as start buttons. Didn't know a simple interface with a sound switch and a game start button can be designed this badly.
skill issue, literally filtered by two buttons on the screen
You mean the buttons are the real CAPTCHA?
Re: Doom Captcha (2021)
#90Earlier quoted context omitted.
I don't think it's that considerable, I made a script to defeat it with vision in only a few minutes: https://gist.github.com/enlyth/a177e4102b0da37a73587e15dbd68... This could be further optimized to not scan the whole screen, and faking some human like mouse movements shouldn't be that hard too
Wow, that's pretty impressive to me and I think it's awesome that you were able to put this together quickly. I admit that I don't have a CV background, so maybe this is easier for a programmer who's already experienced in that area.
To be fair I don't think you need CV in this specific case where the problem space is very limited.
1. There's no lighting, so the enemies have specific, fixed pixel colours that don't appear in any of the backgrounds. Scan and target these.
2. Enemies appear in a specific zone in the canvas. Makes scan faster, combines with below.
If there's expected ambiguity one can a. detect a few interesting background properties by looking at pixels where enemies never appear (e.g corners), and/or b. use a couple of other pixels relative to the candidate match (maybe neighbours, maybe not, could just as well be 20px down, 10 left) to discriminate.
Side story: one day my team was tasked with doing textual document content recognition for some biz. Everyone was like "oh it's going to be $$$ to pull out CV+OCR and have the OCR learn the specific font".
Turns out the document in question was:
- an extremely standardised gov format
- produced only by gov administration
- of a known fixed, overall size with clear identifiable boundaries
- printing known, standardised list of fields at fixed position
- with a known, standard font specifically made for quick automatic recognition
- containing only /[A-Za-z0-9]/ chars (plus a few I can't recall, but essentially dash, plus, slash...)
- on a known, standardised background
- the only variable is the quality of the scan and the size parameters
Cobbled the thing in a couple afternoons, with a quick, simple UI to have the user crop/rotate the doc (putting it mostly upright). It was stupidly fast to run and success rate was very high. Interestingly enough the failure mode was very good as it could reliably tell "ok I can't make any sense out of this" vs OCR which claimed success but outputted gibberish.
You can get surprisingly far with very little when you have known knowns.