I fill out a lot of forms during the day, some on existing sites and others as new internal forms that need review. When testing I have a habit of submitting forms with every error combination possible. I know there are automated tools for this but nothing beats seeing it from the users prospective. It is different to run a command line tool and get a number of fails and successes as it is to spend 2 minutes to fill in a bunch of fields and get some weird screen state, odd colors or wording that doesn’t make sense.
That is exactly what is happening above. I clearly filled out the form to my best understanding and still got an error.
Things I notice about this error:
There is something wrong with these three fields, but it doesn’t point out which one(s)
The wording of the error forces me to look up and then scan down to see where the field is
In my mind I did place the area code in the phone field
There is no explanation of the preferred format for the phone number
After understanding that my method isn’t working and they were not going to automatically transform my format to their preferred format I tried every phone number combination I could think of. In the end none of them worked. Being the curious person I am I ended up digging through their validation javascript and found this regular expression it was validating against:
Doing a little more investigation I found that it didn’t work at all. Try every combination you can think of at: http://j.mp/9sIWEn
Good error messages should include:
A summary at the top of the page of all the errors (long forms usually push the user back to the top of the page)
A highlight around each field with an error
An explanation with an example or clear direction where the visitor went wrong
Not be nit-picky about formatting, transform as much as possible automatically
In the end I brought this issue up to Groupon and they fixed it within an hour. The issue was not with their code, but on the survey vendor’s site. It got me thinking about the time and effort the user has gone through to get to this point and end up confronted with a road block. These small things have the potential to be a huge turn off for the average user. Command line tools may be great but nothing replaces what you can learn by testing things by hand.
A few weeks ago at the CaseV conference I was trying to get wifi in the Chicago Sheraton and unfortunately it was not free, they charge by the day. I fired up my laptop fully prepared to pay the $13.63 for a day’s worth of internet when I was presented with the form above.
A few things struck me as odd.
The first of course was the inability to read the labels for each field. This made it very difficult to use unless you highlight the entire page.
The second was the URL, it was a local address and the page was not protected by an SSL. No way was I going to put my credit card into a form without an SSL. Even a self signed certificate would have worked but CC information going over the air with potentially dozens of people able to intercept it does not sit well with me.
Last but not least the lack of instructions, terms or even description of what I was about to pay for really turned me off. Every customer asks “what is in it for me” before taking any action online. If the benefit doesn’t outweigh the cost the user will not continue. In this case it’s so unclear what the user is getting I would be surprised if anyone has filled out and submitted this form.
Continuous testing
I’m sure they didn’t design the form to be blank like this but whether it was the browser I was using or some change got moved to production that broke the form brings to light a very important lesson. Make sure you test all primary user paths every time a change goes in to production. It might sounds like a daunting task but something like this can easily happen if no one is watching. Just image how many people they are loosing because they didn’t take 10 minutes to test their form.
Even if you can use a mouse most of the time its easier to use a keyboard to fill out web forms. HTML has a nifty attribute called “tabindex” which allows the site creator to dictate how the user will navigate through the forms or links on the page.
The default tab order is usually enough, most forms are filled out linearly and browsers account for that. Sometimes developers get overzealous and add unnecessary tab orders, making the forms a nightmare to fill out.
I encountered one of these nightmare forms the other day. I went to write a letter to my representatives, and going through all the forms I eventually landed on this form. Long story short I started at the top and tabbed my way through it. But the fields led me in a crazy order.
Try to follow this maze
So what happened?
Half the fields had tabindex’s on them, while the other half did not, it made for a pretty unique experience. On Firefox atleast it loops through all the non-tabindexed fields first then hits the tabindexed fields. I used the Web Developer Toolbar to display the tabindex’s in yellow so you can see what I mean. Because these tab index’s were forced there was no way to move from the Prefix field to the First Name field without using a mouse.
The lesson here kids is to use only what you need. Don’t try to be user advanced technology when its not needed, you might just be frustrating more users than you help.
Using the right tabindex
For 99% of all web forms created it is a good idea just to ignore the tabindex attribute and let the order of the fields on the page handle how the user flows through the form. Especially if the form will have new fields or or change frequently, its just another thing to remember to do.
For those one in a million forms that you have to use tabindex my suggestion is to test, test and retest every time you change the form. It would be very easy to forget once and have a large group of frustrated users on your hands.
