Input Fields v Multiple Choice

I'm looking into starting a local charity and so as part of my research, I came across 'Stayexempt.org', an IRS sponsored site that talks about how a charity can retain its tax-exempt status. After a very cheesy, yet informative, series of instructions, there is a quiz.

Take note that the answer field is simply an input form field. You can type anything in there. I happened to type 'Duck' for my answer to make this point.
As expected, my answer was wrong. It should have been 'substantial.' What if I had put in 'substntial' (missing the first 'a'?). The answer would still be wrong.


And that is because there is no constraint on what the input might be. A multiple choice answer would have been much better, allowing the user to at least have a clue as to what the answer might be, and then not getting frustrated (if you can get frustrated with such a simple game) by a simple typo.

But wait, you say, "Maybe the IRS wants to demonstrate that you need to know the answer by heart? And no hints allowed, other than through the question." I get the point. I think it's a stretch in any web-interface situation like this, but I get it. In that case, if it is that vital, the answer system should accommodate common spelling errors. Google does it all the time; as do auto-spell checkers in word processing apps.

In the case of this app, it wouldn't be too hard; there are only a few options total in the entire game and a quick check wouldn't detract from the interface anymore (than the interface detracts from itself; sorry, IRS web dev folks; you obviously weren't given a very big budget).

So recognize the errors that a human being might incur through mis-typing. Put constraints on options in order to reduce the amount of frustration your user will encounter because of simple spelling errors and the like.

Hidden Fields

This is a shot from PayPal's payment site. I was buying some tickets for an event and as I was attempting to tab through the fields, I realized I was unable to type for some reason. Notice the dotted lines above and below Address line 1. Those show up on the website, and at a guess, they highlight a hidden field. I had to tab again in order to get to the proper field, where things functioned properly.

This is more of an exercise in testing and quality assurance than it is a specific user interface issues. Obviously, this is not how the page should behave, but somehow PayPal's web team let it slide by and no one checked it. How does that happen, and more importantly, do they apply the same level of diligence to the rest of their site, say, when they're taking your credit card info?

(For the record, the problem didn't stop me from making my purchase; I use PayPal and trust them as well as any other reputable company (that is, with a grain salt). But when little things like this occur, it does make me question what else is or is not going on behind the scenes.)

Field Formatting Forgiveness

Here, while I was filling out a form a for a local college, I encountered this little problem. After having typed in my phone number (which is in a valid format for a US phone number), I got the error show above. "Please enter a valid US phone number XXX-XXX-XXXX".

This is an example of a failure to be forgiving to your users; asking them to guess (because there was no indication of the format before I entered the numbers) what the proper format is annoying. Other valid formats include: (XXX) XXX-XXX or XXX.XXX.XXX or even XXX/XXX-XXX.

Instead of making the user fill in a field to fit your expectations, allow them instead to put in any format they desire; check for the 10 digits needed to be a valid phone number and then have the system reformat. That way, you're not annoying your user and you can still get consistency in your data (and it's under your control).