
Log in or sign up? - r11t
http://blog.leahculver.com/2009/11/log-in-or-sign-up.html
======
drusenko
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.

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

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

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

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

~~~
drusenko
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.

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

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

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

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

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

~~~
camccann
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
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.

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

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

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

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

------
aw3c2
Don't rely on Javascript for things this important.

