Thanks for the excellent write up, Andrew. Glad to see that Mailcheck's working well for you! I'll post up your post on our Github readme in a bit.
As a side note, I'll be releasing version 1.1 shortly, which has a bunch of improvements, including the option to use keyboard-distance based string matching. Look out for it!
Why is this better than having users enter their email twice and just confirming they match?
I realize entering email twice might be slightly sub-optimal from a user perspective but if you as a user want a service, it seems like entering one's email twice is not a lot to ask or a major source of friction. Or is it?
Not trolling. Genuine question. We do the type your email address twice on our site so wanted to understand if there any clear benefits of this approach.
I see what you're saying about the customer wanting the service but a lot of time it's not so simple. We spend a ton of time tweaking our copy and graphics to convince the customer, if only just barely, that they should sign up. When they finally decide to sign up, the fewer the forms the better. There have been studies that show a marked reduction in performance for each new field you request from the customer. This has lead to people asking for a password only once, instead of the traditional twice, or to go further and not even ask for a password (it's automatically created and emailed to them).
Additionally, as developers, we should be making things easier for customers. Correcting obvious typos is a better system than asking all customers to type it twice. Consider the extra work you're creating for all the customers who didnt have a typo.
One of my accounts uses a relatively long domain, so I often type it once, Ctrl-A Ctrl-C to copy it, then paste into the dupe field. Assuming I'm not the only person that does this, entering it twice isn't going to help in any significant way.
And secondly, there's a fair UI improvement in 'your email might be wrong, and here are some easy 1-click suggestions to fix it' vs 'these 2 things don't match. Work out where the error is, and then fix it', usually without even indicating the non-matching substring(s).
Many people really struggle to type on a keyboard - it's something that geeks often forget (I've been reminded of this again this week when helping my mum setup her new laptop). For them, having to enter their email address twice isn't suboptimal - it's a nightmare.
Those of us who don't have a problem with keyboards don't bother typing twice. We Ctrl-A, Ctrl-C, Tab, Ctrl-V, which renders the whole thing pointless.
The e-mail address is more important than other fields both because it can be used to verify identity and because it allows a website to send marketing e-mails (which is often the purpose of getting people to sign up.)
Then again, you can do a lot of mistakes when typing your shipping address and it will still get through. It is also easier to spot mistakes since a shipping address contain regular words which isn't as common with email addresses.
One char wrong and your email is completely worthless, and with it your only real link with the service is cut off - often with no way of fixing it.
I totally hear you. The jQuery plugin actually wraps Kicksend.mailcheck, so it's easily decoupled (do fork it!). Since its main use would be on the client side, we released as a plugin for the ease of adoption.
Well worth noting: auto-correcting the email addresses would be a very bad idea; ditto for stopping them from submitting the form if this is triggered.
But just showing a little note "are you sure you didn't mean username@gmail.com", then letting them submit anyway, isn't generally annoying even for misfires.
Because there actually are going to be occasional users who mistype "ymail.com" when they mean gmail. Hey, thanks for the warning; the y is right near the g.
Thanks joedev, perhaps I will one day. As mgkimsal mentioned, consultants have to take into account other such considerations when working with more established teams. That said, consultancies like Pivotal Labs make it part of the engagement to impart best practices and effective process to their clients as much as possible.
Engineering is about making such trade-off decisions, constantly. One of the many traits of a engineers is how quickly and accurately (on hindsight) we can make them.
And back to the blogpost, I feel that the array vs hash and LINQ examples are fairly contrived. In reality, a good engineer shouldn't even consider those approaches in the first place, unless there's a really compelling reason to do so.
