Usable XMLHttpRequest in Practice

Two weeks ago I highlighted the most important usability issues with XMLHttpRequest. This week we are going a step closer to see how you can mix the two - including a practical example, just for the fun of it.

Normal forms are usable by default

You can clearly see where the input fields are, so you know what you can edit, and what you cannot.
It is forgiving. You can explore all you want because nothing is changed until you submit the data.
It lets you decide when to "save".
It confirms any action taken, since you are redirected to a different page upon completion.

XMLHttpRequest forms may not be usable

One of the great benefits of XMLHttpRequest is that you can use it to make complex WYSIWYG. This has previously been hard to do on the web. Take a "build your car" feature that you often find on sites of car manufacturers. This could be greatly enhanced by the use of XMLHttpRequest. When the buyer selects something, you can connect to the database, recalculate prices, change the image or change other options - without reloading the page, on the fly.

This is great! But... remember the 4 points above. XMLHttpRequest do not support any of them by default, if you want to keep your web application usable - you have to reinvent them.

Example: XMLHttpRequest Business Card Creator

Let's look at what we can do to turn an otherwise user-hostile XMLHttpRequest application - into a usable one... To do this we could take a Business Card Creator. It's an application that allows people to create their business cards in WYSIWYG and store it automatically for later use.

Link: XMLHttpRequest Business Card Creator »

Tested in IE6 and Firefox. If it should fail to work in other browsers please do not tell anyone... :)

What can I edit?

This one is hard. Keeping something WYSIWYG and visualizing input fields are often two mutually exclusive things - as with this case.

In this case I had to make a sacrifice. I did not want large boxes (with borders) in the middle of my business card. So instead I did 3 things:

Kept it simple.
Clicking on non-editable fields (like the "phone" text) takes you to the nearest field you can edit. (this is simple if you use label tags).
When you mouse-over an editable field, it changes appearance.

MouseOver used to visualize fields

What is the active element?

In a WYSIWYG application it is preferable to make the active element visible. There are two reasons for this:

It confirms that the element you clicked on is also editable
It visualizes if you should accidentally change the focus.

Active field highlighted

Adding Forgiveness?

Forgiveness is very important in any interface. The greatest benefit of adding forgiveness is self-confidence for people using it. This example includes 3 different ways to add forgiveness:

Nothing is final until you press "print", so you can edit all you want. I could have printed it directly (the data is already saved), but that would destroy any confidence using the application.
Hitting "Escape" resets the field to its original value.
As with "what you can edit?" - Clicking on non-editable fields (like the "phone" text) takes you to the nearest field you can edit. This also helps with forgiveness in the design.

Click on a non-editable field and it moves focus to one that you can edit

Is it valid?

XMLHttpRequest offers the possibility of server-side validation, and although I did not use it in this example, I did bring the validation information right up to the fields.

Validation placed with the active field

Other sites often do this with an alert box, which is far away from the actual field (locus of attention). In poorer examples it's done when you submit the data, which causes you to loose focus completely.

This allows you to keep focus.

When is it saved?

One thing I found from other tests is that people do not believe something is saved if it happens too quickly... Yes, you did read that right!

The first application I made using XMLHttpRequest saved the data whenever a field lost focus. It only took a 100th of a second. Most astoundingly none really believed that it was saved. They constantly reloaded the page to "make sure" - taking away all the benefits of using XMLHttpRequest.

So, we need to fake it - making the save process seem longer than it really is. In this example a delay is added + a visual indicator. It works much better and also functions as a confirmation that the application really did save your information.

A fading delay + indicator makes the impression that work has been made

This brings up another issue. We do not want it to do all this if the information hasn't been changed. So, if the information is the same, it just looses focus on exit - without going trough all the trouble saving nothing.

Note: In other applications I tried with displaying "Saved" in the status bar, but found that few ever look there.

In total we got a usable web form, that benefit from the use of XMLHttpRequest (but it can be used in many other situations as well).