Check User ID Button
November 23rd, 2005
We’ve all been there. You find a new cool site. You decide to register for their service. You enter your favorite user id, the password, your pet’s birth date, the name of your third grade teacher (the cute one that you had a crush on), and your favorite Easter egg color. You finally press Submit. Then you find out the user id is already taken. Arrgghh!
Digg.com bypasses the ugly post-submit depression by putting a “Check” button next to the user id. Enter the name. Press Check. Find out immediately if your favorite Id is available.
It’s brilliant. Why doesn’t every site have it?
November 23rd, 2005 at 8:44 am
Jared, why beat around the bush. Let it be simple:
First Name:[ ] Last Name:[ ]
Password: [ ]
—————————————————————
[Submit]
And, the software does not check the uniqueness of the name, it checks the combination as unique.
No forgotten usernames ever, no multiple email ID confusion, and happier users. What do you say?
November 23rd, 2005 at 8:44 am
Indeed very nice. Though, would it not be even nicer if the extra click on the ‘check’ button would not be needed?
November 23rd, 2005 at 9:02 am
Maybe I’m a little thick, but I don’t get it. Enter screen name and everything else and submit. If the name is taken, edit the name and re-submit. How is checking the name as an additional step better? Isn’t the real problem brain-dead Create Account forms that *clear all fields* if they encounter an error, forcing users to unnecessarily re-enter values?
November 23rd, 2005 at 9:24 am
I think the point here-or the “nice touch” is the immediate feedback. As we process the fields in our heads, it’s kind of a bummer to have to go back and rethink another login.
I would imagine most of us now have a few different variants of our favorite handles that we like to drill down into. “Ok, Eddie is taken- how about my simple but more unique el73?” Once we “move on” from this, it’s kind of annoying to have to come back and rethink it. It’s nice to get the feedback right away.
Although- I agree with Rein- it would be nice if yo did not need to click to check.
Ripul’s overall point is nice- although for sites where anonymity is desired, why would someone want to make up two fields instead of just one?
I just think that for 90% of web-apps out here, you should be able to log in directly with just a password and the system should require it to be sufficiently complex and unique.
November 23rd, 2005 at 9:53 am
Serendipitous post for me, Jared. Thanks. I am in the process of redesigning an account creation page and my team has been pondering ideas on how to ensure a unique id is created. We thought of this approach as well but had not seen it before. Other sites always require a server hit/submit button click to validate.
This solution also doesn’t alleviate the possibility of multiple failed attempts to create a unique id – which would be very frustrating. Not sure if AOL still does this, but when you signed up for their services and entered a userid that was taken, they would provide unique IDs similar to the one you entered. e.g. if you tried psmith and it was taken, they would suggest psmith8982 instead.
Thoughts on that approach?
November 23rd, 2005 at 11:23 am
Michael, you forget that a password field will always be cleared on a postback. So even if you try to keep everything else in the same state, the password will still have to be re-entered if a full postback is done.
In usability tests I have done on this matter, I found that someone will enter in their info (accidentally choosing a taken ID), click submit, see that there is an error of a taken ID, fill in a new ID and click submit again. But, since it was a postback, their password field was cleared, so now they get a new error saying they need to enter a password. This ended up being confusing for them, often with a comment of, “But I thought I entered it already!”
November 23rd, 2005 at 1:01 pm
There’s no need for the check button, really. Check AJAX techonology, and if Javascript is enabled, your form can provide immediate feedback upon the onchange event of the particular field. Of course, if Javascript is not enabled, then you’ll need the extra button & click.
November 23rd, 2005 at 3:23 pm
Thanks Dylan. That’s an excellent illustration on why the UI is brain-dead. Are you also suggesting that current technology can’t fix this? The web has been around for over 10 years. Why is this still a problem? Why is the solution to supply a Check button, adding work for the user? I’m sorry, but frankly it pisses me off that we’re still dealing with UIs that would be an embarrassment for an app written in the 1980s.
November 23rd, 2005 at 4:18 pm
I think it’s simply a byproduct of working in a stateless environment like HTTP. When you work on a regular desktop app, you’re working in a stateful environment where auto-lookups and fields holding their state are trivial matters. This is why I think there has been such an explosion of hype/interest in AJAX. It finally gives something resembling a stateful UI to HTTP applications, which as I said, is stateless.
I totally feel your frustration on this still being a problem after ten years. And why AJAX only took off after someone came up with a nifty acronym is another discussion unto itself. (I mean, it’s been around since 1999 or so!)
November 27th, 2005 at 5:51 pm
Scott LePera has a similar example in his blog:
http://jszen.blogspot.com/2005/10/kickass-form-assistance.html
January 2nd, 2006 at 8:49 am
The two buttons could be combined into just one.
When the user clicks the submit button, the AJAX function checks if the username is already in use, if false, the form is submitted. If true, the form is not submitted and the user is asked to enter another username.