Idea: The simplest registration form ever

If a web application has some sort of registration system (and most do), the registration page should be one of the most attractive, inviting, usable pages of it. It should make you to want to register, not repulse you. We don’t want the user to give up in the middle of filling it because they are fed up with it’s length or bad usability, or -even worse- not even attempt to do so, do we?

The most popular websites usually take this rule to heart and employ the simplest registration forms: Only the basic fields required, and most of the times, even without password/email confirmation.

I was wondering lately – what would be the simplest possible registration form? It should have the minimum number of fields required: Username and password and a field for some kind of human verification.

At this point, some readers might argue “Hey, why not an email field as well?”. In my opinion, the email is not always a required field. Let’s see why it’s being asked for in most cases: Unique identification (to prevent double accounts) and for sending out notifications for important events. However, it’s useless for the first purpose due to all these disposable email websites. As for the second purpose, since notifications can be switched off (and if not, then they are essentially considered spam), it could be regarded optional and we don’t include optional fields in registration forms, do we? ;-)

Of course, in websites that use the email instead of a username to let their users log in, you may just substitute the username field above with an email field (since in that case, the username is what could be considered optional) and we also have two fields. Smart readers might have noticed another pattern here: The only fields that are truly required for a registration form are the same ones that are required for a login form plus a human verification field.

And then it dawned on me: We can make the registration process almost as quick as logging in! We could use the same form for both actions. The submit button label could indicate the dual nature of the form, for instance “Log in or register”. If the username (or email) doesn’t exist, we could then ask the user whether they want to create a new account and present them the human verification field at that point. There is no need for a password verification field, since we could just have a checkbox for displaying what the user typed, if they feel insecure about it.

I find 3 inherent issues with this approach:

  1. Security. If a login attempt fails, the user will know whether he got the username or the password wrong. However, in most websites, you can easily check whether a username exists anyway, so I don’t consider this a real concern. I just included it because I’m certain that if I didn’t, somebody would point it out to me in the comments.
  2. Despite being a more usable approach by nature, it’s not by any means a convention yet. Until it becomes one, I’m afraid that some users will be confused by its extreme …simplicity! Funny, isn’t it?
  3. We won’t be able to employ Ajax verification for the registration form, since it will essentially be a login form as well, and until the user submits, we won’t know what they plan to do (login or register). Having an Ajax verification script there by default will confuse existing users as hell (as in “What do they mean by ‘Username is taken’? WTF??”). So, we have to sacrifice some usability to gain some usability. The question is: Is the usability we gain more than the usability we sacrifice? What do you think?

As you can see by the problems mentioned above, it’s still a rough-on-the-edges idea (I just thought about it and I haven’t refined it yet), but I think it’s interesting. What are your thoughts?

  • http://probablyprogramming.com Paul Bonser

    How about the “login or register” button changes to “login” once you enter an existing username (like you said, we’re already revealing whether the username exists or not), or changes to “register” if you enter a username that isn’t already taken.

    If it changes to “login”, you could also put “Don’t have an account yet? Then we’re sorry, someone has already taken this username.”

    By asking if you don’t have an account yet, you make it clear that the message isn’t intended for the existing user.

    Another option would be to have two different buttons. One that says “login” and one that says “register”. That way you do the “username already taken” message once they click “Register”, but tell them “invalid password” if they click “login”

  • http://leaverou.me Lea Verou

    The changing button label sounds like a good idea but you would have to make ajax requests to the server to determine whether the username exists, which poses 2 inherent problems: 1. The change won’t be instant, so it might confuse some users and 2. If javascript is disabled, what will happen?

    The “one button for each function” is an idea I also thought, but we should be careful in making the login button to stand out more than the register button (to avoid having users accidentally clicking “register”, and to make the register button to look like a button (and not a link), so that they understand that it’s sufficient to click it in order to register (if it looks like a link, they’ll probably assume that it will take them to an ordinary registration form).

  • http://james.padolsey.com James

    Interesting idea.

    I can appreciate the need to simplify; but why does that necessarily mean “to combine”? I feel, by combining two forms, both with very different functionality, you’re going to end up confusing quite a few users. I’m all for simplified registration forms; heck, I would go even further and just have an email field (we can send them a generated password), but I honestly don’t think the benefits of your solution outweigh the potential costs (as it currently stands).

    I think forms are one of the hardest website elements to get right. It’s a constant compromise between convention, usability, simplicity and design. I don’t believe it’s been perfected yet… We need to keep on pushing for new approaches and ideas.

    With a bit of refinement your idea is definitely worth trying… I like Paul’s idea of having two buttons also. (But be careful, many users don’t press a button; they press enter)

  • http://leaverou.me Lea Verou

    Thanks for your valuable input James.

    Is the login form’s functionality actually that different from the registration form? They essentially need the same data to be filled in, they have similar purposes (the first creates an account, the second checks if a matching account exists). In fact many websites combine these forms, by putting them next to each other, on the same page. They just don’t use the same <form> tag.

    I’m strongly against generated passwords: Most users never change them so they keep going back to check “that email” in order to log in (in case they didn’t store it in the browser). Also, it’s unrealistic and pointless to expect a registration form to be easier/faster to fill in than a standard login form, since the login form will probably be filled in a lot more frequently than the registration form.

    I agree on your statement about website forms being the hardest website element to get right.

    I also agree that my idea definitely needs refinment. That’s why I posted it in the first place. :P

    As for pressing the enter key, that’s a very good point and I hate to admit that it’s something I missed when pointing out the drawbacks of the “one button for each function” approach. I guess if the user hits the Enter key, it should treat it as a login and if there’s no matching account and the username is free, provide the option to register.

    • http://james.padolsey.com James

      Good point about generated passwords; they are a bit of a nuisance!