Validation shouldn't be a Blunt Instrument

As developers, we know that data validation is important - the security of our systems and the integrity of our data is vitally dependent upon it. Unfortunately, security and integrity seems to be the limit to which most systems apply

This is visible in the breadth and variety of validation libraries that are available. From Microsoft alone, we have the System.Data.Annotations namespace, originally introduced in .NET 3.5 and greatly expanded in the forthcoming .NET 4.0; the Validation Application Block, part of the Enterprise library from the Patterns and Practices group; and ASP.NET Validation Controls. Looking further, on CodePlex we find a wide variety of projects targeting validation - a simple search for “validation” returns over 350 projects.

The problem with most, if not all, of these libraries is that they take a strictly Boolean approach to validation - your object is either valid, or not. While this is very convenient, both for us as developers and for the integrity of our systems, it doesn’t translate into a particularly good user experience. It’s almost as though we are building some kind of stentorian security guard or traffic light into our systems for the sole purpose of protecting our systems from our users.

Is this what we should be doing? The security and integrity of our systems is important - but do we need to sacrifice our user experience to achieve them?

I suggest that we can retain the security and integrity we need without impacting on the user experience , if we replace the security guard with a tour guide. Our systems need to do much more than simply protect themselves from bad information - they should actively guide our users into providing the information that isn’t just acceptable, but top quality.

Let’s replace simple Boolean validation with multi-valued Guidance. Instead of simple true (valid) and false (invalid) values, let’s use a range of values that provide richer semantics:

Error - a fatal problem that prevents further progress.

Warning - important information for users to consider

Hint - incidental information that users may find useful

Ok - no problems found.

Borrowing unashamedly from the compilers we developers use all the time, these Guidance values allow our systems to provide a rich user experience.

Errors can be used for the critical checks we’ve always had, ensuring that our systems remain secure with data integrity protected. Though,

Warnings allow us to caution our users when changes they make are legitimate, but have potentially wide ranging effect. For example, changing a part number in an inventory system is a pretty major update, as the part number is used as the business’ primary key to uniquely identify the part. We can’t exclude this kind of functionality from our system, for sometimes part numbers do change. What we can do is to provide a warning, cautioning the user of the severity of their actions, helping to forestall any accidental change, but without preventing necessary ones.

Hints give us the ability to point out useful extras to our users, helping them to find additional functionality or to gain more use from the system. One good example would be an online ordering system which could advise users “Enter your email address to receive daily updates on back ordered items”.

Of course, this improvement doesn’t come for free - there are additional rules to define and develop, and you’ll likely need to roll your own support framework.

But surely the effort is worth it.