Does it make sense to put a "Send it to a friend" button on a webpage? [closed] - language-agnostic

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How often do we see stuff like "Send this page to a friend" on a webpages? Well, I see them quite often.
My question is, how do you guys see it's effectiveness? If I hit a webpage that's interesting, and I think my friend would enjoy it, I can just copy the URL from my browser bar, paste it into the email and press "Send" button. In my opinion, it's usually faster and less mistake-aware then the button/link like this on the webpage. In addition, I'm not really sure what this website does with the emails I enter there - don't they store it and then sell for $1/100 addresses to spammers?
My question is - when you design a website, do you put such links on the pages (it's often seen on sites with some news/articles)? Does it even make sense?

My mom has no idea how to send a URL in email or IM, but she does use "send it to a freind" buttons quite often.

The tell-a-friend button has a number of uses that are not so obvious.
From the users perspective:
A tell a friend button will remind a user to tell a friend when they may not have thought of it themselves, which increases referrals. As part of the page, it's much more noticeable.
It also removes technical questions like knowing how to paste or email the link, having their local email set up properly, being on their own computer with email access, etc.
From the webmaster perspective:
Some sites just send the email. Others can do a lot more some legal and ethical, some not so much.
For the owner of the website, since the referrals go through their server, it allows (if they so choose) referrals to be tracked. They can see what pages are being sent, how often, and which are most popular.
They might also track other info, which lets them run contests, potentially see what people are saying about their pages, etc.
They may track email addresses, which could give them marketing data - for instance if they see that a lot of people are sharing that have addresses at aol.com, they may decide to advertise more with aol.
Referrals can also be incentivised, contests run, etc.

No I don't personally put that on my pages, but for less tech savvy users I imagine this button would help a lot. A lot of people don't make the correlation between the URL in the address bar and the page they are viewing. I know my mother didn't for years.

I put it in there as clients request, I also distribute a free module that does "Tell-A-Friend" functionality for DotnetNuke installations, it is quite popular.
As others have pointed out it really depends on the target audience, more tech savvy users are just going to copy and paste, the less tech savvy are going to find much more practical use of a "tell-a-friend" style module.

I've used those buttons for when I'm not sure which bits of a long URL are part of the bare minimum needed for my friend to get to the page and which bits are data related to my session on the site.
Having said that, when I've used them I've sent them to myself, and copied and pasted the URL from the email I've received!
As others have noted, non-technical people may not understand what the URL is, but a 'Send this to a friend' button is easily understood by all.

Tell-A-Friend type functions also offer a chance to capture traffic stats you might otherwise miss. If you rely totally on people copy-and-pasting the URLs into email, you have no good way to tell how often this happens. If you build a form that sends the message(s) you can count how many people sent how many messages.
Like any web traffic metric this one is flawed, but it can give you an order of magnitude for this behavior, and a way to compare how two different pieces of content of being received.

Related

Telephone Number Harvesting? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am just completing my mobile website, and I was about to put a <a href="tel:"> links, when I thought about telphone number harvesting, in a similar capacity to email harvesting.
This may not be the biggest issue now, but as mobile websites get more popular this is clearly going to be a target, with the biggest issue being it's not going to be easy to ignore spam phone call like it is with email. This is probably a big issue now!
Has anyone heard of this type of telephone harvesting, although not that much different to the ways company already get your numbers, except this doesn't really have a no call list you can join.
I'm not saying this doesn't already exist now, I've had a few calls from the odd "SEO company", to which I laugh at being a web developer. But this is clearly going to make it easier to harvest numbers.
Has anyone got any thoughts on solutions to prevent this, like the js obfuscation for emails? OR is it going to turn in to one of those do it at your own risk situations, like mailto: ?
Update:
Is there a way to obfuscate the phone number? or is this just something to be avoided?
Telephone number harvesting is possible anyway without the tel: attribute. It's not that difficult to write a parser to extract phone numbers from plain/html text. It's much, much less of an issue than email harvesting as it is so cheap to send an email. A phone call costs money and takes time. Plus of course I've never ever heard of this being an issue to anyone. So I really wouldn't worry about it.
If you are still concerned about it, I suggest you read up on email obfuscation techniques. Very briefly these are:
Scramble the data server-side, and decode it in javascript (but what happens if js is off?)
Use an image
Hide behind a captcha (requires user intervention, is a pain)
And of course none of these are bullet proof anyway, a determined harvester can work round all of these. And don't forget human slave farms in the far east.
tl;dr: honestly, it's not worth it.
Not sure what you are looking for exactly, and I don't know about obfuscating phone numbers, but you could try a CAPTCHA (although that wouldn't work well for some users, and is annoying to almost all users) and/or using a phone forwarding service like Google Voice, which would allow blacklisting numbers, or pulling the plug on all phone calls if it becomes a problem.
I don't think it will become a big problem for you, as phone calls are as cheap or easy as an email message, and it isn't as easy to hop phone numbers as it is to switch email addresses, so it might be possible to keep up with blacklisting numbers.

Are there any analytics on how many people actually print webpages? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Has anyone, with a large sampling, done research on how many users actually print webpages? I'm looking for some percentage values. .01%, 1%, etc actually print webpages.
It seems like a waste of time, to create design oriented print pages, if the stats extremely low.
It is very easy to create some print styles for your stylesheet to make printing easier on people.
As an example: http://www.alistapart.com/articles/goingtoprint/
In the same way that not everyone who visits your site will be disabled, the best practice is still to create sites that work for people with accessibility problems.
I don't have a link to a study for you but I'm very confident that it depends heavily on the type of content. I.e. the percentage of people who print a youtube video page is for sure much lower than those who print a recipe from a online cookbook.
So it's probably best to run your own study on the particular website where you need it. You can either make a little poll for the users of your site or track how often pages actually get printed.
This is not a metric that is usually tracked.
Since one needs to differentiate the regular page from the printable page, this requires a custom implementation on the printable version page that sends a particular tracking code/cookie.
It is not that hard to implement, one can even have printable pages tracked in google analytics or any analytic engine, but as I said it does require preparation and most people don't track this metric in particular.
It is possible through JavaScript to track the actual printing event with IE browsers. Considering users most likely won't switch to IE just to do the printing, it would give some sort of accurate indication of what % of the IE users, print the page.
For more information about the onbeforeprint and onafterprint events have a look at:
http://msdn.microsoft.com/en-us/library/ms536672(v=vs.85).aspx
Btw, I am not saying that collecting this data solely from IE users would give an accurate indication of the overall % of printed pages across all browsers, because IE is far more commonly used in office environments rather than home environments.

What should a main page of a web application be? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Designing a web application, how do you design the main page? By this I mean the page that is displayed to a user after entering the base url, like http://www.foo.com.
It would probably depend on a website, but...
stackoverflow welcomes us with list of questions, no silly what is stackoverflow landing page,
last.fm prestens a kind of dashboard, being very popular lately, kind of personalized landing page for registered users
google welcomes us with a search box, but iGoogle i completly diffrent story - looks diffrent for everyone (well, and that's the point actually).
The other thing is, if the user is logged in (provided the website supports logging in), should we present him a diffrent content there then some new, random incomer? And I don't mean some personalized content, but something completly diffrent, like his user profile instead of main page?
From one perspective it could be good - registered users usually know our site, and get a kind of special greeting as soon as they come back. On the other hand, this could cause problems - when I show a website to a friend, then he goes there from his computer and sees something totally diffrent.
And other thing is, when I show a http://www.foo.com to a friend, and it takes me directly to my user profile / dashboard - this isn't sometimes what I'd like to show everyone, as this might show some of my personal data, etc.
What do you do when you design your web applications? What's, in your opinion, best from user's point of view, do my concerns about the website looking diffrent for registered and unregistered users do or don't make any sense? (Again, I don't mean small diffrences, like hiding huge register now link - but showing completly diffrent view then).
It really depends on the focus of your application, but if you were to generalise I would say determine the one or two most critical paths in your application and focus on those.
Registration is probably what you
want to drive more than anything
else, so make it clear how users can
sign up and get involved.
Make it is easy for existing users to sign in.
Consider the amount of text you have
on your front page and reduce and
pair it down as much as possible. Keep the messages and information you
convey here as succinct as possible.
Provide some content immediately
showing what your application or site
provides. Don't make users follow a
link to access the core functionality
of your site immediately e.g. if
you're building an auction site,
ensure there are listings on the
front page.
Consider your audience. If your site is non-technical, the fewer UI elements you present the better. Portal like sites, with lots of compartmentalised functionality and information can be confusing and overwhelming for many non-technical users.
Make it clear how users can get Help if they require it
Without knowing the business area of your site then it's going to be tricky to answer this, but...
You should get the user into the main flow of your website as soon as possible, and the home page is the best place to do this.
If you're an online store, start showing your products.
If you're a search engine, give the user the ability to search.
If you're a blog/news site, show the user the latest news.
Yes - make the experience for a logged on/registered user better (show them THEIR news, show them their recommended products etc), but the purpose of your site should be obvious and accessible from that home page. Get your existing users into their flow as soon as possible, and attact new users in to your site by showing them the meat of your site.
There are plenty of places out there that discuss good web design, making your site "sticky" etc. Check out SmashingMagazine.com (it's one such site) but there are plenty of others.
Oh, and remember that there's one very important user of your home page that you need to accomodate - search engines. Make their life easy, make the content discoverable and indexable, and drive people to your site via Search.
What I've found works best for me is to "role-play" the end-user's experience.
When they initially hit your site, what do they most want to see, or in other words, what are they most likely to be looking for and wanting to do?
I work on many intranet websites for a very large company, and what I've learned is that a home page that has detailed information of the site and what it does is useless and, consequently, my end-users just skip over it in order to get to the pages that they really need. So, my strategy usually consists in a home page that allows them to get straight down to business and whatever they're there to do.
BUT, that's just for the sites that I create. I think it totally depends on your target market and what they're wanting to do.
For the most part, a visitor landing on your page will already know the gist of what your application is about, so there shouldn't be a need to explain in detail what is is you do. Instead, show them that you have the information they are looking for. Screenshots and screencasts are becoming popular these days as a means of getting this across to the short-attention-spanned user.
For registered users, I'd recommend taking them directly to the primary application page instead of the homepage (unless the homepage is the primary application page). For many apps this is a Dashboard (Flickr, Basecamp, Campaign Monitor). If your app's main focus is the homepage, you may want to show them a personalized version of that page (think Google vs. iGoogle).
With all this said, it really does depend on what you are building. Every application is different and there's no right way to do it - only conventions that work for most.
I would start by looking at the type of tasks that can be performed inside your web app, what's important? what's important when they are a new user? what's important when they are a repeat user? what's important when they haven't even registered yet.
Although all of these things happen on the the same page, it's likely that you'll need to define different states. e.g. If a user is on the homepage and not logged in, should we prompt them to login and register.
Perhaps also look at Personas so you can figure out exactly who will be using the app and what is relevant to them.
It should be whatever makes sense for the application, and this should be verified by testing the application with a group of expected users.
The main page should provide a first-time user with enough visual and/or written information to understand what the application is about. They should have some idea as to what actions they can take to interact with the app and what the outcomes of these actions could be.
I know people hate this answer on stackoverflow but there's only one way to find out what the most appropriate thing for your users is - you need to brainstorm ideas with potential users or at the very least you ask them.
I'm not suggesting that you do a focus group, or put a flawed poll up (neither of those things work). Rather, I'm suggesting that you go out and talk to people who will potentially be in your target users and do planning games with them (like card sorting) or go out and do some user testing with paper prototyping.
Anything else is guessing.

How to convince a customer that what he wants is a bad thing to do? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
For instance, customers that we're creating web sites for, request things like:
all links should open in a new window
put custom 'Back' button on every
page while there is a working
browser's equivalent
make some part of the text blinking etc.
Of course I tell them it's wrong, but is there some nice list of bad things to have from a respected source that I can point them to?
Become that respected source. Seriously: if your clients are showing reluctance to take your advice directly, compose documents that illustrate good and bad user interface design and publish it on your website. You gain three things from this:
You become more knowledgeable about the why of bad and good design. Having to think through something to compose it into a document is more helpful than many give it credit for.
If this is publicly published, you probably will get feedback about your ideas. Throw away the bad suggestions and integrate the good, and you become better at your craft.
You have the source for these discussions in a presentable format, yet you retain all your personal branding. If you include examples and demos of the good and bad, most people can see why you advocate for your ideas.
EDIT: epotter is dead on as far as the "buck stops here" aspect of interacting with a client. If your documents can show why irritating a user is a loss of revenue in the long run, it is unlikely you will have much push-back. On the other hand, if your personal preferences includes UI designs that don't help with retention... stop doing that. (I recall the days of "CSS Only, No Tables" designers before CSS had matured: they insisted on forcing their designs on clients, even though in some browsers they didn't render well. While a cause is admirable, you work for the client not a cause.)
Always try and show them how it will cost them money. For example, if they are going to do something that annoys the user, they will have less traffic which will lead to less revenue.
For better or worse, dollars always speak the loudest.
First, don't tell them it's wrong.
They may take it personally.
Instead, understand the need they are trying to fill, then suggest alternatives that don't include the bad behavior. Mock all the alternatives up and point out the good and bad of each one. Let them choose. As long as you have a good alternative, and sufficiently pointed out the faults of the bad implementation, then they generally come around to your point of view.
In other words, act like a designer. When a customer says, "I want green text on a red background," you don't immediately tell them that 10% of the world's males cannot read that, you first need to understand why. "Well, it's Christmas," then you can suggest alternate themes to give the site a festive feel without the design error. As long as the mockups you suggest are better than theirs then they will generally acquiesce.
Not because they made an error, but because you saw their real need and improved on their idea.
If they're adamant after that, though, do the work - don't spend your time trying to convince them the error of their design sense, it's a waste of resources.
Educate them over the long term, but if it takes you an hour to convince them not to make a change, that's one hour you could have spent improving your relationship with customers who treat you as designers rather than web-monkeys.
-Adam
I've had to play a semi-sales role at time with web projects and I have to stress how important it is to keep the customer happy.
Nevertheless, I completely agree with you that you are obligated to say something in the name of giving them what they want. I always found that the best approach is to start by agreeing with them (in principal at least). You could say,
"I completely agree with you that this
text is very important to your users.
Many testers that I've worked with
have strongly preferred using this
font/graphic/color to call out
critical text. Unfortunately, some
users associate flashing text with ads
and avoid it"
I find that this approach lets them know that you
Understand what they want
Appreciate their motivations and suggestions
Only want to help
One last word of advice, if after the gentle nudging, they don't get the point, consider doing two quick mock-ups. (their idea and yours). If that doesn't work, then just give them what they want. In the end, they pays the bills and if they really want an ugly site (assuming you can't afford to turn away business on aesthetic grounds) just give them the site.
Good luck and take deep breaths!
Jakob Nielsen's Alertbox has been an invaluable source of common-sense usability advice for me for many years. Here's something he wrote way back in 1996 that still applies today:
The BACK feature is an absolutely
essential safety net that gives users
the confidence to navigate freely in
the knowledge that they can always get
back to firm ground. We have known
from some of the earliest studies of
user navigation behaviorthat BACK is
the second-most used navigation
feature in Web browsers (after the
simple "click on a link to follow it"
action). Thus, breaking the BACK
button is no less than a usability
catastrophe.
And here are the first two of his Top Ten Web Design Mistakes of 1999:
Breaking or Slowing Down the Back Button
The Back button is the lifeline
of the Web user and the second-most
used navigation feature (after
following hypertext links). Users
happily know that they can try
anything on the Web and always be
saved by a click or two on Back to
return them to familiar territory.
Except, of course, for those sites
that break Back by committing one of
these design sins:
opening a new browser window (see mistake #2)
using an immediate redirect: every time the user clicks Back, the
browser returns to a page that bounces the user forward to the undesired location
prevents caching such that the Back navigation requires a fresh trip
to the server; all hypertext navigation should be sub-second and
this goes double for backtracking
Opening New Browser Windows
Opening up new browser windows is like a
vacuum cleaner sales person who starts
a visit by emptying an ash tray on the
customer's carpet. Don't pollute my
screen with any more windows, thanks
(particularly since current operating
systems have miserable window
management). If I want a new window, I
will open it myself!
Designers open new browser windows on
the theory that it keeps users on
their site. But even disregarding the
user-hostile message implied in taking
over the user's machine, the strategy
is self-defeating since it disables
the Back button which is the normal
way users return to previous sites.
Users often don't notice that a new
window has opened, especially if they
are using a small monitor where the
windows are maximized to fill up the
screen. So a user who tries to return
to the origin will be confused by a
grayed out Back button.
These aren't crazy newfangled ideas, they're decade-old guidelines based on hard research. You'd need a really, really, really good excuse to repeat a decade-old mistake.
Find examples of actual pages that do this and show them. Here's a good place to find some.
If you show them the examples, and instead of being awed by the suckyness and changing their minds, the clients say, "Yeah! That's exactly what I want!", then make them sign a nondisclosure contract saying they'll never tell anyone who designed their web site. :)
You have to explain "why". It's not enough to tell them something is "wrong" (and in these cases, it's not so much "wrong" as it is a "bad idea")
Most people respond well to logic and reason. If you can make a reasoned argument for why doing something a certain way is a bad idea, they'll usually bow down to your experience and knowledge.
useit.com is an excellent resource for usability arguments
but you're probably wasting your time. Either do it their way ("the customer is always right") or walk away - arguing is unlikely to improve the situation unless you can demonstrate a significant monetary gain from not doing it their way, which you probably cannot do given the issues you listed.
if your name will be on the site, i'd politely walk away
Show them some articles on sites like http://useit.com which has some empirical studies on how adherence to web standard practices increases usability and so therefore user satisfaction and so therefore profit.
Ask them what results they're after. "Have all links open in a new window" is a statement of solution. Solutions are your job, the client's job is to state objectives.
Start with this: "Oh, you'd like links to open in a new window. Tell me more about why you want that - I'd like to explore with you whether there are alternate ways of getting the same results."
Perhaps continue with this: "Also, I might point your attention to other consequences of opening all links in a new window - consequences you might not have considered, and which perhaps you wouldn't like."
Suggested reading: Dale Emery's articles on resistance.
At the simplest, try to explain them each of it in a user understandable manner.
e.g. Blinking text is an old style thing not supported by all browsers
Not sure why "back" can be a problem. But put your viewpoint.
It's always convincing if you demonstrate to the user that his design is unconventional or wrong by showing a list of very well known websites that he would "respect" and pointing out how they don't do X. Your customer will probably want his site to be like the big players' web sites.
If he still insists that his weird design makes sense you could say: "yes, I agree that sounds like a good idea in theory, but the fact is that users are simply unaccustomed to X and would walk away from your website if it diverges too widely from the standard way of doing things".
IOW, when all else fails, use fear.
You can lead a horse to water, but you can't make it drink.
With customers (of any type), the best you can do is inform them of their choices, and why they are not the best ones and then leave it. If it's really bad, require sign-off stating that they find that design acceptable. Do you want to be 'right' or do you want to get something into the customer's hands that works?
If it completely impedes a working solution, then (and only then) should you stand on principle, but beware you have very few (if any) of these 'stands', so use them wisely. Be prepared to walk away.
Paul.
Unless there is a compelling business case NOT to do it (and I'm not sure this is the case with any of your examples) then if the customer is adamant DO IT! They are paying for it after all. They can always find someone else who will do it if you won't!

Are there any alternatives to recaptcha.net, for stopping spam? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
A member of my company in greater ranking than myself refuses to use recaptcha.net on his website to thwart spam off of a public form. He thinks it would be difficult for anyone coming to our site to enter their information since the Turing Tests are "so darn hard to read".
Is there an alternative to using this method? That doesn't contain these sorts of difficult to read images?
(Okay stupid question...if it were up to me we'd use recaptcha because everyone else on earth does...but I just figured I'd check anyway.)
Also, is using a hidden field that is set by Javascript and later checked on the server really a good way to thawart spam?
I myself don't really buy that it is...since there are all sorts of Javascript engines that don't run in a browser yet can run Javascript (Rhino etc...), that could easily be used to thawart a JS/Serverside anti-spam method.
CAPTCHA will reduce your spam but it won't eliminate it. People are paid to decipher those glyphs. Some sites use the glyph that was presented to them for their own site so some hapless visitor will decipher it.
Just so you're aware that it's not a perfect solution.
Based on the principle of don't solve a problem until it's a problem: is spam a significant problem on your website? There is something to be said for not annoying your customers/visitors. Even here I sometimes need to make a few edits and I get the irritating "I'm a Human Being" test on typically the last edit I need to make. It's annoying.
People have proposed all sorts of other methods for dealing with this problem. One I read about used picutres of cats and dogs that you had to classify because apparently there's a database of 30+ million of these in the US for abandoned animals or somesuch. This or anything that gets in widespread use will be defeated.
The biggest problem with spam on sites is if you use software that's in widespread use (eg phpBB). Your best bet for those is to make enough modifications to defeat out-of-the-box scripting. You may get targeted anyway but spamming is a high-volume low-success game. There's no real reason to target your site until it accounts for a significant amount of traffic.
The other thing worth mentioning is techniques that can be used to defeat scripted spam:
Use Javascript to write critical content rather than including it as static HTML. That's a lot harder to deal with (but not impossible);
Rename and/or reorder key fields like username and password. For example, generate username and password form fields and store them as session variables so they only work for that user. That then requires the user to have visited the page with the login form (rather than scripting a form response that can be POSTed directly);
Obfuscate the form submission. Things like unobtrusive Javascript that you can do in jQuery and similar frameworks make this pretty easy;
Include a CAPTCHA image and field box and then don't display them (display: none in CSS). You'll confuse parsers.
The best way for not so popular sites is to insert a hidden field and check it. If it's filled then it's spam because those bots just fill in any field they find.
You might want to look into Akistmet and/or Mollom.
Add a non-standard required input field. For example, require a check-box that says "check me" to be checked. That will defeat any automated scripts that aren't tailored to your site. Just keep in mind it won't defeat anyone specifically targeting your site.
A simple way is to display an image reading "orange", and asking users to type that.
Yes, recaptcha will cut spam but it will also cut conversions! You should consider using XVerify which does real time data verification. What makes those registrations spam is bogus data, with XVerify it will make sure the information you put in is real data by verifing the email address, phone number, and physical address of users. If the information is fake the user cannot click continue! SIMPLE!
I used to think CAPTCHAs were good and used reCAPTCHA on public forms. I noticed that spam submissions were gone but I also noticed that real submissions were cut drastically as well.
Now I don't believe in CAPTCHAs. They work but I feel they can do more harm than good. After having to enter in hard to read CAPTCHAs on other sites I understand why I don't get as many real submissions. Any input that a user must act on that is not related to their main goal is a deterrent.
I usually use several methods to prevent spam and it depends on what type of content I'm expecting in forms. I created server methods that scan comments and mark them as spam based on content. It works ok, but I'm no spam expert so it doesn't work great. I wish someone would make a web service that did this.
I think the links from Evan are pretty interesting!
Another method that I have heard about, which basically extends the javascript idea, is getting the client's browser to perform a configurable JavaScript calculation.
It has been implemented in the NoBot sample as part of the Microsoft AJAX Control Toolkit
http://www.asp.net/AJAX/AjaxControlToolkit/Samples/NoBot/NoBot.aspx for some more details of how it works.
I found an alternative called Are You A Human. Not that programmers should go on gut feelings, but from the start it seemed insecure. Since it's a fun game you play, I decided to try it. It didn't work for me. It's possible the host isn't set up for it. That's the last thing for me to check.
If anyone else has tried ayah, I'd like to know how it worked.
I've used Confident Captcha before and it was really easy to get set up and running. Also I haven't had any spam get through on the forum I manage.
It isn't a text based Captcha but instead uses images similar to picaptcha. I've tried 'Are you a human' before and it's definitely an interesting concept.
Found one called NuCaptcha which displays moving letters...
8 years later...
I have been looking for alternatives to Google's reCaptcha, which doesn't ruin the UX, tracks user, etc. and found this gem: Coinhive Captcha.
It works by mining Monero coins (hash count is adjustable) in the background and provides a server-side API to verify it. It should be noted, that - depending on the selected hash count to solve - it may be slow, specially on mobile devices.