Be liberal in what you accept, and conservative in what you send.
- Postel’s Prescription

Previous posts here have discussed reducing the burden of data entry on your application’s users by cutting down on the number of items that they are required to provide and, even if something is required, allowing it to remain incomplete for as long as possible, only enforcing that “required” status when the time comes that it is actually needed.

But what about the values that are entered, whether required or not?

The next step in minimizing the burden placed upon your users is to “be liberal in what you accept”. Do not impose validation rules which must be satisfied unless they are unavoidable. If you really must require them, make sure that the rules themselves are complete and correct.

Don’t Validate Formatting

The biggest, most common, and most annoying case of pointless validation rules are those which impose restrictions on how the user must format his entry. Any programming language worth its salt can effortlessly remove spaces from a string or insert a space after every fourth digit, so there is absolutely no good reason for credit card validations to care whether you enter the card number as “1234 5678 9012 3456″ or as “1234567890123456″, or even “12 3 45678901 234 56″.

Phone numbers can trip you up here, too. Does the program want them entered as (555)555-1212 or 555-555-1212 or +15555551212 or what? The correct answer, again, is that it should accept any of these formats (and more), which is easily implemented by simply removing any non-numeric characters and then adding or removing a leading “1″, depending on whether you want the country code in your database. This will also accommodate international phone numbers, which may have their digits grouped in patterns you don’t expect.

As long as it’s the right set of digits, let the user group them however he wants to.

Remember The Rest Of The World

When I moved from the US to Sweden, I paid my bank a visit to change my address with them. It went reasonably well and their system was smart enough to recognize that, since my new address was outside the US, the “state” could be left blank.

But it still required a ZIP code. Beyond that, it required the ZIP code to be formatted as a string of five digits with no intervening characters. While it does just so happen that my Swedish postal code is 5 digits, they’re grouped “226 47″. Also, the postal code goes before the city here, so we ended up having to enter the city as “226 47 Lund”, with a ZIP code of “00000″. This is obviously incorrect, but it was the only option for satisfying the US-centric validation rules.

Trust the User

Speaking of ZIP codes, ZIP code-to-city databases are pretty nice. They can be great for letting users enter their ZIP code and then automatically filling in a default city for them.

Note the word “default“. The last US city I lived in was Eagan, MN, ZIP code 55122. About half the ZIP code databases out there correctly list 55122 as Eagan. The other half list it as St. Paul, which is a good 10 miles north of Eagan. I knew I lived in Eagan, and the post office knew I lived in Eagan, but several websites insisted I was in St. Paul and provided no way for me to correct their mistake.

Looking up data instead of making the user enter it is good, but your database will be wrong sometimes. Allow the user to correct the lookup results when this happens.

 
I do have a bit more to say on ways that data validation can go wrong, but that’s a topic for another post. Until next time, what issues have you run into where too-strict or too-lax data validation has caused you problems?

I’m often surprised at how readily people will forget this.

In late January, I ran across a question on LinkedIn which related to a website the asker had developed which was 100% AJAX-driven. The site itself looked nice enough, but it was a disaster technically. Unless JavaScript was enabled, it didn’t even display its front-page content, just a (non-functional) navigation bar.

With JavaScript on, the content did appear, but it turned out to be nothing more than a standard six-page site which could have been done statically with plain HTML pages and regular links to navigate among them without using JavaScript at all. The only thing lost would have been having the old page’s content fade out, then the new page fade in, when you navigate from one page to another.

Yes, the fade in/out is a nice effect. Yes, it looks cool. And, yes, AJAX is a very buzzwordy “Web 2.0″ technology. But it was used all wrong on this site. It added nothing to the functionality or usability of the site, at the cost of making it inaccessible to a substantial segment of potential users¹. If you’re into SEO, this choice of technology also killed that by making the site essentially invisible to search engines.

I’m sure you’ve also seen sites which use Flash, SilverLight, or another “more interactive” technology in a way which does nothing beyond what traditional HTML can provide and makes no use of interactivity at all. Once again, such designs limit the ability of users to access the site and its content, shut out search engines from indexing the site, and add no actual value.

This is not to say that AJAX or Flash or SilverLight or whatever are intrinsically evil, or even suspect, but rather that you need to know what you’re trying to accomplish with your site or software and then choose appropriate technology - and an appropriate use of that technology - to support that goal. Just using technology for its own sake or because it’s the hottest thing at the moment will, in 99% of cases, do nothing to support the software’s purpose and is likely to detract from it.

What’s the most useless (mis-)use of technology you’ve seen lately?

While that may be a good negative reason (”there’s no reason not to”), there are also positive reasons for allowing this:

It makes your users’ lives easier.

Are you perfectly organized at all times? I know I’m not.

Requiring that saved data must be complete and valid (or at least valid-looking) at all times demands perfect organization from your users. It makes them collect all of the information you want up front and have it all available at the same time when they enter it. Removing that requirement means that they can enter as much as they know right now, then find the rest and come back later to finish.

It provides a record of user actions which were started, but not completed.

Suppose you have an online store for which users go through a series of three pages in the course of placing an order. Do you persistently store the partial data at each stage of the process or do you just keep it in the active session and write it all to the database at once when the final form is complete?

If you’re smart, you’ll make a permanent record of it at each stage. This information about what items a user started the purchase process for, but didn’t actually buy, can provide valuable insight into buying habits. If you’re using a recommendation engine (”people who bought X also liked Y”), then information about what users almost bought is almost as valuable as information about what they actually bought.

More importantly, though, this incomplete transaction data can highlight issues with your site’s effectiveness. If 90% of your users are starting a transaction, but abandoning it after the second step, then perhaps you should take a hard look at the third step (and, while you’re at it, make sure that the server is completing step two in a timely fashion) to determine why they’re not continuing at that point.

Incomplete or invalid data can show what mistakes your users are making.

Users will make mistakes and they will submit invalid data. That’s as inevitable as death and taxes.

Most software ignores invalid submissions, beyond throwing it back at the user along with an error message.

If yours saves it anyhow, though, then these invalid submissions give you a window into your users’ experience that will show you what mistakes they’re making. Once you know what mistakes are being made, you can attempt to determine the cause of the mistakes and make it easier for the users to get it right the first time instead of just scolding them for doing it wrong.

Like the data I’ve been talking about, I’m sure that this post is also incomplete. What other benefits or drawbacks are there to saving partial or incorrect data instead of rejecting it?

This is the wrong approach. As application designers and developers, we should be minimizing the effort we require from our users, not adding to it.

I recently encountered a blog post on Rethinking the Comment Form which, among other things, suggested that there’s no reason for a blog comment form to require - or even request, really - an email address unless the user requests to be notified of additional comments. This is a step in the right direction and provides my first principle for minimizing requirements:

If you will never use the information, don’t request it.

In most cases, that can be expanded slightly to “if you will never use the information for the user’s benefit“. If your only use for the information is to sell it to spammers or “marketing partners”, that doesn’t count.

The second principle expands slightly on the first:

If you won’t use the information immediately, don’t require it.

The first was pretty conventional, at least if you’re not talking to marketers. The second is a bit bigger of a step. It means that, if you’re not going to be sending someone postal mail today, then it’s perfectly OK for them to enter an address with no ZIP code. Or a phone number with no area code.

Yes, yes, I know… “What about data integrity?!?”

Which is a good question. What about data integrity? If you’re not going to use the information yet, then why does it matter? Sure, you definitely do need to get that ZIP code before sending them a letter, but, until you have a letter to send? So what if you don’t have it?

This then leads to:

Even if you do need the information, accept its omission.

Let the user leave it blank. Really. You can remind them each time they log in about important information that needs to be completed, but there is no excuse for refusing to let users enter partial information now and then come back and finish it up later.

The only potential exceptions are a username and either a password or an email address (so you can send them a password). This is sufficient to allow them to return and provide whatever other information may be needed at a later time.

Of course, if you use the email address as their username, then that leaves exactly one piece of required information. You can’t get much more minimal than that.

Do you have any other suggestions for good ways to minimize the load on your users of providing information?