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.
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.
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.
Tested in IE6 and Firefox. If it should fail to work in other browsers please do not tell anyone... :)
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:
In a WYSIWYG application it is preferable to make the active element visible. There are two reasons for this:
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:
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.
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.
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.
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).
Full access for... $9 per month
Full access for... $99 per year
Join 'The Weekly Update' to get an email every Friday afternoon with the latest from Baekdal + noteworthy articles from around the web.
What the shift in media is really all about.
Free for subscribers
$8.79 on Amazon
It is not about creating a shop in a tab. It is about turning communication into sale.
Free for subscribers
$7.58 on Amazon