5 ms·

Log in or sign up?

67 points by r11t 17y ago

NikkiA 17y ago
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.
- rudd 17y ago
  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.
  - saikat 17y ago
    This approach only really works with signups that ask for an E-mail instead of a separate username.
    - BerislavLopac 17y ago
      As should all of them, really...
      - ryanwaggoner 17y ago
        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.
        BerislavLopac 17y ago
        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.
- saikat 17y ago
  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.
  - DTrejo 17y ago
    His webapp: http://gomockingbird.com/mockingbird/ http://gomockingbird.com/mockingbird/ Login/Register button at top right
- camccann 17y ago
  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).
  - jonknee 17y ago
    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.
- teej 17y ago
  If an existing user misspells their username, being taken to a register screen is not where they want to go.
patio11 17y ago
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.
jeremyw 17y ago
Some Google research comes to the same conclusion Leah does, with slightly different behavior. http://sites.google.com/site/oauthgoog/UXFedLogin http://sites.google.com/site/oauthgoog/UXFedLogin
zck 17y ago
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.
- rantfoil 17y ago
  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.
  - rapind 17y ago
    That's a great point. The convenience to most users justifies the inconvenience to the few who miss-type their password.
    - drusenko 17y ago
      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.
  - zck 17y ago
    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.
    - drusenko 17y ago
      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.
rufo 17y ago
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.
- BvS 17y ago
  I like the way justigining.com is using here: https://www.justgiving.com/fundraising-page/Creation/?pcid=557138e8-f6b9-4903-a488-845d1e57ecd6 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).
  - rapind 17y ago
    This is great. Thanks for the link. I'll probably do a similar flow in a project I'm working on.
snprbob86 17y ago
We independently conceived of Hurl's approach. It looked like this: http://imgur.com/Th9yi 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.
thwarted 17y ago
"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).
Tichy 17y ago
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.
- yesimahuman 17y ago
  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/ http://aws.amazon.com/ec2/ The way you would go about logging in from that page is less clear than most websites.
aw3c2 17y ago
Don't rely on Javascript for things this important.
drusenko 17y ago
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.
- deleted 17y ago
  [deleted]
- decadentcactus 17y ago
  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).
yummyfajitas 17y ago
Mathjobs.org uses something along those lines, though in my opinion better than this implementation. https://www.mathjobs.org/jobs?info-ja https://www.mathjobs.org/jobs?info-ja
james234 17y ago
Somebody needs to kick Leah Culver off her high-horse and into the pool of disgusting self-obsession shit she deserves. No, Leah -- you are not hot. You do not have intelligent or interesting conversation to offer to the world of GUI interface. You're too obsessed with yourself, your own name, and the hype of that pathetic rag known as "leahculver.com" to offer any credibility. Sure, you know how to use people . . . that much is obvious. Please stop spamming hackernews.com with your own self-interested boilerplate.
vl 17y ago
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 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).

67 points by r11t 17y ago

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.

rudd 17y ago
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.
- saikat 17y ago
  This approach only really works with signups that ask for an E-mail instead of a separate username.
  - BerislavLopac 17y ago
    As should all of them, really...
    - ryanwaggoner 17y ago
      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.
      - BerislavLopac 17y ago
        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.
saikat 17y ago
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.
- DTrejo 17y ago
  His webapp: http://gomockingbird.com/mockingbird/ http://gomockingbird.com/mockingbird/ Login/Register button at top right
camccann 17y ago
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).
- jonknee 17y ago
  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.
teej 17y ago
If an existing user misspells their username, being taken to a register screen is not where they want to go.

patio11 17y ago

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.

jeremyw 17y ago

Some Google research comes to the same conclusion Leah does, with slightly different behavior. http://sites.google.com/site/oauthgoog/UXFedLogin http://sites.google.com/site/oauthgoog/UXFedLogin

zck 17y ago

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.

rantfoil 17y ago
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.
- rapind 17y ago
  That's a great point. The convenience to most users justifies the inconvenience to the few who miss-type their password.
  - drusenko 17y ago
    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.
- zck 17y ago
  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.
  - drusenko 17y ago
    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.

rufo 17y ago

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.

BvS 17y ago
I like the way justigining.com is using here: https://www.justgiving.com/fundraising-page/Creation/?pcid=557138e8-f6b9-4903-a488-845d1e57ecd6 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).
- rapind 17y ago
  This is great. Thanks for the link. I'll probably do a similar flow in a project I'm working on.

snprbob86 17y ago

We independently conceived of Hurl's approach. It looked like this: http://imgur.com/Th9yi 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.

thwarted 17y ago

"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).

Tichy 17y ago

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.

yesimahuman 17y ago
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/ http://aws.amazon.com/ec2/ The way you would go about logging in from that page is less clear than most websites.

aw3c2 17y ago

Don't rely on Javascript for things this important.

drusenko 17y ago

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.

deleted 17y ago
[deleted]
decadentcactus 17y ago
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).

yummyfajitas 17y ago

Mathjobs.org uses something along those lines, though in my opinion better than this implementation. https://www.mathjobs.org/jobs?info-ja https://www.mathjobs.org/jobs?info-ja

james234 17y ago

Somebody needs to kick Leah Culver off her high-horse and into the pool of disgusting self-obsession shit she deserves. No, Leah -- you are not hot. You do not have intelligent or interesting conversation to offer to the world of GUI interface. You're too obsessed with yourself, your own name, and the hype of that pathetic rag known as "leahculver.com" to offer any credibility. Sure, you know how to use people . . . that much is obvious. Please stop spamming hackernews.com with your own self-interested boilerplate.

vl 17y ago

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 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).