Okay, so maybe I’m being a bit melodramatic or maybe I’m just a bit stressed out. I had previously talked about how website purchase forms that require you to enter a credit card number in a specific format (e.g., no spaces) were poorly designed since most people don’t deal with large groups of numbers very well. Furthermore, it’s trivial to format the number server-side, so why require the user to? Well, today, I ran into a form that not only required you to enter all of the numbers without spaces, but also punished you if you did not.

A bit of background

I am a member of the IEEE. They’re a great organization, and I find some of their publications such as IEEE Spectrum to be fairly interesting. You also sort of need to be a member if you want to publish anything in the field (I did two summers of research while in university), and since I’m an Electrical Engineer, I feel that I need to be part of the largest organization dealing with the field.

So, when a renewal notice arrived in my mail recently, I didn’t hesitate to pay my dues to remain a member. (Well, actually, it sat on my desk for a week before I did anything, but my procrastination is another topic) I thought that renewal would be painless process; it started out great, because as soon as I logged into the site, there was a big button/link for renewing. Clicking it added a “Renewal” item to my cart.

Checkout, or, things take a turn for the worse

Clicking “Checkout”, I thought I’d just have to enter my CC number and a few details, and things would be done. After all, I’ve ordered a ton of stuff online and have never really had a problem. That was, until I encountered the payment form from hell. Just how bad was it? Well…

I enter my CC number in my usual fashion – groups of four digits, separated by spaces. I like to do this just so it’s easier to double check that I entered the correct numbers. I don’t really care if the server “requires” you to enter without spaces, since I usually just remove them myself before submitting. However, as soon as the credit card number field lost focus, after I tabbed to the next field, the form submitted!

After the page had reloaded, there was a warning in red text, “INCORRECT NUMBER OF DIGITS”, or something to that effect, pointing to the CC field. And, the field was empty. That’s right, it just blanked out the field without even giving me the faintest hint that it would. All my hard work of entering in a 16-digit number was gone, and I’d have to do it again. I didn’t even remember seeing an initial warning telling me that I couldn’t use spaces!

What really happened, of course, is that the form did not really submit. They had some messed up event handler tied to the blur event of the field which sent the value server-side, validated it by their stringent rules, and then loaded the page again if the entered number did not conform to their rules or if the planets did not perfectly align or something like that. That is just whack.

If you actually enter the number the way they want you to, no spaces, it still sends the value server-side, and the page still reloads – but now the credit card field displays not your full number, but just the “XXXX…” and the last four digits, typical of how most statements display it. Your CC number is then stored server-side in a session, I presume. Weird. Furthermore, the submit button of the form wasn’t actually a submit button, (of course…), but was instead a hyperlink with the href attribute set to javascript:someMethod().

Why this is bad

I shouldn’t have to explain this, but I will just because I feel like it. Firstly, as I mentioned before, it’s insane to require users to conform to the “no spaces in credit card numbers” rule when you can just process the number server-side to remove any spaces. But the IEEE form takes it a step further by not only requiring this format, but actively removing any data NOT entered in this manner. It should be a given that you never clear any fields in a form unless the user is given prior warning and confirms it. (This is also why “Reset” buttons should have some sort of confirmation against accidental clicks)

But to carry out all of this action right when the field loses focus is completely beyond me and probably where I lost it. This goes against everything “normal” in UI design. It disrupts your workflow, it changes the state without notification or warning and it pisses off users. A purchase form is probably the worst place to do this in, since you’re trying to facilitate payment from a potential customer.

But the idea that the user has to enter the data in one, very-specific way is just what peeved me off. Most people aren’t perfectionists, so why would you assume that they are when it comes to data-entry and then punish them when they fail to achieve that expectation?

Having strict data format standards for machine-to-machine transmissions is one thing. In human-computer interaction, it’s a whole different ball game, and one that whoever designed the form from hell, evidently doesn’t understand. I’m no usability expert, but I know junk when I see it.

Final words

Okay, so maybe I’m overreacting a bit, or a lot. Though this only wasted maybe five minutes of my time, I was bothered by it enough to write about it for a further ten minutes. You may think me stupid for that, but that’s just how I felt.