

Techniques To Simplify Sign-Ups and Log-Ins - cwan
http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/

======
Hovertruck
"Use a Question Mark Icon for the Password Recovery Link"

Am I the only one who thinks that is really unintuitive? I don't even think
clicking on that icon would cross my mind as a user, and I would spend my time
trying to find the "Forgot Password" link.

~~~
skx
The way that I've always handled this is to only show the "Forgot Password"
link after a login attempt fails.

Maybe that's unfair; expecting a user to attempt to login even if they're not
sure of their details, but it always seemed reasonable enough to me.

~~~
pbz
That's not intuitive. When I go to a site I know if I remember the password or
not. If I have no clue what the password could be I won't even attempt to
login. If I don't see the "forgot password" link I would assume the site
doesn't have that feature and leave.

~~~
jtheory
Agreed -- particularly because the site may have some kind of lockout feature
if I fail too many attempts, there's no chance I'll waste one just to see if
there's a forgot password link on the failure screen.

------
mekoka
Another thing that I'll start to experiment with is delayed confirmations.

The confirmation step via emails is one of those things that has been copied
over and over, without knowing, in many cases, what problem it addresses in
the first place and if it's crucial to one's particular situations.

I think having to interrupt your visit to log into your email, is another
speed bump to a smooth registration process.

A better approach, in my opinion, would be to let users just start interacting
with your service right away. Give them 5 to 7 days to confirm their account,
after which it is automatically suspended. You can let them know the next time
they try to login that they never actually clicked the link they received via
email a week earlier. The timeframe is long enough that they can actually use
the service with no hassle and it's short enough that they won't have
forgotten which email and password they gave during registration.

Of course, if the operations they're trying to perform in your site are
sensitive enough (e.g. purchase, sale), you should let them know that it
requires an immediate confirmation of the email address.

Other unrelated advices:

\- if you use the email as a login name, then allow users to have whatever
handle they'd like. i.e. don't make the username unique. Also, allow spaces in
that field. e.g. StackExchange.

\- under no circumstance should you keep an unencrypted record of the
password. It's tempting to think that in the name of user friendliness,
whenever someone loses their password, you will just send it back to them. As
soon as I see my password sent to me in an email, I usually logon to the
website, change the password to 12345 and depending of the sensitivity of the
data kept by the service (e.g. web hosting), I would consider stopping using
it altogether (Ironically, I've had cases of websites telling me that 12345 as
a password isn't secure enough for their service, after they'd sent me my
password via email).

~~~
bxr
Its also worth it to decide if you need user email addresses at all, chances
are you don't. For most services the only function of having the email address
is to spam the user. Yes, there are password resets but you don't have to
force it on them, let the user decide if they want to make that fallback
available to them.

~~~
lukifer
For better or worse, email has become the primary way of authenticating
identity, with Facebook and Google Id in second and third. Password resets are
vital if your service is non-trivial, and I consider having _some_ form of it
to be absolutely necessary.

------
ZoFreX
> use a hidden and required text field generated with client-side Javascript

So now only users with Javascript enabled can use your website. I'm sure that
will increase conversion.

> Spambots can’t fill in the field because they can’t interact with objects in
> client-side JavaScript; only users can.

Not true anymore.

> you can create a honeypot form field that should be left blank and then use
> CSS to hide it from human users, but not bots

Apparently those of us that are blind, browse from the terminal, or use
automated form-fillers are bots and not users too?

Some of this advice is good, some of it is very obvious and widely
implemented, and some of it is bad. As the author has left determining which
are which as an exercise to the reader, I'm not sure they know either.

~~~
portman
>> _"So now only users with Javascript enabled can use your website._ "

It's easy to measure what percentage of your users have JavaScript disabled.
For a consumer website, it's probably measured in the _hundredths of a
percent_.

If you can make a change that increases the conversion for 99.97% of your
users, even at the cost of ZEROING the conversion for 0.03% of your users,
then you will still come out ahead.

~~~
lukifer
I would be very, very curious to see hard numbers on this.

Also, it's trivial enough to add a <noscript> tag advising users to turn on
Javascript (with a friendly "here's how" link), or you can do the work to
degrade gracefully. Your conversion might drop for such users, but there's no
reason it should go to zero.

~~~
mauriciob
Or you could add the Captcha in this case.

~~~
prawn
In which case, are most captchas going to screw blind people anyway?

~~~
count
reCaptcha has highly-accessible captchas, including audio versions.

~~~
ZoFreX
Have you ever tried entering an audio captcha?

~~~
prawn
Can't say I have. Is it not as one might imagine?

~~~
ZoFreX
It's difficult to describe. Go sign up for a new Google account [1] and click
the wheelchair symbol to activate the audio captcha.

[1]: <https://www.google.com/accounts/NewAccount>

~~~
prawn
On the off chance someone reads this, I'll try to describe it: over the top of
random, unintelligible babbling, a voice reads alphanumeric characters. Parts
of it are about as difficult to understand as some captchas are to read
recently.

------
redstripe
I just ask for an email address. I then email an auto generated password to
the user. Their first login with the password I sent creates the account and
takes them to their profile page which allows them to change their password or
fill in other non essential info.

This system has a few benefits:

* No annoying "username already taken" or "password too short" rejections that make people give up.

* No junk accounts that haven't been verified since I don't create an account until the first login

* Person's email history has a record of their password if they're the type of person that doesn't care to change it.

* Since I'm really lazy, the account creation code is also the password recovery code. It just emails a new password.

I don't see any downsides with my system.

~~~
aristidb
A downside might be that you send passwords over unencrypted e-mail?

~~~
lukifer
I consider this huge. Aside from the obvious man-in-the-middle network attacks
that could capture this easily, it also creates a huge physical security flaw:
if you save/archive your emails, I can sit down at your machine, type
"password" in the search box of your mail client, and trivially steal a dozen
or so of your passwords. If these weren't auto-generated, it's even worse, as
most people re-use passwords.

~~~
redstripe
If someone has access to your email client you're hooped anyway.

There is nothing stopping an extra security conscious user from deleting the
email and changing their password right away. What it does is to give a
convenience to users that want to treat your service as a trial. Picking
unique user names and password is too far down the developing a relationship
path for me personally.

~~~
lukifer
Against knowledgeable techies, sure, you're hosed either way. I'm talking
about more casual security threats: a mischievous child, a bad breakup, a
sneaky Best Buy bench tech. It's the difference between leaving your front
door unlocked, versus leaving it wide open.

~~~
jules
Don't most sites offer password recovery via email?

------
lukifer
I'm surprised they didn't mention what I consider the greatest cardinal sin of
sign-ups: if you're not validating email addresses, start the user's session
as soon as they register, instead of making them re-enter the same info again
into a login box. (Even if you're sending a validation email, you could allow
the user to postpone validating, or at the very least, log them in
automatically upon clicking the link in their email.)

~~~
Ixiaus
This is a big one. I threw out the "click the activation link email" process a
long time ago, I now just set the session and push the new user straight into
the panel.

------
bane
Not sure if it was accidental or not, but we ended up with the single simplest
sign-up/login I've ever seen. We've even received a few emails from users
alarmed at how simple it is. We're considering adding a few artificial steps
(like filling out a profile) so that users _feel_ more like they are creating
an account.

1\. Click login

2\. Choose account provider

3\. Grant us authorization access

4\. Done - we pull your name and email address from the OAuth information and
autopopulate your user profile.

At this point we don't strictly need any more information, and adding more
account providers doesn't increase the number of steps. Actually, when we only
supported Google accounts we didn't have a step #2.

We may start asking people some more questions, but for now signing up and
logging in virtually identical user experiences.

~~~
pamelafox
We did that for an app, and let people pick from Google, Twitter, or Yahoo.
They'd sometimes forget which one they'd chosen (like after being away from a
bit or clearing the cache), and then login with a different one and get
confused as to why their data was missing. Do you encounter that at all with
your users?

~~~
jtheory
That's what kills me about these flexible sign-ins -- I was locked out of
stack overflow for months because I have accounts on all of these providers,
sometimes more than one, and I had no clue what I'd used initially.

No idea what the solution to this problem is, but I suspect it isn't going
away.

~~~
tripzilch
I have an idea, but I'm not sure if it would be a security risk.

Let the user pick a username to go with the ID provider. When you fill in the
username, it'll look up (AJAX) which provider was used and offer/highlight
that one?

The question is, is it a security risk if anyone can type in any username to
find out which ID provider it is used with?

------
MatthewPhillips
1000x times yes about the newsletter checkbox. Nothing turns me off to a
service more than being tricked into receiving a newsletter. I consider those
to be spam and mark them as such.

~~~
bxr
Having the newsletter unchecked by default is effectively the same as not
having a newsletter.

Personally, I think "don't have a newsletter" is a great idea (it reduces UI
cutter too), but people want to send newsletters and the only way to make
sending a newsletter worth the time spent to prepare it is by making it opt-
out not opt-in.

edit: I'm not saying I support this, just that a newsletter is never done in
the users' interest but as an advertizement. It might make for good UX for the
user for it to be unchecked, but thats kind of the point, the entire concept
of the newsletter relies on bad UX to gain subscribers.

~~~
masklinn
Opt-out newsletters are illegal in the EU, as per EU Directive 2002/58/EC.

~~~
pbhjpbhj
Article 13.5 means that only article 13.2 applies to non-natural persons (ie
businesses, very weird) and hence "provided that customers clearly and
distinctly are given the opportunity to object, free of charge" to receipt of
messages then it appears a company can spam you if you first gave them contact
info in some way.

Indeed the Article only says they have to allow you to object, nothing about
the company not sending you repeated emails when you do object.

Looks badly drafted and without teeth IMO.

\---
[http://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electr...](http://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications)
[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:...](http://eur-
lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32002L0058:EN:NOT) \- full
current text

~~~
salvadors
Directives don't really have teeth, per se. They don't take direct effect, but
need to be passed into each member's country law separately.

AFAIK most made opt-out illegal, even if the directive didn't necessarily
require it well.

~~~
pbhjpbhj
Do you know of any quick reference to the individual laws created as a result
of ratification of these articles?

------
bugsy
I'm skeptical of such articles, but this one had a lot of good advice.

I so hate country selection popups that have 200 countries in them, and United
States is near the bottom even though 95% of their customers are in the US, or
perhaps they don't even ship outside the US. So many sites do that and it is
infuriating.

~~~
hellweaver666
This kind of thing is the curse of using off the shelf e-commerce packages.
You can easily avoid these kind of mistakes if you roll your own.

~~~
reedlaw
Then why does Skype do it for every out-going phone call? I have to select US
from the drop down list every time I make a call even though my Skype number
is US based.

~~~
personalcompute
I remember reading in the Gnome Human Interface Guidelines (a document that
defines consistency standards for gnome (linux gui) applications) that
countries should always be alphabetically ordered as to not appear to favor
any of them. Interestingly, it doesn't appear to be in the guidelines anymore
though.

~~~
BrandonM
That makes a lot more sense in Gnome, a world-distributed open source project,
than it does on many websites, where it's quite easy to figure out the source
of the majority of your traffic.

------
codenerdz
Using an Oauth Provider for Signup and Login makes most of these techniques
moot. For the service Im working on, im using a wonderful OmniAuth gem that
together with Devise allows for easy support of popular OAUTH providers such
as Facebook, Twitter, Linked In, Google, you name it. After dealing with
forcing users to come up with yet another password to sign up for the service,
I prefer that somebody else deals with that and I just store OAUTH tokens

~~~
dholowiski
What happens when your oauth provider goes out of business or decides they
don't want to offer oath any more and you lose all of your users?

~~~
codenerdz
Ill take the risk of Facebook, Twitter, Linked, Google, etc going out of
business before my service does :)

------
chime
> Spambots can’t fill in the field because they can’t interact with objects in
> client-side JavaScript; only users can.

Not true anymore. What you could do is add a hidden field with
value=encrypt(timestamp+salt) and only accept the form if the decrypted
timestamp is at most x hours old. If you want to further restrict it, you
could also add the IP to the encrypted value. This will fail if a user gets a
new IP between loading the form and submitting it (laptop user moving around,
VPN gateway changes etc).

~~~
mekoka
Another technique against spambots that I've used along the line of "hidden
fields" is to have a textfield that should NOT contain anything at submission
time.

You hide the textfield (margin: -10000px) and give it a name unique enough,
that browsers with autofills won't have a record of a value ever entered
there.

Spambots usually fill every fields, so if you see a value in the field when
you process the registration, you know that it's highly likely that a non-
human is registering. You now have the option of rejecting it, or accept it
but put the account in a "monitor" queue.

One pitfall is that this scheme expects everyone registering to uses css. You
can however give various hints to non-css users, to keep the textbox empty.

~~~
djb_hackernews
That's wasted effort. The bots are usually built by humans, and the humans can
detect that and build the bot to ignore text fields with margin < -1000 or the
unique name or something.

~~~
aik
I agree. I think this method is a great idea and is much more foolproof:

"You could also use Honeypot Captcha approach: you can create a honeypot form
field that should be left blank and then use CSS to hide it from human users,
but not bots. When the form is submitted, you check to make sure the value of
that form field is blank."

<http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx>

~~~
djb_hackernews
Fails the same test. I build what can be considered bots for a living, though
they have nothing to do with spamming or otherwise shady reasons.

Part of the process in building the bot is to send exactly what a browser
would send, and we do this by actually making the requests in a browser and
viewing the raw request. If my browser doesn't send a honeypot captcha,
neither does my bot.

~~~
aik
Say you have a field hidden with a div on a low profile, minimum traffic site
(100 visitors a week). It's incredibly unlikely and pretty dumb for a bot to
be made specifically for that site -- in this case, how could a bot determine
whether that field should contain a value or not?

------
brm
One that gets missed almost everywhere is: if I type the wrong username or
password, keep my username in the field (so many erase the forms when
returning the error). That way I can tell if the mistake was in my username or
my password and if it was in my password I don't have to retype everything.

~~~
arank
i think its done to prevent brute force attacks on passwords. If someone knows
that username was correct and password wasn't, he knows something! That's why
the message 'username or password does not match' and that's why both the
fields needs to be empty when page loads with error.

~~~
dvdhsu
Depends on whether the login username is public or not.

If you're on a community based site where others can see your username,
there's no reason to hide it. Anybody trying to brute force your password is
probably specifically targeting your account.

On the other hand, if you're on a service where other people cannot see your
username, it would indeed be better to return a 'username or password does not
match' error.

~~~
kwantam
I don't think the idea is to indicate whether or not the username is correct.
No matter what the user enters for the username, when you spit back "username
or password incorrect," fill the username with what they typed. A brute force
attacker gets no more information than he would with an empty username field
because what comes out is identically what he put in, but a real user who
mistyped his password knows this immediately by checking the username field
and verifying it's correct.

------
ma2rten
In my option there is a lot of bad advise in there:

    
    
      Require Users to Type Their Password Only Once
    

At least I am very likely to overlook a typo, but less so to make the same
typo twice.

    
    
      Allow Users to Auto-Fill Their Payment Address From the Shipping Address
    

Why not make a check box "same as billing address"? That way if people make a
mistake they only have to correct it once.

    
    
      Don’t Check the Newsletter Option by Default. Offer a Preview Instead
    

And how many people will click on that preview ?

    
    
      Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript
    

sure

    
    
      Allow Users to Unmask Their Password
    

If I saw this I really would have no idea what the checkbox "check password"
does.

    
    
      Make the “Submit” Button as Wide as the Text Fields
    

Never had problems with being insecure which action I was about to take when I
logged into facebook.

    
    
      Allow Users to Log in Via Facebook, Twitter or OpenID
    

I don't have twitter, OpenID confuses me and I hate websites where I have to
login with facebook.

But don't get me wrong I still think it's good to think about this stuff and
don't take everything for granted, just because everyone does it. From that
perspective it is a great post.

------
bitsm
I'd be very careful when considering and implementing most of these ideas.
While the sentiment is correct (make users' experience easier), many of these
approaches have pitfalls or require fallbacks.

Your signup and login pages MUST be bulletproof.

Autofilling city/state from zip, for example, requires an updated database of
postal codes, but users will often consider your autofill city as "wrong",
since they use a different district/locale name. Make sure users can override
your guesses.

------
p4bl0
Autofocusing the login field is a bad idea. Sometimes the javascript take some
times to load and the user already filled the login field and is already
typing is password when the javascript focus the login field: then the
password is written in clear on the screen, and that's not pleasant for the
users.

~~~
lautis
That's why you should use HTML5 autofocus attribute (perhaps with a JS
fallback).

[http://www.whatwg.org/specs/web-apps/current-
work/multipage/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/association-of-controls-and-forms.html#autofocusing-a-form-
control)

------
andypants
Does anybody else think unmasking the password field is a terrible idea?

~~~
mekoka
I think it depends of the sensitivity of the material in the website. e.g. I
would never do this for a financial service website, just in case I get sued
later. If your website doesn't require https for logins, then unmasking the
password at registration time is the least of your worries.

It should nonetheless be noted that many browsers cache values entered in non-
password fields, so if someone is using a shared computer to register, the
next person might only have to double-click on the non-hidden password field
to see a list of previously entered passwords. Not so good.

~~~
mooism2
Does the value in a field that gets toggled between password and plaintext get
cached when the field is a password at the time the form is submitted? We
could always ensure the field was in password mode at that instant.

------
gchucky
Admittedly I hadn't heard of using a client-side JS input box as an
alternative to a Captcha. Does that sort of thing actually work, or can
spammers get around it? Is there any anecdotal data to suggest that that's a
better method? (not snarking; actually curious)

~~~
palish
No client-side method can ever work against a sufficiently motivated spammer.

For example... 1) Start capturing packets via wireshark. 2) Fill out the form.
3) Replay the captured packets, altering the username.

Presto, now you can sign up as fast as you want.

~~~
jcampbell1
The strategy you suggest, capturing packets, won't work against any reasonably
modern codebase that has XSRF prevention. I agree with your initial statement,
but I highly recommend Seleinum scripts instead of wireshark for your spamming
needs. It is slower, but much more likely to actually work.

------
Herwig
CAPTCHA's are always annoying, no matter what. So why not make some money.
Lots of new companies out there offering CAPTCHA ads.

~~~
thinkzig
While you're right that all CAPTCHAs are annoying, the CAPTCHA ads are a whole
different level of annoying. I think you'd lose more goodwill than you'd gain
in money from doing this.

~~~
Herwig
depends, I believe it will depend on what the user has to type.

~~~
michael_dorfman
I disagree. I'd find an ad in my CAPTCHA to be sleazy regardless of what I had
to type. It's a bad idea, full stop.

------
dholowiski
Thats a great article. The first two points inbound the most interesting...
Let the user choose a username after they sign up - I wonder what sites do
that now, it's a good way of removing a barrier to entry. The second I'm not
so sure about... Having the user enter their password once and showing it to
them - I'd be worried that you might lose users to simple typos. Most of the
rest is kind of common sense but a great reminder that the login/signup system
is probably the _most_ important feature of a web site, since it's the one
users interact with most often.

~~~
evanw
I believe StackExchange allows you to create a username after you've created
an account, you start off with something like "user12345" if you don't specify
one.

------
pdenya
I hate being forced to login with my email address. My username is the same or
similar for most sites I use but I use a site specific email (with gmails +
feature) for almost every sign up.

~~~
periferral
i presume you use that to filter spam. you could always have your userid as
your email where the email is always username+site@emailprovider.com

however, i have noticed some sites dont like the + which sucks because the
spam model breaks down

~~~
pdenya
right, I have that problem, remembering whether or not the site accepts the +
as well as an issue with sites with long or weird to spell domain names.

------
aliglia
I have never understood why I need to type my password twice. Inevitably I
just copy what I wrote in the first box into the second.

I'm also interested in the elimination of the post sign-up confirmation email.
I'd rather get a "Welcome! If you didn't sign up for this service, click here"
email, but I can imagine that if I didn't actually sign up for the service,
I'd never want to "click here" for fear of spam. There has to be another
option, though. Anyone have any bright ideas?

~~~
rsoto
You type your password twice because you might make a mistake. Also, you can't
copy anything from passwords fields.

~~~
aliglia
Sorry I misspoke -- I copy/paste from email confirmation fields. And I
understand why password confirmations exist, but I think the option posed in
this article is a much more elegant solution to that issue.

------
tcarnell
From my experience of building web applications only two pieces of information
are EVER required at registration time:

1). Email address - unlikely to be forgotten and is useful, ie you can then
contact the user

2). Password - so the user can access the site. And I agree, dont ask twice
for this, as long as you have a password reset feature.

Any further information can be obtained once the user is inside the system -
and full explainations can be given as to why particular information is
required.

And never use captcha! There are a millions tricks that you can employ to
avoid bots.

~~~
tcarnell
...so really what I am saying is that I can not think of a reason to ask for
address, city, security questions, usernames etc at registration time.

------
MatthewB
These are all great suggestions. Smashingmagazine is a great resource for
developers.

I'm not quite sure about a checkbox to confirm password...maybe I need to see
it actually implemented somewhere to know if I like it.

~~~
r00fus
It's basically equivalent to the "show characters" checkbox in your wifi
password entry.

~~~
blasdel
That's there in the WiFi dialog for a very specific reason: you're usually
typing in _someone else's password_ , which is often being dictated to you as
you type, so mistakes are inevitable.

In every other case it's _your_ password that you type all the time (or
paste). In the rare instance that you fuck up it's easier to enter it again
than it is to fix it.

------
kmfrk
_> Log Users in Without Leaving the Page_

As someone who uses LastPass, don't do this. It (usually?) won't let LastPass
log you in to the site nor save the log-in details for a new site - a huge
pain in the ass.

On another note, if I fail to enter the right details or check the right
boxes, _don't_ let me start all over again! Opera is great in how it lets you
go back and retain all entered data, but other browsers are not as good at
this.

------
bjonathan
the best signup flow I have seen recently is <http://friend.ly> perfect
integration of facebook .

~~~
desigooner
The problem with the likes of friend.ly is that it forces me to use the email
address associated with Facebook and it's PITA if you use multiple email
accounts / filters for multiple purposes

~~~
brimpa
The problem is _nothing_ is editable (full name, birthday, location, email --
ok, they can have gender). If I'm signing up for some brand-new, unknown
service, I'm usually not inclined to divulge anything more than an email
address with an alias (+newsite@gmail.com).

~~~
ArtasBartas
You might want try out our service (Spockly.com) to tackle this problem: it
allows you to limit your sign up form to email (& password) and get the basic
info like age, gender, location from us. So sign up is straightforward, but
you still get some insight about your users. Of course, it only works with
people who have public profiles on social networks.

------
supershazwi
I feel that asking a user for the right username after they sign up wastes
even more time when they can settle it all at once at the sign up page... The
tips mostly reduce hassle and why cause them more trouble by alerting them
that their username is already taken when they felt they're already set to use
the site.

~~~
dpcan
But asking for the username after sign-up gets you the user's email address.
If they don't create a username, you can now provide direct support and ask if
they need help with the next step in the sign-up process, etc.

------
colanderman
Regarding auto-completing the country field, most modern web browsers allow
you to enter text in a drop-down field, and they will auto-complete for you.
(Although last I checked, IE had the annoying tendency to simply choose an
entry starting with each character you typed.)

~~~
bostonvaulter2
But how many users know that? Also you have to know exactly how they spelled
the your country name which isn't always known, such as USA versus United
States, and UK versus Great Britain.

------
bricetebbs
Depending on the security needed for a particular application I have been
wondering why not just Email for authentication since its common for password
recovery. More here: <http://blog.headspin.com/?p=352>

~~~
periferral
Seems like an interesting proposition and makes sense overall. I can think of
a few issues however.

1\. You always need access to email to get access to a website. This means
that for whatever reason you don't have email access, you are locked out of
all sites.

2\. While it works from a security standpoint, you still add overhead to the
users task. Users have to go between website and email and back to website
just to log in.

3\. slow connections might make the task even more cumbersome since you now
add the delay of checking emails just in addition to logging into the website.

~~~
bricetebbs
Agree on all points. But I still like the idea as an optional way for people
to log quickly in without having to give the site owner any password info.

And yeah its a little more tedious if the site doesn't have a long session
time.

~~~
ydant
That's why I like using it in conjunction with passwords. The forget password
link just provides an auto-auth one-time use link that suggests (but doesn't
force) the user create their new password.

In theory, you could just continue to click "Forgot password" every time you
need to log in, indefinitely. Some sites that offer this sort of
functionality, that's what I do.

What I hate is when the forgot password link FORCES you to change your
password. If there's a forgot password link that lets me log in easily via
email, then I see no reason to be forced to change my password.

------
a3nm
Using OpenID makes the rest of the techniques moot (except for OpenID
providers), right?

~~~
Tichy
I think OpenID has proven to be uneffective, some (HN popular) sites have
removed it again (37signals? not sure).

I have problems with OpenID, too, because I tend to be unable to remember
which OpenID login I used for a site.

~~~
Timmy_C
Why do you use more than one? I thought the point was that you could sign in
once with your OpenID and be signed in everywhere.

~~~
Tichy
It just happened, I was a little bit careless and used both Yahoo and Google.
I don't remember the exact problems anymore - I think also if the web site
does not link directly to the OpenID provider it is hard to fill in the
details.

Or maybe it was that Yahoo creates several OpenID logins?

------
fleaflicker
Any ideas for speeding up birthdate entry? Lots of sites need it to comply
with COPPA.

~~~
Raphael
A single button or checkbox labelled "I am 13 or more years old."

------
strebel
Been a fan of this login (<http://www.janrain.com/products/engage>) service by
janrain for some time. Use it where I can on apps.

------
ballard
OpenID, or email address -> confirmation.

------
lautenbach
been looking for good writeups on sign-up best practices. thanks for this!

------
georgieporgie
A lot of these seem to be, "do this really nonstandard thing because it suites
my tastes." I'm all for streamlining, but if you change a common way of doing
things, and you're not targeting a technical crowd, your new way had better be
crystal clear.

As someone who talks to non-native English speakers, "check password," is
triggering a burning rage within me. There is so much potential for
misunderstanding.

