Date() with destiny

Computers are dumb. Humans are smart. So it makes sense for computers to do as much of the smart part as possible and leave the humans to cope with what the computers can’t do.

Sometimes that is most obvious in little things, such as entering information in ways which any human could make immediate sense of, but which brings badly designed software to its knees. Enter a date, a credit card number, a post code. All simple things, all things which have been part of web forms since the dawn of internet time, and all of them badly done with remarkable frequency.

I had a rant about that several years ago (which opened with a rather smug passage about how I had avoided that particular trap on the one occasion on my life when I have had to put any of this into practice). As I observed then,

There are things humans are good at, and other things which computers are good at. Putting simple data elements into standard formats is, without a shadow of doubt, something for computers, not humans

In the four years since then, depressingly little has changed. Just yesterday, a site asked me for my credit card expiry date, with a lovely wide field to type into. “03/14″ I typed (or something on those lines) and carried on to make the payment. “Your payment card has been declined” was the stern warning in red at the top of the next screen. By which it turned out they meant that the card expiry field, though occupying half the width of the screen, was limited to four characters. So my entry had been truncated to “03/1″. It then stripped out the “/” and submitted “031″ to the card processor. What it had wanted – and the only thing it would accept – was “0314″. The most trivial of cleaning up would have got to that from what I gave them, and they clearly have the code to strip out “/”; it’s just not deployed in a way which gets the balance right between humans and computers. And if they weren’t up to doing that, just making the data entry field four characters wide would have given me enough of a clue.

So it’s worth celebrating the people and sites who take the trouble to get this right.

One of the many reasons why I like Matthew Somerville’s Train Times site, apart from being the best way I know of discovering where trains are supposed to be and where they actually are, is the simple elegance of the data entry – throw pretty much anything at the date field shown on the right, and it will cope.

Now, from another corner of mySociety, comes a brilliant post by Dave on why all this matters and how to understand the design problem which actually needs to be solved. It isn’t really about the near-infinite set of ways of referring to dates and times, it’s about recognising that some forms of complexity are best moved away from users (who get frustrated and irritated) to computers (which don’t). Doing that successfully entails thinking about what users want to do even (perhaps especially) when they have to do something as simple and obvious as typing in a date:

The general rule is: even for something as simple as this little web form, if it’s possible to create an interface that matches the way that a user thinks about the world, then it will be less confusing for them than one that does not. Usually this means the system has to be a bit more complicated to program, in order to convert what the user types to what the computer needs.

Once you start looking for them, there are lots of examples of small details displaying thought, wit and imagination (as well as occasional tweeness) – and a site dedicated to collecting and displaying them.

So let the last word go to Dave, from another of his posts:

If you want to build sites that people use, you should be as clever as a magician, and the secret to that is often keeping it simple — deceptively simple — on the outside.

Original post