"Your username can only contain letters, numbers and must not start with a number, please correct it and submit again."
As software users, we've all ran into these annoying error messages before on bossy web forms that want to tell you exactly what information you're allowed to enter.
Programmers and software engineers are very detailed-oriented, precise people. Computers are pretty stupid; if they're not told exactly what they should do and how they should behave they become confused. Good programmers are good at telling computers exactly what they should do and precisely how they do it.
Unfortunately for programmers, end users of their products are human beings and don't take kindly to the same sort of "precision bossing around" that computers thrive on.
Along these lines, I'd like to share with you an issue from a support email a frustrated Pay4Bugs Tester that came to my attention. The tester emailed Pay4Bugs support after his bug report was rejected as not being a bug. Typically, we don't address support emails regarding bug client bug decisions, but in this case, it was a bug submitted to our own product.
The reported "bug" filed by the tester was regarding a phone number field on a customer sign up form that accepted characters besides just numbers.
His bug report was rejected as not being considered a bug by the developer with the following reasoning:
"Reasoning: That is by design. Many countries use letters in their numbers. (eg. (800)-ABCDEF ). If the user enters garbage and we can't reach them their order won't be approved."
The tester, apparently frustrated by this line of reasoning wrote Pay4Bugs support the following message:
"If this is the kind of logic you use to write a website where brackets, commas, semicolons can be put in a phone number and its not an error on your behalf--your [sic] why have you put it up for testing?"
We all know where he's coming from. At some point in learning to become a programmer or a software testing engineer, etc, someone told him that a programmer should validate user input.
This school of thought leads programmers to design phone number fields that would reject "(212) 555-1212", "+1(212) 555-1212" "1-212-555-1212" and "(800)4mybrand" all of which are ways people write phone numbers in various parts of the world. A potential new customer using such a form might end remaining just that...a potential customer, not an actual one...because of overly picky data validation.
Users don't really care that some programmer thinks that a phone number should just have digits in it. Users only care about achieving their own goals with the least amount of cost/effort possible.
Problems like this occur because some programmers are either unable or unwilling to think about how users will use their product. They do not consider whether or not the cost of implementing data validation code and the hassle users will endure as they spend time complying with it is worth.
In the case above, the phone numbers are for one time use by humans who need to contact the customer for orders flagged as high risk. I would rather risk being unable to read information because a customer entered nonsense, than risk frustrating and scaring away a potential customer. In the case above, there's absolutely nothing to gain from additional data validation on the phone number...unless you count a more frustrating user experience and possible lost customers a gain.
What's your take on bossy, over-the-top data validation? Horror stories? Is it ever warranted? Share your thoughts in the comments.