What are the differences between CAPTCHA and reCAPTCHA?
What is the best situation to opt for reCAPTCHA?
CAPTCHA is the human validation test (usually the blurry squiglly letters that need to be deciphered) used by many sites to prevent spam.
reCAPTCHA is a reversed CAPTCHA - the same test, used not only to prevent spam but to help in the book digitazion project. In other words, the reCAPTCHA tests are not meaningless combination of words, but excerpts from books that undergo digitation, while CAPTCHA uses several human validation methods including math or general knowledge questions, visual puzzles and even chess puzzles.
Google purchased reCAPTCHA several years ago, and now it is also used to collect street view data
A CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a program that can tell whether its user is a human or a computer.
The process involves a computer asking a user to complete a simple test which generated by computer. Because other computers are unable to solve the CAPTCHA, any user entering a correct solution is presumed to be human. Sometimes it is described as a reverse Turing test, because it is done by a machine and targeted to a human. reCAPTCHA does exactly that by channeling the effort spent solving CAPTCHAs online into "reading" books.
reCaptcha is hosted by Google, and one of the more interesting things about it is that it is used to digitize text of old newspapers and books. That’s why there are two “sections” of a reCaptcha instead of the single series of characters for CAPTCHA - one is known text, the other is not. If you get the known one correct, it assumes you got the second one. Then the next time it offers up that same “unknown” text, it is considered possibly known.
A few more times with the same result for the “unknown” text, and it becomes “known” and the text it originated from can be correctly digitized. Clever, eh?
Also, because of frequent updates, I would expect reCAPTCHA to be slightly better at preventing bots from solving them.
Reference: https://anydifferencebetween.com/difference-between-captcha-and-recaptcha/
reCAPTCHA is a type of CAPTCHA. It is easier for humans and relatively difficult for bots to crack, which is the sole purpose of having a CAPTCHA in forms. If you need a CAPTCHA, go for reCAPTCHA.
I think I remember CAPTCHA from a few years ago for Gmail.
reCAPTCHA is easier for people. I usually had some difficulty getting past the old CAPTCHA, because I couldn't quite read the letters and had a hard time seeing the difference between "O" and "Q" or other similar looking letters like "mn" or "nm".
I recommend reCAPTCHA over CAPTCHA since it's easier for actual users, and you can always add a firewall to help block bots.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would like to know what do you think about adding captcha mechanisms to registration forms?
I notice that many sites don't use captcha mechanisms in their registration forms(examples: http://djdesignerlab.com/2010/04/14/25-cool-sign-up-and-login-form-designs/).
I would like to open this topic to see what people thinks.
I always thought that we should make our forms as secured as possible, but from another point of view there are many users out there that don't really have to much patience to fill a captcha at a registration page.
-Do you think adding this mechanism to a registration page can drastically drop the amount of registered users at long term?
-How dangerous can it be not including this mechanism at a registration page?
I setup captcha on my system for one main reason: To know that the user who register or is registered is actually human. Don't forget that captcha is not only used for registration and/or login security checks. SO, for example, have captcha if it senses that there's too frequent edit on the same question/answers in a very short time span. Captcha, in this case, is a check to see if the editor is human instead of a robot.
In essence, you have to make a good decision of where you will like to use captcha (if you're planning to use it) and how will it serve for your purpose.
Hope this helps.
I can't stand captcha's at all. I understand the need for checking against bots, but why should the legitimate end user have to pay the price in reading obfuscated words... that's my personal opinion.
I have seen some sites actually ask basic questions such as, "The colour of the sky is: " provided with a textbox and clue to the word length. Its a bit more on the fly but to be honest I have had no problem getting the right answer with the ones I have seen.
I refuse to implement it - its a big 'F U' to users. The only exceptions are those where numbers are required... these are much better as there is no casing involved, half the time with letter based captchas you can hardly tell which letter are uppercase or lowercase.
We've come a very long way in web accessibility, captcha's are sending us in the wrong direction. Recaptcha does serve a purpose I agree, but its still a captcha.
Danger is one thing, but the flood of SPAM you will get is another. I have seen situations where a commenting system was rendered useless because of the SPAM that was being added.
There are definitely issues with CAPTCHA's beyond simple inconvenience. There are accessibility issues with a lot of them. I prefer RECAPTCHA which does a really nice job of handling accessibility while performing a service at the same time.
There are other options out there, Akismet is a verification tool that does not require user input. I would recommend looking at that if you are trying to avoid the manual verification process.
I think it's a case by case situation. If your site is public and popular and bots could gain a financial value for a clever programmer by posting content to your site, then the captcha is the way to go.
If you find that your site does not get much traffic or it is on a private network, then there is no point to employ a captcha.
I would suggest going without it at first, then pull it out of your tool belt if spam becomes a problem.
Me and a few of my fellow small publishing friends created a private database to pool IP addresses and netblocks of known spammers. Some of us have removed our recaptcha integration in favor of backend IP check. Some backlink spammers are getting through, but its slowing down as the database gets larger. We've opened up the api so others can give it a try: http://www.spamerator.com
CAPTCHA? Fine. Set it up. But please make it human-friendly, like this one:
The letters are clear, big and readable. And if you don't use images, I have implemented a base64 one in addition.
Does anyone have recommendations/experience of how to find people willing to do usability testing of web based apps? I suspect I may need people who might actually be potential users, because mine is a commercial/vertical app which contains some processes and terminology which may not mean much to the average joe/jane.
I have a fairly robust prototype of a web app which is designed for people in Sales Management and before I go too much further with it I want to try a couple of key pieces out on some live users. I have a few friendly faces I can turn to (and have already), but I really want strangers who will not feel they need to be nice to me about it.
I'm fine designing the usability tests themselves, it is finding the guinea-pigs that is proving difficult.
I've used this service a couple times and have been impressed with the quality of the feedback they provide.
usertesting.com
Don't Make Me Think has the exact chapter you would be interested in. Basically, you should set up your test in such a way that it's not about being nice or not, but it's about finding out whether the user can use it or not. This way you can use all your relatives or friends you want and know.
In a nutshell: set up a desk with a computer that has access to your app, get two chairs, a notepad and a pencil. The book mentions a video link to your co-workers, but let's skip that. You get your tester and place her in front of the computer, while you sit beside her with notepad and pencil at the ready. Be specific about that for the sake of this test, it's technically impossible that she would do something wrong, because that's what you are interested in.
Ask her then to do some specific tasks; You present her with some kind of state in the application, and ask her to do something. Example: "If you would want to do a new entry, how would you go about doing it". Ask her to describe what she's thinking, her train of thought; "I would seek for some kind of 'add' or '+' labeled button, let's see if I can find it. They're usually underneath the lists", etc. Make notes of the subtleties of her gestures and faces, like if she hunts with the cursor for something, or if she's grimacing in frustration.
If she can't find that add button quickly enough, there's a usability problem.
But really, buy the book. It's a great read, worth every penny.
Do you have a list of local companies who could be potential customers for your application? This would be a good place to look; you can simultaneously get users for user testing and make good contacts.
Take yourself to Starbucks and put a sign on the back of your laptop which says "Ask me for a Free Coffee" make sure you use some screen recording software like Silverback to record the session for later.
I read this a few days ago and it might help:
http://www.joelonsoftware.com/uibook/fog0000000249.html
Does your organization have a Sales team that will allow you to borrow appropriate users? I think that would be a good start for Alpha testing of the UI. After that, perhaps your customer can use the Beta UI for further testing.
Believe it or not an ad in Craig's List works for us. Simply offer a reward, we use $50 prepaid debit cards, and you can usually get 10 - 20 people per ad.
see useit.com - there are several levels of usability testing, and it is obviously critical to recruit users that are representative of your target market
You could also check out uTest.com, a software testing services that relies on "crowdsourcing" the testing process. While more on the side of functional and technical testing, I'm sure you could negotiate a test project more focused on usability testing.
My coworkers and I were having a discussion about this yesterday. It seems that no matter how well we prepare and no matter how much we test and no matter what the client says immediately before the site becomes public, initial site launches almost always seem to be somewhat rocky. Some clients are better than others, but often things that were just fine during testing suddenly go horribly wrong when the site becomes public.
Is this a common experience? I'm not just talking about functionality breaking down (although that's often a problem as well). I'm also talking about sites that work exactly the way we wanted them to, but suddenly are not satisfactory to the client when it's time to make the site public. And I'm talking about clients that have been familiar with the site during most of the development process. Meaning, the public launch is definitely not the first time they've seen the site.
If you've dealt with this problem before, have you found a way to improve the situation? Or is this just something that will always be somewhat of a problem?
Don't worry. This is completely and entirely normal and happens with every piece of software. Everything that can go wrong will go wrong, and the most volatile entity in the development process, the client, will be the cause of these things.
You could do all the Requirements Gathering in the world, write a 100 page Proposal, provide screenshots and updates to the project hourly and the client will still not approve. On a personal note, I feel that the Internet is one of the worst mediums for this, as designs are a lot more free-flowing nowadays and the client will always have a certain picture in his/her mind; one that won't look like the finished product.
I find that a bulletproof contact with defined stages and sign-off sheets are the best way to handle such a situation. Assuming that your work is contracted you should ensure that at each stage the client is shown the work and is forced to approve each and every change made. At least that way if the client wants something changed you can tell them that they've already signed off that section and the additional work will cost them extra (also defined within the contract).
Not only did this approach work for me, it made the client stop and think about what he/she REALLY wanted. Luckily for me many of my clients are already tech-oriented, so they understand that these things can take time, but those that haven't a clue about Web Development expect things to be perfect within a couple of days. As long as you make sure that everything is covered in the contract the client will think about what they want and won't pester you with issues after.
Of course, anything you can do in regards to Quality Control would be fantastic and help the project move along nicely. Also ensure that some form of methodology is planned out before the project and that this methodology is known by the client(s). Often changes in fundamental areas can be costly and many clients do not seem to realise that a small change can require many things to be changed.
Yes, saw this several times on our projects (human beings are fickle).
Something that helps us in these situations is a good PM/Account Manager that can handle the customer, which makes things a little bit bearable on the technical level.
Web site launches are usually fairly smooth for us. Of course, we do extensive validation including code inspections, deployments to proto-servers (identical to our production servers), and mountains of documentation.
After every launch, we have a meeting to discuss what went well and what didn't so that we can make adjustments to our overall process and best-known-methods documents.
As for clients that change their minds at the last minute... sigh... we minimize that by having them sign off on the beta version. That way, there is no disagreement when the project is launched. If there is a disagreement, there is always a next release.
For what it's worth, the last site launch I did went off without a hitch. Now, it wasn't a high-traffic site, and there were some bugs that I did eventually fix, but there wasn't anything troubling on the day of the actual launch.
This was an ASP.NET/C# site. It wasn't terribly large or complicated, but it wasn't trivial either. Probably the most notable thing is that it was 100% designed, implemented, and tested by myself, from the database schema all the way up to the CSS. It was also my first time using ASP.NET. There were plenty of bumps in development but by the time I launched it I was pretty familiar with them and so knew what to expect.
I think the lesson to be learned from this is to have a good design up-front, solid implementation skills, and good testing, and a new site doesn't have to be a nightmare. There's at least a possibility of a trouble-free launch.
I wouldn't limit your statement to just web sites. I have worked on a lot of projects over the years and there are always details that get "discovered" when going live. No amount of testing removes all the fun things that can happen.
One thing I will say is what you learn in the first couple of hours of a new system going "on-line" is way move valuable that all the stuff learned during development. It's show time when the real cool problems and scenarios appear. Learn to love them and use these times as a learning point for the next time. Then each time it will be just at fun!
We used to have this problem a lot, but much less recently.
Partly for us it is about firmer project management and documenting the specification (as suggested in other answers here) but I believe more of the difference came from:
Expectation management - getting the client to accept that iterative changes are still to be expected after launch, that this is normal and not to worry about it
Increasing authority - we are now a well established (13 years) web developer and we can speak with a lot of expertise
Simply being more experienced - we can now predict in advance most of the queries that are likely to come up, and either resolve them, mitigate them or bring them to the client's attention so they don't sting us on the day
Plus, we rarely do big fanfare launches - a soft launch makes things much less stressful.
My experience is that web site launches are almost always rocky. I've only had two exceptions to this common truth. The first was a site developed for a small business ran by one person. This went smoothly because, well there was only one person to please so is was fairly easy to track what they wanted. The other was a multi-million dollar website launched by a fortune 500 company. This happened to go smoothly because there were 2 PMs and a small army of consultants there to manage the needs of the customer. That coupled with a one month of straight application load testing and a 1,000 user beta launch meant when the site finally went "live", I was able to get a full nights sleep (which is fairly uncommon). Neither of these situations constitute then norm though. Of course, there's nothing better than several thousand beta testers hitting your site to help find those contingencies that you never thought of.
I'm sure you can figure out the kind of errors that always sneak in, so for example is it due to rather superficial testing? E.g. randomly clicking around and checking if things appear to be right.
In order to improve I propose something along the following:
Create documents/checklists that specify all testing procedures.
Get regular people to test, not just the folks who built the application.
Setup a staging environment which closely resembles production.
Post-launch, analyze what went wrong and why it went wrong.
Maybe get external QA to check on your procedures.
Now, all those suggestions are of course very obvious but implementing them into your launch procedures will require time.
In general this really is an ongoing process which will help you and your colleagues to improve. And also be happier, because fixing bugs in production just makes you age rapidly. ;-)
Keep in mind, you won't be done the first time. Documents are heavy which is why people don't read them. People are also lazy and don't follow the procedures. This means that you always have analyze what happened, go back and improve the procedures.
If you have the opportunity I'd also spend some time on looking why nothing went wrong with another launch and comparing this to the usual.
I'm specifically thinking about the BugMeNot service, which provides user name and password combos to a good number of sites. Now, I realize that pay-for-content sites might be worried about this (and I would suspect that most watch for shared accounts), but how about other sites? Should administrators be on the lookout for these accounts? Should web developers do anything differently to take them into account (and perhaps prevent their use)?
I think it depends on the aim of your site. If usage analytics are all-important, then this is something you'd have to watch out for. If advertising is your only revenue stream, then does it really matter which username someone uses?
Probably the best way to discourage use of bugmenot accounts is to make it worthwhile to have an actual account. E.g.: No one would use that here, since we all want rep and a profile, or if you're sending out useful emails, people want to receive them.
Ask yourself the question "Why do we require users to register to access my site?" Once you have business reason for this requirement, then you can try to work out what the effect of having some part of that bypassed by suspect account information.
Work on the basis that at least 10 to 15 percent of account information will be rubbish - and if people using the site can't see any benefit to them personally for registering, and if the registration process is even remotely tedious or an imposition, then accept that you will be either driving more potential visitors away, or increasing your "crap to useful information" ratio.
Not make registration mandatory to read something? i.e. Ask people to register when you are providing some functionality for them that 'saves' some settings, data, etc. I would imagine site like stackoverflow gets less fake registrations (reading questions doesn't require an account) than say New York Times, where you need to have an account to read articles.
If that is not upto your control, you may consider removing dormant accounts. i.e. Removing accounts after a certain amount of inactivity.
That entirely depends.
Most sites that find themselves listed in bugmenot.com tend to be the ones that require registration for in order to access otherwise-free content.
If registration is required in order to interact with the site (ie, add comments/posts/etc), then chances are most people would rather create their own account than use one that has been made public.
So before considering whether to do things like automatically check bugmenot - think about whether their are problems with your business model.
There are a few situations where pay-to-access content sites (I'm thinking things like, ahem, 'adult' sites) end up with a few user accounts being published publically (usually because someone has brute-forced some account details), and in that case there may be a argument for putting significant effort into it.
From an administrator viewpoint absolutely. That registration is required for a reason, even if it's something just as simple as user tracking/profile maintaining. Several thousand people using that login entirely defeats the purpose. IP tracking could help mitigate this problem, but it would definitely be hard to eliminate entirely.
No need to worry about BugMeNot: http://www.bugmenot.com/report.php
With bugmenot, keep in mind that this service is not actually there to harm the sites, but rather to make using them easier. You can request to block your site if it is pay-per-view, community-based (i.e. a forum or Wiki) or the account includes sensible information (like banking). This means in virtually all situations where you would think that bugmenot is a bad thing, bugmenot does not want to be used. So maybe things are not as bad as you might think.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm not a usability specialist, and I really don't care to be one.
I just want a small set of rules of thumb that I can follow while coding my user interfaces so that my product has decent usability.
At first I thought that this question would be easy to answer "Use your common sense", but if it's so common among us developers we wouldn't, as a group, have a reputation for our horrible interfaces.
Any suggestions?
Source: http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png
Read Don't Make Me Think by Steve Krug. It is a great starting point, and an easy short read.
EDIT: This is mainly for web usability though, but it would still be a good read even if you are doing rich clients.
Just two things, really:
"A user interface is well-designed when the program behaves exactly how the user thought it would" - quoted from Joel Spolsky's User Interface Design For Programmers
Put your designs in front of a user. A real end-user is best, but for lightweight, rapid feedback, you can't beat hallway usability testing i.e. grab a co-worker.
If you remember Joel's advice and make sure you get feedback on whatever you do and act on it i.e. iterate, you'll not go too far wrong. And I would echo the recommendation for Steve Krug's Don't Make Me Think - it's probably the best work-related book I've read, bar none, and is just as applicable to desktop software as websites.
Hope this helps.
Don't make things work in a different way than your users are expecting (i.e. breaking the "back" button when using Ajax in web forms
Follow the K.I.S.S principal
Really, any rules someone posts will be a variation on the theme:
Don't Make Your Users Think
"Don't Make Me Think" has already been posted, see also
Design of Everyday Things and Designing with Web Standards which are also great for light usability reading.
Avoid modes. It's frustrating to a user when input works sometimes but not others, or does different things at different times.
The single most important piece of advice I'd give someone is to work on the UI first. Pen and paper and all. That way, you won't subconsciously couple buttons to functions, input fields to variables, etc.
The best UI might be a pain to code, and if your backend code is mostly written, it will sabotage your thinking.
Other than that, I'd point to Apple's Human Interface Guidelines. Of course, if your platform is not OS X, take the OS X sections with a lot of salt. What works in OS X might not work on Windows. You should embrace your platform's idioms.
OS X stuff aside, that document has some pretty good starting points on the fundamentals.
Here are some simple rules:
Fewer clicks are better.
Frequently used features should be easier to find.
Features for "advanced" users can be harder to find than the ones above.
Think about the number of mouse/keyboard clicks it takes a user to get to something.
PS - please don't tell the Microsoft Office 2008 people about this; the poor little guys would cry themselves to sleep tonight! :)
Think about the users that will use your app. Why are they using it and in which context?
Will the majority be pro users that know the domain in which the application is used and use the app a lot? Then don't be afraid of adding a lot of data to the screens as long as it arranged logically for users (normally that is not in alphabetical order :-). Think trade screens for stock borkers or airplane cockpits.
Are users occassional users? Keep it simple. Avoid context switches (keep all/as much as possible of necessary data for a task on the screen at each time). Don't break expectations of how gui widgets normally work. Design for failures.
Anything in between? Allow users to grow in the UI. Track usage so you can later determine where users seem to spend the most time so you can improve the most used areas of your app.
Test your app on friends and colleagues (the corridor test) to see if they are able to use it efficiently.
That's a start.
I suggest to read these blog posts from the Enso creators.
Of course they repeat guides/ideas/advices from books such as
The Design of Everyday Things and About Face, but nevertheless, the posts contain quite a few insights and (IMO) they are a good read.
What information does your user need, put that on the screen and nothing else. If you cannot define what the user needs - get another user.
Remember that your application will be one of many the user will have to deal with. Don't do things just to be different or kewl. Don't come up with unusual graphics, behaviors, terminology, or interactions. Use the standard OS controls, conventions, utilities, and behaviors.
Let your app interoperate with other apps; allow cutting and pasting of data, save your data in formats other apps can read, and allow importing data from other apps instead of using your UI.
If you are making a desktop app, do not try to take over the user's computer. Leave the user's Documents folder, task bar, and application preferences alone. Don't change anything already installed on the computer. Allow scripted or command-line interactions.
If you're making a web app, do not try to take over the browser. Do not try to subvert the standard menu bars, history, layout, or fonts. Allow the user to change the page using Javascript.
(1) Common actions should require as little effort as possible and should be obvious; on the other hand, actions that are rarely needed can be require a lot of steps and can be hidden behind menus and dialogs. To be able to do so, you should always describe what the user will want to do with the application by listing use cases.
(2) A UI should be selfdocumenting. The manual should be integrated in the application's dialogs and menu's, as users don't read separate manuals. For example, the keyboard shortcut should be shown in the menu item representing the action it is associated with.
Provide keyboard shortcuts for power users (even if it is as simple as "hit enter to search")
Don't put too much on screen at once.
If you pop up a messagebox, your users generally won't ever read it.
In addition to the other recommendations here, I'd recommend Designing Interfaces by Jenifer Tidwell as a good way of becoming familiar with UI conventions.
Also, The inmates are running the asylum By Alan Cooper is excellent for providing an insight into how to approach interaction design.
A good follow on to Don't Make Me Think is Robert Hoekman's Designing the Obvious. It's more focused on web applications, as opposed to web sites like in Krug's.
Simple is better than complex
Complex is better than complicated (eliminate 'nested ifs')
Intuitive (good elements needs no explanation)
Follow the convention (for example, underlined means link, red means error, tab goes to next field, etc.)
Use semantics to apply the logic (header reads first, paragraphs next)
whitespace is important