While flowing out some registration / log in steps someone on my team pointed out that we're asking the same information from users in both of those steps - an e-mail address and a password, what's the point in the steps being different?

This made me realize that in previous apps I've built, I've used different Facebook button to register and log in users, but on the back end the same function is used for both - check if the user exists, and if not, register them, else verify them.

Why can't that be the way that things work for normal log in forms? Doesn't it make more sense (nevermind that there's a preconceived notion of registering and logging in - just because it exists doesn't mean it's right) to just have one form to handle both cases? Have we reached a point where the user should just be able to log in to your site? Is it time to start pushing this type of interaction?

2 Answers
2

You might consider the security aspect of a login form. Let’s say a user is trying to login to the system – but enters the wrong password. What should you do then? Register a new user? Probably not. Would you tell the user that the password is wrong and implying that the username is valid? That’s not a good idea either because it opens up for possible security breach. Username (for login) and screen name should be different.

But if the password is correct and the username is wrong – would you then register a new account? You can’t, sorry, you shouldn’t tell the user that the password is correct but the username is wrong, even if it’s technically possible. But would you register or would you give the option to register a new account or would you add forgot password option? It’s getting quite complicated, as you can see.

The reason for not register where you login is they are two completely different activities. Either you login or you register. The second reason is that the convention on register vs. login have a strong convention. Users have to trust your application, and they do that if they recognize the pattern. If you break the convention users might wonder what else you changed and start to ask themselves or others if your site can be trusted. That’s a bad idea.

Yeah, the "it's what a user trusts, and convincing them your site is worth trusting without such a standard pattern" was what I had in mind, but too me that wasn't a strong enough argument for what might have been a bad UX pattern. However, thanks for bringing up the security issue. That's a really solid reason for not doing it, even if it kind of remains an implementation issue, I'm not sure it's one that I can immediately see a way of skirting around.
–
SimonOct 18 '12 at 16:35