I normally begin each post with an anecdote explaining my motivation behind writing. In this case I was asked to add code to a user profile page to validate a zip code. The request was that I not only check the length but that I compare the zip code against a registry of all possible zip codes to see if that particular zip code exists. My response was simply “Why are we bothering?” After all, I thought, what’s next? Submit their address to Google maps to make sure it exists? Check their name against MVA or voting records to make sure they exist?
Validation is the act of verifying that data is constrained to certain rules. The rule could simply be required input, a certain format such as date, or a complex system of logic that combines constraints on several input fields. When a user submits data, a certain amount of validation is helpful. We’ve all been saved at least once by having to type in our passwords twice when they don’t match.
The question I pose is this: is there a such thing as too much validation? And if so, when does that occur?
To answer that question, we have to take a step back and look at what’s happening. Data submission of any kind is essentially a conversation between two parties: the submitter provides information and the receiver provides feedback. This could be through a web form, a paper form, or an interview. An interview requires the most time and effort by the interviewing party but offers the highest degree of validation since they can converse freely. Paper forms remove the interviewer and thus streamline the process, but provide no validation. Invalid data is submitted, caught while being processed, and the form must be fixed or returned for resubmission. Valid data must still be processed and stored by an administrator of some sort. This system has worked fine for centuries and still does, but now we have the web, which brings me full circle.
Web forms can provide instant feedback and force a user to fix errors through validation. This completely cuts out the interviewer and the administrator. It also saves time for the user during entry and shortens the processing time, which benefits everyone. The only cost to the enterprise is that they now need programmers, database administrators and the technical baggage to keep the system running. Still, this is generally a fraction of the cost for the provided return.
Validation is useful for streamlining a conversation for both parties. But once validation starts to hinder the conversation, it’s usefulness declines.
The most obvious occurrence is when validation throws false complaints. This can occur when the rules change but the code logic becomes out of date. Some examples might be the 9 digit zip code or new email formats (I once forgot to allow for European email formats). These are the simple fixes. The gray area concerns the things I mentioned at the beginning.
The issue is relevant to me not only because I code lots of forms with massive amounts of validation checks, but also because I am currently co-authoring a jQuery plugin to precede user actions with a confirmation dialog to force the user to verify their intent before committing the action. Like validation, a confirmation prompt can protect users from making mistakes, but it could also become a nuisance if it is overused. Since this is a plugin, it will be up to the consumers to decide when and how often to implement it, but to make it as useful as possible, we want the default behavior to mimic the majority of use cases.
And determining default behavior requires a bit of prediction at this phase. Hopefully, once we go live, we will get some useful feedback from the community and see how close our predictions are.