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).
I completely agree with delayed confirmations. On the service we're building right now, we're also letting users get started using the site without signing up at all to begin with. Then, if they want to save their data, they'll need to create an account.
On a desktop app, you don't have to enter a filename until you're ready to save...why should you have to do that on the web? (of course, this isn't useful in cases where data is sensitive)
A danger here is that a new user makes a typo in their e-mail address when signing up, puts a fair amount of effort into their new profile/account/whatever, and is then locked out forever. They won't realise they made a typo and will blame the site instead.
But I agree that new users having to leave the site to check their e-mail is a hurdle to get over.
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.
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.
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).