Log in or sign up?

blog.leahculver.com

67 pointsr11t31 comments

Leah's asking the right questions, but I don't think the direction she took is the right one. Users rely on the UI to be familiar, and I've always found Amazon's UI strange in that I have to pause, analyze, and think when logging in/signing up. While Amazon might be able to get away with it, removing the familiarity from the UI is probably a bad decision for most. If an extra field is a barrier to sign-up, the user actually having to actively analyze and parse your sign-up form is a huge mental hoop to jump through.

We (Weebly) thought of this problem early on, and we tried to simplify things by just requiring an email/password when signing up. What we found was that our users were extremely confused, because the sign-up form didn't look like a sign-up form. When doing usability testing, we found that users would stare at the page for minutes. "us: Just sign up..." "user: I can't see where to sign up", even when it was right in front of them. They saw two fields and assumed it was a log-in form, even when it said in really big letters "Create a new account".

Users don't read your page, they scan it. People expect the log-in form to be in the upper right and the sign-up form to be towards the center of the page. You should absolutely make your site scan-friendly.

Users do, though, get confused and try to use the sign-up form to login. Our solution? If the user enters credentials into the sign-up form that already exist (like the correct username/password combo), we'll just log them in instead of creating a new user. You can try it out on weebly.com.

Seems like you might not want to do it if they enter a correct existing username/password, otherwise there is the slim (but non-zero) chance that they'll fluke into an account that isn't theirs. I figure email would be a better "username" since they aren't likely to enter the same one.

I don't know if you've encountered that problem (rare, I know).

Even if you're not going to go the full monty and change the user-visible interaction, you can file off some of the sharp edges. For example, I have the traditional sign in and register forms, and (predictably, given that my customers are not too tech savvy and the forms look similar if you read none of the words on them which, after all, is the default behavior on the Internet) many people use the wrong one.

Since user intent is clear if they try to register a user name and password that are already in your database, rather than giving them a "that account already exists" error I just log them in straight away.

There's an interesting point made, but I'm not sure that I really like the direction Leah went in. To me, the fields stand out far more than the radio buttons, I stop reading the header after "Log in..." (what more do I need to know, it's a login form) and I really wouldn't notice that it's a sign-up form unless I look carefully - I had to look twice before I realized there was even a difference between the two screenshots.

I'd probably ditch the radio buttons and make the header more eyecatching, with "Join Now?" clearly a link. Clicking it changes the form in the way Leah shows, probably with a quick Javascript fade so the user notices.

I like the way justigining.com is using here: https://www.justgiving.com/fundraising-page/Creation/?pcid=5.... They made a clear distinction while still using only one page for registration and sign in (they have a "normal" log-in page too).

This is great. Thanks for the link. I'll probably do a similar flow in a project I'm working on.

Especially in this case, when you don't ask for an email, it seems like a mistake to only get the password once. If someone mistypes it, there's no way to get them access to their account again.

And yes, I'm aware HN has this problem, unless you go in and put your email in your profile.

Interestingly, this was one thing PG pushed us to take out of Posterous registration. And he was right. You want to lower barriers. Since we already were getting the user's email address, it really wasn't painful at all to let the 'forgot password' flow handle the case where the user mis-typed their initial pw.

That's a great point. The convenience to most users justifies the inconvenience to the few who miss-type their password.

You have to both mistype your password AND mistype your email for it to be a problem. The percent of users who do that is minimal, and if it happens, it's not the end of the world: create a new account.

Yeah, username + password + email would work. It's not as safe as username + password1 + password2, since you can mistype both, but it allows an escape plan. The way HN does it, with just username + password is dangerous, I think, because most people won't, immediately upon registration, go to their profile and put in an email; they'll just start using the site. And if someone mistypes their password once, and can't re-login to the site, they'll be very turned off.

As long as the increase in sign-up rate is larger than the percentage of users who mistype their password, then it's a net win for the website.

I wish Amazon would preselect the "existing user" option, or at least have a JavaScript that selects it as soon as I type the password.

I agree. I think all Amazon log in systems favor new users and not returning ones. For example, here is the first result when googling "amazon ec2": http://aws.amazon.com/ec2/

The way you would go about logging in from that page is less clear than most websites.

I think that there are two problems with approach taken on hurl's homepage: 1) New user may be confused and not discover sign up functionality behind log in link. 2) Two buttons in the dialog require thinking each time when existing user logs in (i.e. common scenario).

When I was designing Memengo's homepage (http://www.memengo.com), I was trying to provide streamlined execution path for 3 different scenarios: see demo, register, log in.

I hate web sites that have tiny log in link in the top-right corner. After all, I usually visit home page to log in immediately, so I expect email and password fields to be provided right there.

To streamline sign up there is a need to ask as few things as possible, preferably on home page as well.

Potential users should be aware that there is a no-strings-attached functional demo one click away, so this area requires some screen estate as well.

The final design: 3 equally sized boxes on the bottom of the page: 1 click demo, Sign up (with all required fields), Log in (with all required fields).

We independently conceived of Hurl's approach. It looked like this: http://imgur.com/Th9yi

Maybe it was just a function of our design, but the feedback was that people didn't read and thought it was a login-only form. People are just conditioned to seeing long sign-up forms. A username/password pair just screams "login"!

There is enough innovation in the rest of our app to worry about, we didn't also need to be re-inventing authentication. Our login and sign-up forms are now on two separate pages and we added "Remember me" and "Confirm password" to the respective pages. Both pages have a link to the other.

We're trying to funnel users through the workflow such that we can present the correct page the vast majority of the time. For example, many features can be tried before making an account, but you get to them by clicking "try it now". Once you have an account, you get to them from your dashboard. This way, we can reasonably assume a user is new if they aren't authenticated already when they go to use such a feature.

"Sometimes I put my log in information into the register fields." "Me too! I hate that not only do I feel stupid, I have to retype everything again."

I hate the page LinkedIn shows when you're not logged in, it asks you to signup, and the login page is actually a different one. I find the call to action to register stands out, but they seem to hide the link to the login page. I never feel stupid when I encounter this, I feel like the site doesn't want repeat users, they want new user signups, and don't care if you end up recreating your account (this may explain why I've seen so many duplicate and inactive accounts on LinkedIn).

I agree with the direction one of the comments takes - if you're going to this trouble, why differentiate, if the username isn't taken, take the user straight to a 'confirm your password to create account'. One dialog box, two functions. Having to notice and choose the radiobutton is just another barrier to both types of users.

There's at least one problem with this approach: trying to sign up with a username that's already taken. If you want the username "foobar" and it's already taken, you're just going to get a "wrong password" error, when you really wanted to sign up. That certainly creates some sort of user confusion.

This approach only really works with signups that ask for an E-mail instead of a separate username.

As should all of them, really...

False. If I'm just using a web app myself, email may be sufficient, but if I'm creating a public-facing profile, I want a username to be visible, not my email address.

Of course, there is no reason why shouldn't you be able to log in using any of the unique information in your profile, be it email, your username/alias, your phone number etc.

I implemented exactly that for my web app (one dialog box - after the user enters an E-mail, automatically validate it and if it is unrecognized, just add a confirm password field and change the button to "Register"), and the response has been entirely positive.

His webapp: http://gomockingbird.com/mockingbird/

This sort of approach will leak information about what usernames exist in the system, which has security implications.

Depending on the nature of the application you may or may not need to worry about this (e.g., obviously irrelevant if the site has a user list that shows the login names).

Most sign up forms give away that information anyway--try putting in a name or email that's already taken and you'll get a form validation error.

If an existing user misspells their username, being taken to a register screen is not where they want to go.

Some Google research comes to the same conclusion Leah does, with slightly different behavior.

http://sites.google.com/site/oauthgoog/UXFedLogin

Mathjobs.org uses something along those lines, though in my opinion better than this implementation.

https://www.mathjobs.org/jobs?info-ja

Don't rely on Javascript for things this important.

Reply on news.ycombinator.com