array(0) { } Thinking about user registration forms | Darren James Harkness

djh

Thinking about user registration forms

I've been thinking of user registration for a project I'm working on.

Registration is a speedbump every site that relies on user accounts faces.  There's a reason why Facebook/Twitter/Google login is so prevalent in site development: users hate filling out forms, especially if it gets in the way of what they want to do (buy your product, use your new webapp).  Part of this is the complexity of many new user registration forms.  Sites ask them for email addresses, names, complicated passwords - which they have to verify by typing out again, their dog's middle name.... and so the user abandons the form.

Using Facebook/Twitter/Google for login seems like a low-friction method of addressing this. But, do you really want to outsource one of the most important parts of your business to Facebook, Twitter, and Google? What happens when they change their API? Or start limiting your access to authentication based on the number of users you have? At Webstock 2011, Marco Arment made a compelling argument about this:

You don’t need to rely on someone else’s service, and you probably shouldn’t for anything crucial for your business because they don’t care about you because they don’t need to. You need them for everything and they need you for nothing.

Your user database? Sounds pretty crucial to me.

So we need to look at ways of reducing abandonment on our own site registration forms. What if we made user registration easier through better form design? OK, I'm absolutely not the first to think along these lines. Many folks have already talked about this problem. People are intimidated by long forms, they're not sure what you're going to do with their personal information, or they're just plain lazy and your product isn't worth spending the time to register for.

So how can we make it better?

Speed through the registration process.

As site owners, we don't actually need all that much information to start registering their account. We need:

  • a unique way of identifying this user,
  • a way of contacting them about their account, and
  • a password

That's it. The first two can actually be solved by the same piece of information: an email address.  In most cases (with some notable exceptions involving shared accounts), each user registering in your system will have a unique email address. For the most part, there's no reason to ask them to create a username, which they might forget. Their email address is simple, unique, and the user won't likely forget it. If you do have a need to show some sort of display name in your application, wait until the user engages with a part of your site that requires it, and ask them then.

Passwords are another sticky point in user registration forms. Users have to blindly type in a password, then blindly retype it and hope that they've typed the same thing twice.  I made at least 6 typos in that last sentence; what's the likelihood that a user will have to type and retype their desired password into the two password fields, and get frustrated?  There's valid security reasons for enforcing the use of a masked password field, primarily around shoulder-surfing.  Users, having been trained for years to expect a masked password field, will also feel unsettled about typing their password into an unmasked text field.

But what if I suggested that there's a hybrid?  For this, I have a unique CSS-based solution.  Instead of providing two password fields for verification, which are always masked, why not provide a single password field that masks and unmasks based on focus?  No Javascript required, just a modern browser that supports the :focus selector and attribute selectors.

Here's an example:

It's about as simple a form as you can get, and lets the user register an account in a blazingly fast time. The use of type="email" and required="" on the Email address field provides built-in validation on some modern browsers (OK, Firefox).  The password field makes use of CSS selectors and a couple of tricks to provide the masking/unmasking, with the following CSS:

  input[type='text'].password {
    color: transparent;
    text-shadow: 0px 0px 0.5em rgb(210,210,210);
  }

  input[type='text'].password:focus {
    color: rgb(210,210,210);
    text-shadow: none;
  }

And here's the accompanying HTML:

    <div>
    <label for="email">Email address:</label> <input type="email" name="email" required=""/><br/>
    </div>
    <div>
    <label for="password">Password:</label> <input type="text" name="password" placeholder="Select a memorable password" class="password" required="" spellcheck="false"/>
    </div>
    <div>
      <input type="submit" value="Register"/>
    </div>

From the user's perspective, they're provided with a dead simple method for entering and validating their password.  The text is displayed to them in clear text, but is done so with low contrast.  This gives the user an easy way of entering and verifying the password, and not worrying about typos. When they're done entering their password, the field's value is blurred.  This gives us the best of both worlds: the user can see what they are typing in for their password when the field is in focus, but in a way that is difficult for other individuals to eavesdrop on. When they are done entering their password, the contents of the field are obscured, much like the traditional masked password field. This keeps the user's sense of security, while providing a better user experience for entering their password.

From there, the user just has to hit the Register button and click on the account verification link when it is emailed to them. If you need more information from them, such as a name, then you can ask them to provide it there. Though, I might suggest that it's better to wait until there's a reason your site/application needs that information and ask them then - for example, putting up an interstitial screen before they post to a support forum, asking them to provide a name.

I'd be really curious to see results from a site that A/B tested this login form - if you make use of it, please let me know!

Photo from Flickr by Bryan Rosengrant, used under Creative Commons