Yes, Open ID or any social sign in solves the problem but we can't offer it as the only way to sign up.
–
PhilJul 2 '12 at 9:18

You can use OpenID as an option and call it "faster signup".
–
Danny VarodJul 2 '12 at 10:41

3

+1 for OpenID. And please, please, please give us the option of using our own URL, even if it's a small button below the big "Google", "Facebook", etc.
–
André ParamésJul 2 '12 at 15:51

1

You could use Deep Linking To jump from 3 to 7 straight away in case the user opens the email on his device (you shoot him straight back to the app after you've confirmed him)
–
MichaelOct 12 '14 at 19:46

5 Answers
5

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.

I am working on an project right now in our company where we're facing just the same issue where we need a different approach. ATM the sign-on process is the known one:

register

check mail

click to confirm, set password and enjoy

(the SaaS logs you in automatically after you entered your password -- I've seen "flows" doing it worse by letting you log-in by typing your name / password once again after you just entered your password for the first time...)

Now I created a new approach (keyword: onboarding) which will allow the user to instantly start using the SaaS after entering a log-name / password (name = e-mail), but with some functions being locked till the user confirms his account via e-mail.

This is due to security reasons, since the user will be able to use online banking functionality and we don't want fake users fooling around with the service.

Tumblr's onboarding process is some kind this way: You enter your mail, get instant access so you can look around. However, using advanced methods (post comments etc.) you need to confirm first.

E-mail addresses don't serve as a unique identifier in the sense that one person can have multiple e-mail addresses. So, the only reason to have the user's e-mail address is if you plan to contact them via e-mail.

With that consideration in mind, you could take the approach that reddit takes. Users can sign up without an e-mail address. Accounts that have verified e-mail addresses are given a "trophy" (similar to a badge here at SE) stating such, but that's the only difference between a verified and unverified account.

Considering that verifying your e-mail address before ever being able to use a service is annoying, it serves as a barrier to registration. Requiring an e-mail address actually lowers the amount of registered users you will have on your service, particularly if your service doesn't already have an established reputation.

In short, unless your company is losing something significant by the user not verifying their e-mail address, there's not much reason to require verification.

Good input, thanks. We actually need the email address for several reasons but we're just working on getting rid of the username (you'll only need an email address and a password to sign up).
–
PhilJul 20 '12 at 15:05

@Phil So it won't be possible to use a group email address for notifications but have individual accounts? Each account must have a unique email address, and your users must remember which of their addresses they use for your service?
–
Andrew LeachJul 20 '12 at 18:05

@AndrewLeach Actually we have different kinds of members and for some of them it's possible to have several accounts linked to one email address (the whole system is a bit more complex than mentioned in the question).
–
PhilJul 23 '12 at 6:33

Like other people suggested, it's a very good idea to let user's explore your app before email verification or give up email verification at all. But if you really need email verification, you may use the mobile's capabilities to improve the user experience.