I have been writing a lot of code lately for the new product I hope to share with you before the new year. The past two days I worked on a login/create account screen. Two days ago I wrote the shell, got the views created, did all the data entry and set up the basic structure of the controller. My designer set it up to be perfectly centered on the screen so I had to do little things like move it up when the keyboard appeared but only if the keyboard covered the form. Also, on the iPhone, once the keyboard comes up there is no button to make it go away. Touching outside the form hides the keyboard, thus uncovering the additional options. I hooked everything up and made sure it worked in the application the way I wanted. Then yesterday morning I handled all the error cases.

Error cases, for a log in screen? Yes. Login screens are funny little things. They look so simple yet if done right they are extremely complicated, from both a design and technical perspective.

Let’s start with technical. There are only two “good” outcomes in a log in screen. Option 1 is that the credentials entered matched an account and the user was logged in [1]. The second is that the credentials are a new account, an account was created and the user was logged in. But there are numerous “bad” outcomes, everything from the server being down to no Internet connection to bad passwords and email addresses, to incorrect passwords with matching emails [2]. In addition a good login screen must handle special cases like the user forgot his password or, for sites that make you verify an email address within a certain amount of time, verification failures [3].

And that leads me to the second thing: design. The app requires an account so the login view is the first thing the user sees. It not only needs to handle all these cases clearly and succinctly, helping the user when she runs into trouble, but I also needed to remember that this is the first experience she will have with our product. The login screen, albeit functional, also needs to represent the product once you get inside.

Our designer did a great job with the design. It is clean and simple. The interface is straight forward and offers features for those that aren’t certain they want to commit to an account yet but would prefer first to get a better perspective on the product. This is the era of app stores where people download apps, especially free ones, without even reading the description. We didn’t want to assume the user was familiar before installing.

I spent half the day yesterday getting all the error cases worked out, displaying each message with an alert and the alternatives for handling the case. For instance, a bad password (meaning an account was found but the password doesn’t match) could mean that it was just typed wrong or that the user forgot the password. We wanted to make sure both options were available.

The problem was, at about the five hour mark, I realized I hated the way it looked. The alert dialogs were unsightly popping over my form and slightly hard to read with the transparency. It was difficult, too, to relay the options in a straight-forward way. I also felt it needed an indicator so the user knew when it was working. I hate views that take a little time and give no clear indication that what I did had any effect.

So I went back to the drawing board. I stuck with the same login interface my designer designed, but instead of using alerts I created a second view that mimics the login view in appearance but first displays an activity indicator (spinner) before displaying a message, if there is one. The primary choice is highlighted cleanly, with secondary choice options below it. It took me seven additional hours to map all this out, set up a structure so all of this could be handled succinctly, and then make sure it all worked correctly.

I’ve designed a number of log in screens now and tried many different things with them. I never like the way they turn out. I know 95% of customers will spend five seconds on this screen, enter their credentials and move on, without realizing how much time and attention to little details went into it. I’m proud of the entire project and believe it will be a huge success. But when someone asks about the piece of code I am most proud when this project is completed, I may very well say it is this login screen.

—

[1] Technically not logged in. Instead the credentials are valid and they are stored in the app. Each time you access the site the credential, using SSL and other means of protecting your data, are passed to the server.

[2] The complete list of cases are: 1) an account is created and credentials stored; 2) the credentials are valid and stored; 3) user requested a new password; 4) no account exists with this email address; 5) the email is found but the password doesn’t match; 6) the server is down or there is no Internet connection; 7) the email verification was never completed and time has expired to use without verification; 8) invalid username (we handle this case but don’t use one as of this writing); 9) invalid email address; 10) invalid password; and 11) the account is suspended.

[3] Yes, I am using the word “user” (instead of “customer”) very deliberately.