45

When logging in, users might mistype parts of their email address. For example, [email protected] instead of .com, Yaho instead of yahoo, etc.

The main rationale is that by autocorrecting user input we could avoid unnecessary error messages that are either due to misspellings or other common typing errors.

So my question or rather questions are:

  1. Is there a list of common typo errors associated with typing an email address?
  2. Are there any access security implications?

Related:

What are the most common mistakes people make when entering their e-mails in a form?

16
  • 33
    Imagine a user has the domain goggle.co, which she uses to host her mail server. She wouldn't appreciate you "correcting" her email to google.com
    – SBoss
    Dec 5, 2014 at 15:21
  • 3
    I know there is already an accepted answer but I am really curious as to how big of a problem this really is in your case. Do 50% of your users forget their full TLD?
    – MonkeyZeus
    Dec 5, 2014 at 21:52
  • 14
    Don't ever assume you know what the user will type in a textbox.
    – Kroltan
    Dec 6, 2014 at 22:14
  • 11
    A few years ago, some service could not handle my “incorrect” e-mail address having a suffix of more than 3 characters. My e-mail address ends with “.info”. Such ill-advised validation of user entry has to be avoided. Dec 7, 2014 at 14:46
  • 7
    @Okavango Well, you might suggest possible changes, with an usual autocomplete dropdown, possibly. But it's dangerous to assume you know the user's correct spelling of the email, which is a potentially access-binding information.
    – Kroltan
    Dec 8, 2014 at 13:18

10 Answers 10

76

I would recommend against an auto-correct as domain name extensions are about to change drastically, to the point where an email ending with "sitename.anything" will be valid.

Consider an inline check, which means it doesn't cause the frustration of the usual ENTRY > SUBMIT > ERROR MESSAGE > RE-ENTRY > SUBMIT

[email protected]
[!] Did you mean .com?

Asking for a quick confirmation before submission saves time for both the user and the system.

10
  • 30
    .co is the TLD for Columbia
    – Justin
    Dec 5, 2014 at 15:24
  • 5
    Related frustrations caused by mishandling of new TLDs: Is my new gTLD causing it to get filtered as spam? What I took away from this is: never assume you know what TLDs exist (or will exist in the next 10 years).
    – apsillers
    Dec 5, 2014 at 17:29
  • 4
    You could also include some action to fire the auto-correct (as making the Did you mean...? clickable for applying it), so the feedback loop gets faster as you wanted. Dec 5, 2014 at 17:53
  • 3
    And .co is a public suffix, meaning that you should be prepared for more or less anything immediately under it. In contrast for example .il is not (currently) a public suffix, so if someone claims their email address is "[email protected]" then it'd be a surprise. Still not impossible, though. They might be a domain registrar, and anyway the public suffix list isn't a perfect description of what domains are available to register. Of course you can check your own records to see whether .co is rare enough compared with .com among your users to justify an extra confirmation. Dec 6, 2014 at 15:44
  • 11
    @Justin — No ; .co is for Colombia. Dec 7, 2014 at 14:41
12

Definitely don't silently change the address without telling the user, as this can lead to extreme confusion if it guesses wrong. Instead, you might consider a "Did you mean...?" message underneath the field. This is easily understood by any user who has done a Google search.

Mailgun has a service for doing exactly this. They have an online demo. In addition to checking the domain name (remember, you can't just look at MX records, as mail servers are required to attempt a fallback to the A record if MX doesn't exist), it performs a variety of other sanity checks (for instance, it knows about minimum length for a Gmail username).

4
  • 1
    Welcome to the site, @Wolfgang! When you write "doing exactly this" what do you mean? From the context of the OP's question I would expect "doing exactly this" to mean that the service autocorrects, but then you go on to say that it does not autocorrect, but instead provides suggestions of alternatives. Can you clarify how your answer addresses the OP's question? Dec 6, 2014 at 4:55
  • 2
    @3nafish: By "doing exactly this" I meant "avoiding unnecessary error messages" - rather than an error message, it provides a helpful suggestion. Looking at the OP, this answer does seem a bit disjointed. Should I reorganize & rephrase it?
    – Wolfgang
    Dec 6, 2014 at 19:03
  • Yes. Editing that context into your post would probably clarify things. Dec 7, 2014 at 0:25
  • 1
    @3nafish: what do you think of it now?
    – Wolfgang
    Dec 7, 2014 at 23:01
11

I would lean towards not using Auto-correct in this instance as it can lead to more frustration than presenting an error message.

The reason I say this is with the increase of domain names the accuracy of auto-correct becomes less and less.

Your example is changing the .con to .com, what if the user's intention was to write .cn or .co?

Form field error messaging is usually subtle and effective without the user getting too frustrated auto-correct on the other hand is extremely frustrating when it doesn't work.

1
  • 2
    Though, what you really are (or should be) doing is presenting a notice or warning, not a full error (where error implies it's incorrect, and prevents form submission). I would hope a "did you mean...?" message looked different from a "your passwords do not match!" error.
    – Bob
    Dec 7, 2014 at 23:48
7

How about an ajax request real-time to check if the submitted domain is valid or not? If it's valid, presume it's right. If you can't find an MX or A record at that domain, state "could not find this domain" or suggest a "did you mean" mined from past records you kept about what users changed the input from and to all the previous times you "could not find this domain".

I'd recommend against autocorrect, being a person who especially and passionately hates it when the computer thinks it knows better than I do.

Also, I'd like to add: please don't be overly restrictive in your email validation. Go read I knew how to validate an email address until I read the RFC to find all the ways that so many web sites are doing it wrong.

It really ticks me off when a web site won't let me put a plus sign in the portion before the @ symbol of my email address. It's a horrible user experience for me that their system won't accept my perfectly valid email address. Only the post office can decide if an address is valid or not, and for email addresses, the post office equivalent is the mail server of the domain in question deciding whether it found the associated user or not. Random web sites should never try to decide if another server considers an account valid other than by the one and only true way: sending an email to the supposed email address and determining if the user received it by whether he possesses the information that was sent.

5
  • 1
    This is a more reasonable approach, provided that the system do not go beyond suggesting. The user must have the last word. Dec 7, 2014 at 14:51
  • 1
    @Wolfgang in his answer says something about checking the MX record not being enough. Dec 7, 2014 at 14:52
  • @NicolasBarbulesco I updated my answer. My intent was merely to see if the domain listed could be a valid answer. If no domain even exists by that name, then that's the only time I'd suggest something else.
    – ErikE
    Dec 8, 2014 at 23:48
  • The worst is if you can put a + sign into the email on registration, but you are not able to login because you may not enter a plus sign into the login form.
    – Alexander
    Dec 9, 2014 at 8:47
  • @Alexander I once had a web site let me create an account with a 20+ digit password, but on signin I would get a validation error using more than 16 (or somesuch), even hacking the form post to defeat client-side validation. That was not just a bad experience, it made me never use the site.
    – ErikE
    Dec 9, 2014 at 20:06
2

Autocorrect is somewhat invasive, and sometimes doesn't let user understand what was the typo or notice it at all. I would opt for typeahead (autosuggest) dropdown saying "Did you mean correct address?".

3
  • 3
    This dangerous in regards to security, as then you are giving a possible attacker a list of correct e-mails that are hosted on the server. It would be preferable to just say the user made a mistake anywhere. Dec 6, 2014 at 15:17
  • I guess thats the main fear from an access security point of view. so correcting user input should in principle not indicate whether the email inputed is valid or not!
    – Okavango
    Dec 7, 2014 at 12:41
  • @DoktoroReichard — It would be preferable to just say the user seems to have made a mistake anywhere. Dec 7, 2014 at 15:00
2

I think its useful to separate common typing errors from spelling mistakes. auto-correct might not be relevant for correcting domain names as @Simwil suggested because of changes to domain name extensions. This being said, if we are looking solely at auto-correcting typing errors this would enhance the overall user experience and minimise user frustration by looking at elements such as:

1- Removing Full stop at end of address

2- Replacing commas with full stops when needed

3- Trimming spaces in middle or at end of the address

4
  • 1
    This post combined with @Simwill's post seem to be best of both sides. Autocorrect should only be used for these use cases, otherwise a friendly suggestion is recommended.
    – Vince C
    Dec 8, 2014 at 15:15
  • 1
    Your first two suggestions are absolutely valid, but the third might get legacy sometime. Spaces being invalid now does not mean spaces are invalid forever. They're still type-able characters after all.
    – Mast
    Dec 9, 2014 at 14:18
  • @mast Type-able yes but not intentional. are you suggesting that they could be a valid input in the future?
    – Okavango
    Dec 10, 2014 at 13:07
  • @Okavango I don't know. The point is nobody knows, therefore it's a bad idea to restrict it. There is no technical reason why they shouldn't be allowed. It would be a disaster user-experience wise, but that hasn't stopped the big guys from implementing bad ideas before.
    – Mast
    Dec 10, 2014 at 18:49
1

I wouldn't personally recommend auto correcting the email address' domain name, but you could check it against the "VALID" domain name extension, and for that you need to check it against list of valid domain name extensions which would be an absolute pain, specially nowadays that we have new and totally weird domain name extensions, here is a link to all of them; http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains

However personally I wouldn't recommend neither of the domain and its extension as it could be a pain, also you'll be confusing the user... and if something isn't working properly as it should then you'll lose your new user and they'll never ever come back again... trust me!

As so many people suggested, I would highly recommend agree with the "Did you mean .com?" as 1) you're constantly giving feedback, 2) they can still change it if it isn't correct, and 3) you're not over complicating things for both your app/website or whatever is and the user, 4) less http requests, less page loads by ajax or whatever that u be using to check in the background, 5) most importantly less work/code...

I hope it helps :) Cheers

1

Depends on How smart is your checking?

Relatively speaking a list of typo's is unsophisticated. There are services that can determine the presence of

  1. a valid Domain Name record
  2. an email server
  3. an individual email box

Certainly in the case 1 above, if there is no matching Domain Name Record - then an email can not reach the recipient. So in this case to auto-suggest a correction makes sense.

The reliability of checks 2. & 3. is not very high so take some caution using these as triggers.

0

People sometimes intentionally obscure their contact information online, e.g. by l33t-ing a few characters. One more reason not to do it.

1
-1

The other answers explain why autocorrect is bad. But you are correct about users being really bad at typing their own email address, so here's an alternate solution:

Make them enter their email address twice, just like when setting a new password.

Even if they are lazy and copy-paste it, hopefully they will at least look at it again and have a chance to catch errors.

4
  • 1
    not sure this is a good idea! We are trying to simplify the process and mitigate human error. Retyping adds a totally unneeded step to the process! even Retyping your new password is gradually being phased out in favour of unmasking to verify or check what you have typed.
    – Okavango
    Dec 9, 2014 at 19:43
  • @Okavango be that as it may, retyping works. UIs have gone way downhill with a lot of modern practices, and "reveal one char" was already on my list of bad techniques.
    – o11c
    Dec 10, 2014 at 4:37
  • @Okavango or to put it another way: most attempts at "simplification" tend to fail horribly. Consistency is far more important.
    – o11c
    Dec 10, 2014 at 4:39
  • have a look at this post (ux.stackexchange.com/questions/36424/…) I think it explains well the advantage of unmasking passwords
    – Okavango
    Dec 10, 2014 at 10:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.