On Validation: What's your first grade teacher's middle name?

I needed to order a copy of my birth certificate a few weeks ago. There's a company online called Vitalchek.com that handles it for you for all 50 US states. There's only one "small" problem i ran into ... the validation routines screwed up my application entirely, because the developer looked at validation from a narrow data-centric perspective. As a result, the validation routine did not allow me to enter my valid phone number or zip code, and my birth certificate was sent to a non-existent city in Maine. UPS couldn't call me either to try and figure out what went wrong, so they just sent the birth cert back to the sender.

The developer was stupid enough (sorry, but i can't find a kinder adjective) to prepend a 0 in front of my 4 digit zip code when i kept trying to follow the error handling's directive and "enter a VALID zip code". He also stripped the phone number of the useless extra digits and characters, reformatted it according to the US standard and UPS tried to call me at some phone number in Toronto, at ext. 7 no less.

I run into this all the time because i live in Europe. My valid zip code is 4 digits long. My valid phone number is 11 digits long including the country code. I should almost certainly include the "+" in front of it to indicate that it's a country code, which makes my valid phone number a string that is now 12 characters long. If i had an extension, it could easily be a string with something like 20 or so characters.

If i lived in Britain, my zip code would include letters and digits.

There is no reason whatsoever for a zip code or a phone number to be stored as numerics or validated as numerics (after maybe stripping them of certain characters) - because our applications have no reason to use them as numerics.

The bottom line is this. If a user doesn't want to fill in their correct zip code or phone number, "validating" those fields to numerics that are 5 and 10 digits long respectively, or in any way developer can dream up, will not force anyone to enter their valid data. A valid phone number for a particular person is one you can use to call them. A valid zip code for a particular person is the one the post office or a courier can use to deliver a package to them. A valid email address for a particular person is one that can gets to their inbox. There's no regex in the world that can prove an email to be valid for a given person, and that's what we're asking for when we ask someone to fill out an email field. Please give us an email address where we can contact you.

In this sense, the user is solely in control of whether the data they enter is valid or not. All our clever validation routines and regex's can only get in the way. In my case, they get in the way all the time.

What i find particularly annoying is when a developer decides that a field can be at the most 20 characters long for instance and i get a "Please enter a VALID address" message back when i need 25 or 30 charaters for the address. Again, i can't enter my valid address where the post office can find me.

The ONLY reason i see for validation is if the user's entry could cause the application to error, and there's no way for the programmer to work around that. Say for instance you allow your user to decide what tax rate they want to pay, carte blanc, and you know you have to multiply by that number to get their total. Then in my mind it's necessary to validate the taxRate as a numeric before you let the application try and multiply by it. But cases like this are rare.

And what about those fancy regexes used to validate email addresses? I've used them in the past, but i won't anymore, and i'll tell you why. I've never gone back and updated them in all the applications i've built in the past when new domains are released. Have you? And i've run into a bunch of validation routines that only validate for .com, .net, and .org. Personally, I'm fine there with my gmail.com address, but this certainly trips people up. Only a keen developer would suspect an outdated regex when they see a "Please enter a VALID email address" error message on a valid .biz email, and try a .com address instead. A normal user would have no clue what's going on.

And we as developers never find out about all these validation snafus that live within our own work. Our users just freak out and give up, like i do, when confronted by what seem to them to be senseless error messages and forms that don't let them enter their valid data.

I've run into validation brick walls like this where the validation routines would not allow me to enter my valid data on some very high profile sites, including macromedia.com, adobe.com, and symantec.com. And it's always either something in the address or the phone number. I run into it suprisingly often, more times than not, and am forced to enter invalid data in order to trick the form into working.

The Vitalchek developer was really clever tho'. I have to give him credit for ignoring my corrections after several attempts to warn me with the INVALID messages, and just correcting my data for me. As in "whoops, this user is too stupid to fill in valid information, so we'll just do it for him after 3 tries". He had me fooled into thinking the form accepted my corrections! So i didn't have a chance to employ any of my own tricks.

We actually keep a Skype number with a Los Angeles area code for just this purpose. Now if only Skype would offer virtual addresses for filling out forms on the internet that would be forwarded to your real address, we'd be all set.

In my mind, validation should be as user-centric as possible. I've run into way too many problems with web application that obviously took a database-centric approach toward validation to believe otherwise. If your app has to send an email to the user, then require the email address. If it doesn't, then don't. As much as possible, let the user decide what is valid and what isn't in regards to their data, and give them plenty of room in your fields to do that. Let them decide what they want to tell you about themselves, unless the functionality that the user is "contracting" with you to provide by filling out the form really requires that information.

And please, please, please, if you have to ask a secret question, let me as the user decide what it is! I honestly don't know the answer to most of the secret questions out there in those dropdowns!