Your e-mail is your username

The 30-years-old unix pattern for user management involves a UserName, Password pair associated to a unicity constraint on the usernames. On most web applications, this pattern has been enriched as a triplet UserName, Password, Email with, usually, a two-fold unicity constraint both on usernames and on emails. But is there any good reason to distinguish e-mail from username?

By looking at the major web players (Google, PayPal, Amazon …), the answer is negative without any doubt. This pattern has already been widely adopted. Yet, it’s still not stated a being an obvious web design best practice. For example, there is still no simple ways in ASP.Net 2.0 to enforce such a policy through the CreateUserWizard. Let’s review the arguments in favor of this pattern.

A mighty, but somehow recursive, argument is that since big players (Google, PayPal, Amazon) are doing that then doing anything else is only going to hurt a large number of users.

The only real drawback of this approach is the lack-of-privacy concern i.e. you may prefer your e-mail address to stay invisible to the other users of the website where you are registering. Yet IMO, the Display Name is a much more appealing and user-friendly concept compared to the username approach.

Ps: does not follow this pattern. I have no good excuse for this situation. I was just young and inexperienced at the time.

Reader Comments (2)

The whole point of a UserName is to have a constant public handle for every user. As you mentioned, an email address is (or better: should not be) public. But it isn’t constant either, as email addresses can change. Similar, a DiplayName doesn’t qualify as a handle. So you’d probably add an additional constant user handle, a UserId (often an integer or a GUID). Instead of the (A) username-password-email triple you now have a (B) userid-email-password triple. To be fair, the first triple often is actually implemented as a (C) userid-username-password-email quadruple (except in UNIX, where the username is used everywhere). The UserId in (B) is not a problem in B2C & B2B apps since the user doesn’t care or ever see his UserId. Hence I agree, it makes lot of sense for B2C and maybe also B2B applications, but I see problems in community-based applications. In such apps, you’d want to have a simple way to refer to buddies, their profile websites etc. You need a unique constant handle, like a user name. For example:

Btw, I forgot: MS Passport also uses email addresses as user names. However, there’s a reason they’ve introduced the * handles, which look like email addresses but aren’t: