Some Hard Lessons in User Interface Design

Developers tend to blame the stupid users when problems occur. But when it's 5% of the users reporting problems you can't even try to trot out that lame excuse. Typically, these problems arise due to flaws in the user interface (UI). I believe that's exactly what happened in Holidailies. The registration difficulties probably resulted from two bad UI decisions that I made.

This year, we used nearly the same registration process as last year. The only thing we changed was the way that we assigned usernames. Last year, when you registered for the portal you had to choose a username and enter it into an empty form field. This year we provided a default username value. When you entered your contact email address into the form it also was copied (by the magic of javascript) into the username field. That provided a default value that you could choose to keep or change. A significant number of people (114 out of 165) chose to keep the default.

I was trying to simplify the registration process by eliminating what appeared to be an unnecessary step. An email address is a perfectly good account identifier. I could use that and save the user the bother of entering a username. Even better, if I offered it as a default then the user could accept the helpful (sic) default answer if it suited them, or substitute some other value if they preferred. It's easy and smart, what's not to love?

That all sounds nice, but it's wrong for a couple of reasons. First, even though I thought it was helpful to offer a default username, it really wasn't. That's because most people already have a regular, preferred username for Internet logins. The default probably was different from their usual preference, and thus harder to remember. I wasn't doing any favors by foisting a default answer in a case where the user already had a preference.

Second, and maybe most critically, when I provided a default I short-circuited the user's memory process. The username credential is important to remember. When the user is given a default value, they are likely to just accept it and sail right over the question without thinking—and without committing it to memory. When, instead, the field is blank, the user has to stop and think and make a choice, with greater likelihood the choice would be committed to memory.

So, now I know that offering a default username was not a good thing to do.

Lesson One: Do not provide a default when the user probably has a preference for something else.
Lesson Two: Do not provide a default for information that is critical to remember. Make the user stop and think.

The next problem is that the username field in the database is 20 characters long. If you entered a longer username—and email addresses often are—it would be truncated to length and saved to the database. So, when that user (say "joeblogger [at] example [dot] com") returns and enters their username, the database lookup fails and they are rejected. That's because the username they entered isn't in the database, but the twenty character "joeblogger@example.c" is.

The problem here is that I failed to assert the data constraint: maximum username length is 20 characters. Instead, I silently corrected data (truncated to length) to meet that constraint. That sounds helpful, but often isn't. The information has been changed on the user without their knowing.

Lesson Three: Do not silently correct data that fail to meet constraints. Assert the constraints.

The rule of that last lesson, like all good rules, has exceptions. The trick is knowing when to invoke the exception. Sometimes it's reasonable to canonicalize the user input, just so long as you do so consistently. For instance, on a form field where a URL is expected, it may be reasonable to canonicalize to a standard form, adding "http://" when missing.

In fact, I used canonicalization to resolve this bug. I modified the verify_login() routine to truncate the username to 20 characters before performing a lookup. That converts a long email address to the form it would be found in the database, and so the lookup succeeds.

These problems combined created a frustrating situation for many users. Fortunately, it shouldn't be an ongoing problem. The problem won't reoccur once the user realizes the right way to log in. Nonetheless, even though registration is closed, I removed the clever javascript code from the registration form. I don't want any chance of it sneaking back in next year (should there be a next year).


Comments have been closed for this entry.

re: Some Hard Lessons in User Interface Design

I actually had a variation on this problem with flickr--they use your e-mail address as your login. I wasn't paying attention to this at some point (long after signing up) when I had to log in again. I just assumed I set up the account with my default login, and was frustrated that it wasn't working. So even guys who are generally very good and innovative about UI make this kind of mistake.

On reflection, e-mail addresses just aren't good account names. They can change when you change jobs, get married, get divorced, change ISPs, or relent in the face of excess spam.