- Fields for typing-in a credit card
- Fields for typing-in an e-mail address
- Fields for typing-in a U.S. street address
There are widely-known techniques for optimizing data entry for these fields, yet these techniques aren't widely adopted, and further yet they're known to increase conversation rates.
Someone should build a (subscription) service where you can embed a bunch of fields (and labels) onto a form with a single line of Javascript.
Then, the fields would render on the page. The performance of the fields (their effect on conversion rates) could be measured continuously. New variants of the labels and fields could be A/B tested continuously as well. That is, the performance of the fields would improve over time.
If there's interest I'll elaborate in a blog post (with mockups).
made a few edits
I think you misspelled "open-source widget library".
It's a technique I use, along with only allowing digits and doing some format masking (i.e. spaces or dashes to split the number into 4 digit blocks) to make the number more readible
We implemented the Luhn[1] algo credit card check on the checkout page. Invalid CCs would trigger a little warning but still allow the form to be submitted. Invalid CC transactions dropped ~90% immediately. Even better we were able to get rid of the 'select your card type' field since that was detected by Luhn. A little JS was a win all around.
FYI: Card Type is not determined by Luhn algorithms, but rather (broad brush strokes, see http://en.wikipedia.org/wiki/Bank_card_number#Issuer_Identif... for more detail):
3 - American Express 4 - Visa 5 - Mastercard / Diners 6 - Discover
Out of curiosity, why allow the form to submit anyways?
Not quite the same, but sounds a bit like inForm[1]. These guys presented at a recent HN London meetup[2] and this was the meetup.com description which summarizes it better than I could:
"Ever wondered how users engage with your site, where they get stuck or how long they spend making choices? Forward Technology's upcoming form analytics service inForm can help you answer all these questions and more. Without any configuration Inform allows you to quickly build up a strong picture of what happens when real visitors interact with your forms."
Beta sign-up for HNers here[3]
[1]http://inform.forwardtechnology.co.uk [2]http://vimeo.com/32617520 [3]http://inform.forwardtechnology.co.uk/users/sign_up
But testing multiple fields, with multiple variables and experiments requires lots of traffic.
And what works for one source of traffic, PPC for example, won't duplicate to other sources of traffic like TV / Radio / PR / SEO / etc.
We recently ran a ton of traffic just around an inbound-email newsletter pop-up that lists out what we found to work best here:
http://www.conversionvoodoo.com/blog/2012/01/opt-in-email-ne...
Those are some "tried and true tips" that we'd stand behind for a popular affiliate marketing blog getting most of their traffic via SEO and referral, but unfortunately the entire addressable universe that we can guarantee those results for are the client we undertook the project with ;)
The base case alone would be enough to get many to buy your component but for a subscription (where the real money is) you need to provide continuous value.
So your pitch could be that using your product would instantly get you the best industry standard input forms but over time they'll get better because you're going to apply a/b testing and machine learning on them continuously.
We experimented with doing something like this on Quizlet, but didn't actually launch anything. We first looked at a lot of the data and doing based on string distance is the wrong approach.
For example, if you type hotmail.de into that checker, it suggests hotmail.fr. Another is ymail.com --> gmail.com. The more valid domains you add, the more (correct) permutations get marked as invalid. We have 20k users with ymail accounts.
I think a blacklist approach is much more solid than a whitelist approach, I just haven't gotten around to building it.
Just curious, but are you suggesting that plain text is the wrong way to store an email address? Your comment makes me draw that conclusion, which of course seems rather silly.
Off-the-shelf usefulness would be improved a lot if the plugin contained a list of say 100 or so of the most commonly-found email domains.
My 2c.
Edit: Another good idea from hinathan.
A mx checking service sounds awesome. Keep us posted if you guys do it.
`$ dig hotnail.com MX` yields results but is still invalid.
One thing we do differently on http://www.queondaspanish.com/ though is allow users who haven't confirmed there email use the logged in features but with limitations. They can keep track of their lesson progress for example, but not send messages to other users. They can also change misspelled email addresses, which I think would help in your case.
casema.nl, chello.nl, hetnet.nl, home.nl, kpnmail.nl, kpnplanet.nl, live.nl, online.nl, planet.nl, quicknet.nl, schuttelaar.nl, skynet.be, t-online.de, tiscali.nl, upcmail.nl, wanadoo.nl, wxs.nl, xs4all.nl, zeelandnet.nl, ziggo.nl, zonnet.nl.
This checks email addresses using regexps and DNS.
It's certainly plausible that Google or FB login is a more pleasant experience for customers, just be aware that a non-zero number of people will bounce from your site if that's all you offer.
I tried highlighting this in the FAQ and on the purchase page, but the rate at which it happens didn't seem to change.
