I think there's a general purpose need for "optimal" form components. Let me elaborate:<p>- Fields for typing-in a credit card<p>- Fields for typing-in an e-mail address<p>- Fields for typing-in a U.S. street address<p>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.<p>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.<p>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.<p>If there's interest I'll elaborate in a blog post (with mockups).<p><i>made a few edits</i>
It's a cool idea, but I think they're doing it wrong.<p>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.<p>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.<p>I think a blacklist approach is much more solid than a whitelist approach, I just haven't gotten around to building it.
Cool until I checked the source and realised that the developer has to hard-code a list of domains they want to check against (there are none included).<p>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.<p>My 2c.
I really like the idea. My only nitpick is that these days most projects seem to be ending up as jQuery plugins even when they don't really use much of its functionality. I think a standalone version would save a bit of effort for some of us bound to other frameworks (or not using any framework).
Great work and thanks for the mention. We've been thinking about doing something similar but going a little further and actually checking mx records, with a response if they don't exist. This would help with the long tail domains.<p>Edit: Another good idea from hinathan.
I can understand email validation for a service like PayPal or Yammer where money or access is truly tied to an email address. But it seems like there are a lot of service that validate email addresses unnecessarily (and could thus improve rates by 100%). If Kicksend only sends documents to email accounts then it would be one of the latter. If it actually makes docs available in an account, then, yes, it would need to verify.
So how about keeping the user on-site for a while and notifying them immediately if you detect their confirmation email has bounced? If you push the temporary session dowbstream enough to correlate seasion with bounce tou can talk back to the user. You could probably account for a healthy chunk of those bounces which this js doesn't catch.
Just a quick test of doing HTTP-based checking as opposed to a string-distance checking:<p><a href="http://richthegeek.co.uk/ui/input/email.html" rel="nofollow">http://richthegeek.co.uk/ui/input/email.html</a>
We've been doing the simpler version of this for years now, basically stolen the idea from a 2007 MarketingSherpa article [1]: we just raise a modal window for every subscriber address and ask something like "Please check again: is this your email address? - Yes / No (I want to correct it) (with the email address in big letters). Has worked wonders ever since ;)<p>[1] <a href="http://www.marketingsherpa.com/content/?q=node/2223" rel="nofollow">http://www.marketingsherpa.com/content/?q=node/2223</a>
This is really cool. It would definitely be useful on my sites.<p>One thing we do differently on <a href="http://www.queondaspanish.com/" rel="nofollow">http://www.queondaspanish.com/</a> 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.
Nice little gimmick, thanks! We put it in our sign-up script as well. Since most of our clients are Dutch, we added the most popular Dutch e-mail providers (+ a big German + Belgian):<p>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 is good for sanity checking the right side of the '@' but detectable things go wrong on the left side sometimes, too. One phenomenon I've been seeing for years is the erroneous "www." prefix, often tacked on to @aol.com and @yahoo.com addresses. I don't think I've seen one of these that <i>hasn't</i> bounced.
Another option is checking server side using whatever is your language equivalent of:
<a href="http://search.cpan.org/~rjbs/Email-Valid-0.188/lib/Email/Valid.pm" rel="nofollow">http://search.cpan.org/~rjbs/Email-Valid-0.188/lib/Email/Val...</a><p>This checks email addresses using regexps and DNS.
If you can predict the correction with good accuracy, why wouldn't you just fix the address on the backend? The only reason I can think of is to avoid spamming someone else in case of a wrong guess. But for popular domain name spelling errors, that should be almost never.
So awesome that this exists, and the timing is serendipitous -- I was about to ask someone on my team to make just such a thing after I noticed that the vast majority of our bounces are really obvious typos of popular domains, like gmial.com.
email != identity
There are better alternatives to login these days such as OAuth and OpenId, or FB for that matter.
Nerveless, this script could be useful - well done!
I bought a license for an app recently and didn't get my license key because I entered gmail.con or something. I was really pissed at them for about a day until I pestered them and they sorted it out. After it was over I was still kind of annoyed with them, really for no good reason, even though I was the one who goofed up.