registration - Sign up: Double opt-in still best practice? What about mobile?

Everybody knows the normal registration process:

1. Fill in sign up form


2. Wait for email



3. Click confirmation link in email


4. Done (signed in & confirmation by email)

IMO this process works because people are used to it but it isn't very elegant because it breaks the user's flow. The same process on in a mobile app would look something like this:

1. Fill in sign up form


2. Wait for email, switch to email app


3. Click confirmation link in email


4. Browser opens and shows confirmation page


5. Switch back to app



6. Type in sign on information


7. Done

This is just painful (even more so if the email address used for the sign up isn't the one that is used on the mobile's email client).

I see two main alternatives but both have some issues:

1. 
   

   Don't require a confirmation by email, just sign in the user immediately. Main problem: We can't be sure if the email address is correct (other than syntax).

   
   


2. 
   
   

   Don't require immediate confirmation: Let the user confirm his email address in the next 7 days or so and sign him in immediately. Main problem: Still can't handle wrong email addresses

   
   

Are there any other alternatives or more elegant ways to handle registrations?

Answer

Let's say the user just cannot receive email on their mobile device - for example those that deliberately do not want to be contacted by email - those on a limited data plan - or those without the inclination or technical know-how to setup email.

For whatever reason, there are going to be people who fit that category. So ask yourself if you want to actively include them as new sign-ups - or deliberately exclude them.

I'd be inclined to actively include them and let them confirm the email at their convenience.

Then between signup and email confirmation (whether it's from desktop or mobile it doesn't matter), their account is put in a 'pending' state.

If there's anything secure or that involves sharing, distribution, or in any way involves other people or large volumes of data, or anything that physically costs your business, then this is disabled until email is confirmed, but basic features should still be enabled in this pending state.

This 'pending' state should be displayed clearly but discretely somewhere with the ability to quickly see why the user's state is pending and not fully signed in.

That information would include something along the lines that

• an email has been sent to dev@null.com and is awaiting confirmation


• and with the option to change the email address that was used


• and also an option to resend a confirmation (which happens automatically if you change the email address).

So this is an informal, accepting and flexible mechanism that should adapt to most situations.

Those that confirm straight away won't see the pending state displayed.

Those that don't confirm right away will be gently reminded, but there's no pressure to do so immediately.

Those that continue to use the service for longer without receiving an email can easily check the pending state to make sure the right email address was used.

After a week or so, you might highlight the status somehow and show a suitably apologetic message to say it doesn't look like the user has confirmed the email and would they like to check the email address or send the confirmation email again.

All of this of course assumes that the types of activity your service provides are not all those that really you need to confirm the email address before they are allowed.