Category: User Experience (UX)

Bad UX: Discarding Form Data

I promise I will add examples of good UX in the near future. But first, I want to address one of my biggest pet peeves online…

JobSite’s login form is guilty of a particular crime that several other web sites’ forms are guilty of. Basically, if you try to sign in to the site and just happen to get your email address or password wrong:

You’ve guessed it: both fields are empty when you’re told so. It makes sense for the password field, but my complaint is with the other, plain-text fields – in this case, the email address field.

Why is this a problem?

First of all, JobSite’s login form comes populated with your email address (if you’re a member already, or you accessed the site from a link in one of their newsletters), so it makes no sense to “forget” it if you get your password wrong.

Second, because the email address field is empty, a lot of time is wasted filling in the email address again. Worse still, the clearing of the field suggests that the email address was wrong – so a lot of time could be wasted in trying to guess the correct email address. Usually the problem is simply a small typo.
The only quick option then is to request a new password (or if security was an afterthought, retrieve the actual password) by guessing which email address was used to register.

Believe it or not, this doesn’t just happen with poorly conceived and poorly implemented login forms. I’ve seen the same thing happen with registration forms on various web sites (most of them fly-by-night), where one small omission will present you with a completely emptied form – meaning you’ll have to type in every single bit of information over. Unfortunately I can’t provide any examples off the top of my head.

The moral of the story: if you don’t want your web developers hunted down in cold blood, please think about how you implement your forms. If there’s an error with the data the user is submitting, try to keep as much of that information available the next time.

Bad UX: “Confirm” fields

It’s been a rough few weeks, and I’ve been incredibly uninspired to do anything as of late – but let’s get this bugbear out of the way first.

If you’ve used the Internet for any length of time recently, you’ve probably come across a form where you have to enter – and then confirm entry of – a new password.

In most cases that’s good practice: since you can’t see the contents of a password field (because all the characters are replaced with either asterisks or bullets), the confirm password field is a method of making sure the password you want to use is the right one.

However, some places on the Net take this concept way too far.
Continue reading Bad UX: “Confirm” fields