natalian archives 2008 07 08

Error detection in Web forms

4 comments

Can you quickly spot the typo between a form field value ”+2731284325” and ”+2731294325”?

nocue

Now what if the form field had a cue? For example a colour cue on the border colour:

withcue

16 Colours provide instant visual feedback that there is a difference between the two form fields. That’s a 4 bit Web form error detection using md5.

When you enter the same data again and again in form fields like your:
* username
* email
* birth date
* credit card number

Each one of these “datums” could be associated with a cue. So you would subconsciously over time recognise you entered your details correctly.

This cue idea is useful for accessibility. People who are prone to making typos could use a cue (an additional band/channel) to quickly find mistakes.

I initially thought of form error detection, checksums & cues when I accidentally mistyped a number from a business card three times into my mobile. If that business card had a “checksum”, with the number (for e.g.) underlined with the according md5 colour chances are I would have entered that number in correctly first time into my addressbook. Saved the cost of the misdirected texts and saved an awful lot of time.

So a cue is especially applicable in mobile environs. Anywhere I imagine were copy&paste is not easy to do.

Of course a cue does not have to be a colour cue checksum. A ‘cue’ could be some other easily recognisable symbol like Wingdings, different CSS styling like border styles, Unicode symbols, playing card symbols and so on.

So I encourage you to please try my initial implementation called “Get a cue” with Web form input elements. For the developers amongst you, please look at the BSD licensed code. Feedback and patches are very welcome.

Hopefully a defacto ‘cue’ error detection algorithm rises to the top that will help everyone improve their input quality.

get a cue

Comments

83.101.7.146

sounds like lotus notes password field ;) http://homepage.mac.com/bradster/iarchitect/lotus.htm#LOTUS12

but I like it, I’m just not sure how user will understand it I was quite confuse at first. And I’m not sure one need a full fledged md5 implementation for that but I might have missed something.

Comment by antoine —

90.152.10.135

Hey Antoine,

You are quite right. It doesn’t have to be md5, it can be much simpler like just a sum. I hope to collect several “bookmarklets” and see which one is best.

Try write one. ;)

Comment by hendry —

62.49.117.34

It’s a good idea, I just don’t see how it can ever be practical. In your example you have a 10 digit number, I don’t know the possible combinations, but it must be huge, especially as you are using this for any character, and you need a different visual clue for any combination. Currently in your example you use, what, 16 colours? So 1 in 16 errors will go unnoticed (1, 12 and 13 all show cyan), not only will they go unnoticed, but worse the user will think that they have it right. You say that you can use any visual clue, you are not limited to colours, but I do not see how you can keep it simple enough and at the same time cover enough possible errors.
Comment by Jamie Kitson —

90.152.10.135

Of course collisions with 4 bit checksums are very possible.

md5sum is a 128 bit checksum and it’s very hard to get a collision. “get a cue” uses just the first 4 bits of md5sum.

there must be some intersection where this checksum catches most errors. ‘Cue’ is not about being “fool proof” (thanks Jamie), or providing secure authentication.

I think you could fairly compactly represent 128bit with CSS, colours & Unicode. Though I think a much lower bit size, like 10bit can suffice for small input fields commonly found in Web forms.

Comment by hendry —

Add a comment

Tags: