These "security" devices hurt user experience.
Some of the hacking/security "industry" guides suggest manually completing one of these CAPTCHA mechanisms as a person before allowing your interactive program to interface with the target site or application. This means that once you're authenticated as a person most sites assume you will still behave as a person. Just as people research habits of good visitors, bad visitors research the patterns of the security systems on the websites.
The animated captcha you've referenced has been compromised already. Another major CAPTCHA (reCAPTCHA) was also hacked by people who took the time to examine the system, look for a pattern and break it.
Why use these in regard to User Experience?
The benefits of these mechanisms are simple. If your site runs the risk of being massively exploited to the point it severely limits the user experience, then mechanisms need to be in place that prevent people (or applications) from automatically completing forms and require users to participate as good, wanted users.
Why should I not use these in regard to User Experience?
When you're using one of these devices (gimmicks) to keep people from exploiting a website instead of hardening the website itself, basically it makes everything a little harder on your normal visitors and their user experience has the potential to be much worse. They may see this hurdle every time they access the site or the application. If it causes their account to be locked, now they have other hurdles to overcome because of their misunderstanding of how to complete your device successfully, or because they misspelled or misread a character.
CAPTCHA mechanisms often require that the visitor complete the test in English. This might not always be the best solution.
In regard to the sound challenge, if someone isn't familiar with the language and they're trying to use the audio portion: if they have a sound card, and are not in a loud place, and can actually hear the audio, then they have to recognize the phrases and translate them into characters that phonetically sound like the originating language. This is also pretty complicated and require a good understanding of phonetics.
There are also math CAPTCHA mechanisms that require people to solve a math problem. These are easily beatable because most computers are pretty excellent at math, much more so than their users.
If someone's trying to get into your site or app to compromise it and you've not hardened the security, the exploiter may only see a mechanism once. There are several security mechanisms available on the market that work similar to these I've mentioned. With any amount of time they can all be beaten and are all basic gimmicks presented as solutions to the problem of lack of budgets (or laziness) in regard to security when designing websites and applications. Then the exploits are made available on the internet and it's only a matter of time before the device's original intention is useless.
The first thing we look at is user interaction. User habits are a great indicator as to what to expect from a website's normal visitors.
Most users take time to complete a post or form; they read things at average speeds and interact in a standard way. Even auto-complete usually requires some sort of interaction.
- If people complete the forms too quickly (inhumanly impossible) then chances are they've copied and pasted their content or they've automatically injected into the board.
- If they take an excessively long amount of time to respond (more than the session time) then they've attempted to compromise the system the other way.
Use the research
If you do simple things like check the length of time it takes to post, check if the mouse has moved while the person was on the page (if it's a computer), see if they've scrolled (on a mobile device), check if the user is using a real browser (not something like cURL), or if they've actually spent some time on the page actually reading what they're going to interact with, then you're much more likely not to get a false positive. Check to see if they've been on the site for a little bit of time before posting. There are circumstances where someone writes out their thoughts in an application like Microsoft Word (like on this site where people cite their references) and instantly pastes them in; even then those people will typically alter their content before posting or they will have been on the site for some time before adding their content. At the point someone exceeds their expected limits (or breaks form), THEN you present them with a challenge and response.
A new type of CAPTCHA
If you make people provide an answer to a problem in their native language or recognize a shape and provide their response in their native language (through multiple choice and on -the-fly translation) it's much more user friendly because with a library of thousands of images(understood in all cultures) the attacker would theoretically have to figure out what the image is, then find its meaning, then store a database of these images for repeated attempts. If the images and answers load at random, the attacker has a much harder time finding a pattern.
Here's a working example of the concept featuring language translation:
A CAPTCHA might stop a lot of new abusive traffic. It will look good to the people who run the website. At the point the CAPTCHA is compromised, it's lost its charm and is simply a hurdle driving real visitors, customers, and users away.