Slick online registration

« Previous / Next »Filed under geekiness, on a spooky Hallowe'en, Sunday, 31st October 2010.

I realised this week that I've been doing online signup completely wrong all this time. By online signup, I'm referring to the process of letting users register to use your site - for free or otherwise - providing the website owner with an all important email address that can then be marketed to.

The model I use (and twitter, and facebook, and everyone else) has always been:

  1. Invite the user to register
  2. Capture their details via a form, including the all important email address
  3. Send a generated password to that email address
  4. Sit and hope the user takes that password and logs in to their new account

Why is this important? Because the owner of the site or application needs a valid email address to prove that the user is in some way "real"; someone had to have read the mail in order for them to login for the first time. This doesn't stop people supplying other phoney details or using "throwaway" email addresses, but on the most part, this mechanism does provide a reasonable guarantee your new member is human and therefore a potential customer.

This method is tried and tested, the code is easy to write and it works. The problem is the limbo moment between registration and the new member's ability to use the service they signed up for.

Generally this isn't too big a consideration on a computer, but the friction generated switching between apps is much greater on a mobile device. I've been playing with mobile a lot recently, both at work and at home, and getting this signup step right is paramount to get users into a little fun app I've been working on. brilliantly shows how this should be done. It provides three registration methods - via facebook connect, via twitter OAuth, or by using a regular registration form - then allows you in to the app immediately. With no time stuck in limbo, the user has a chance to get hooked by the product there and then.

Cleverly, they still send an email containing a link the user can click to confirm their identity but until this link is clicked, the user can play on the site as normal, but are just restricted slightly on some of the functions they can perform. I don't know if Quora have a time limit to do this action, but I suspect they probably do. Either way, there is more code involved doing things this way, but I suspect the benefits are very real.

Sadly for me, this means I'm going to be spending the next few days rewriting my registration code on my new app, but the end result will hopefully be worth it.

A tiny thing to note with either method is that one needs to be careful how they code their emails so as not to have them dumped straight into the user's spam folder, but that is a topic for another day.

Add a comment

Sorry, comments are closed

Jon Combe