Examples:

• Instant save - why force the user to click "submit", when you can save it directly


• Smart tags for the web


• Translating services - select a word and have it instantly translated (or defined)


• Smart shopping carts - add, remove or edit products instantly


• Server side validation - client side - validate forms, credit cards etc. as it is typed


• Intelligent sign-in systems


• ... and a lot of other useful things

But, there are a few essential issues to keep in mind:

Do not load entire pages

This one should be obvious. XMLHttpRequest strength lies in the ability to set or retrieve parts of a page. But by loading entire pages, you are preventing the normal flow of a site. You will no longer be able to bookmark a page, use the back button (in some cases), or know where you are by looking at the address bar (remember the problems we had with frames?)

One offender is Google Maps

Know the difference between a web application and a website

The difference between the two has been a source of discussion for a long time, but essentially a web application is a program made using web technology - a website is a bunch of pages linked together.

A web application would benefit by the use XMLHttpRequest, but a web application should also conform to program usability guidelines - like Apple's Human Interface Guidelines. A website should instead conform to website guidelines.

When mixing the two, you are heading into trouble. It is then no longer about technology - but about user expectations. Do your visitors expect to see an application or a bunch of pages? Do your visitors expect your website to update itself on the fly?

Do not break what the user is focusing on:

Take live-search, the web variation of Apple's Spotlight technology. This is a great use of XMLHttpRequest. But be careful not to break the users focus when using something like this.

Say, you want to search for the word "usability". Your primary locus of attention is then to write this word, and secondly it is to find article about it. If the site then starts a live search while you type, it will break what you are trying to do.

The first letter you type is "u", and the live-search will return all the results that contain "u" somewhere in the text. Now, you might get lucky - and the article might be at the top of the list, but most likely it will display a lot of irrelevant articles.

Not only did it stop your workflow, it also forces you to spend time looking at something you do not need. Writing "usability" takes 1.8 seconds for the average person, but since live-search interrupted this it now takes 4-10 seconds (using GOMS).

One solution is to add a delay, so that it will not do anything until you stop for a period of time (usually 0.6 seconds). This will allow you to complete the word, and get the benefit of XMLHttpRequest.

This is not just about live-search, but also about validating form fields etc.

Consider how to handle users that cannot use XMLHttpRequest

Objects like mobile phones, PDA's, screen readers and search engines cannot use XMLHttpRequest. If your site relies on this technology to function, it will become inaccessible.

Always consider how to handle these devices.

Do use it to eliminate confirmation pages

Confirmation pages are essentially a waste, and only exist because a normal web form has to submit the date in order to process it. XMLHttpRequest solves this, and enables you to confirm actions taken - directly where it happens.

Do not use it to eliminate acceptance

XMLHttpRequest can be used to e.g. save data directly, without the need to click submit or save. This might sound great, but it conflicts with one very important usability principle - "Forgiveness".

Forgiveness allows the user to explore your interface, add or edit information without actually changing anything. This is important when creating a web application, since most do not offer "Undo what-I-just-did".

Do not over-use it:

With every new approach, there is a normal tendency to over-use it. But don't. Always consider if XMLHttpRequest is relevant for the user. Is it just noise that breaks the users flow, or does it really accelerate their workflow.