Usability tips for visualizing Ajax requests

November 1, 2009

The usage of Ajax in web applications and web sites is rapidly increasing. If not handled properly Ajax fucntionalities can break users’ expectations and conventions. This is why it is important to help users easily identify what is going on with the system and prevent them to make errors during Ajax operations.

Keep users informed

Ajax indicators are very important tools that help users to have an understanding of what is going on with the system and what are responses from the system. Indicators should be shown as soon as request starts and hidden when request ends. I’ve seen so many times that indicator is visible even when it was obvious that request is finished (or even worse, in some cases there were not any visual clue of what is going on).

Simple indicators

Simple Ajax indicators provide a strong visual clue that request is in progress. They can be shown as simple text or as an image, usually animated.

  • If it is in a text form, be sure to provide meaningful message, like “Sending email…”. Messages like “Waiting…” could confuse users. What am I waiting for? Is something wrong with the system?
  • If it is an animated image they are usually represented by rotating animation. This is one of the rare good usages (if not only) of animated gifs today

Loadinfo, my favorite choice when it comes to indicators, offers a plenty of animated gifs. Some of them are really fancy, like rotating hourglass.

Progress indicators

If an operation needs a longer time to execute you should use progress indicators. This type of indicators provide a real time information about the progress status, usually by showing how much time has passed and how much has left to the end of request. Progress indicator can also show a status message explaining what is happening at the moment.

Dropbox provides graphical status indicator as well as textual status messages. This is the efficient way to communicate the status of long operations.


Whatever option you choose, you have to make sure that indicator is clearly visible. Depending on their purpose, indicators can be placed inside the same context as the element that started a request or they can be shown in a single position for all request. Previous example shows the case where progress indicator is shown in the upload area.

Google Mail has centralized Ajax indicators in the top of the window that is revealed upon any Ajax request.

Which one to choose?

I think it’s the best to quote Jakob Nielsen’s article Response Times: The Three Important Limits. I wouldn’t have anything to add here:

  • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
  • 1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
  • 10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

Disable UI elements during Ajax request

While one Ajax request is in progress user can start another one which may bring about the risk of data damage. By double clicking the same button or by clicking on another users can even cause an application failure. But if that happens it’s not their fault.

This can be easily prevented by disabling UI elements during Ajax request. Depending on the case, you can disable a particular element or you can disable the entire user interface. UI elements should be disabled when Ajax request starts and enabled again when request ends. In some cases your user interface will change view after Ajax request so you won’t enable disabled elements again.


BuySellAds shows Ajax indicator in centralized area on the screen while the rest of the user interface is disabled. This behavior is consistent through the application.

Highlight updated area

When partially updating a page it is important to emphasize the outcome of Ajax request. The goal of this method is to draw users’ attention to updated area and enable them to easily confirm the update. This can be done by highlighting updated area for one second and then fade it away (you can even flash it once or twice). The usual color for highlighting updated area is pale yellow.

Basecamp highlights the updated area with yellow color.


To make Ajax functionality easy to understand, you have to provide the information about state of the system during a request and after the request is finished. Basically, when working with Ajax you should:

  • Use textual or animated Ajax indicators
  • If requests are long, use progress indicators
  • Disable UI elements during Ajax request to prevent potential errors
  • Highlight area updated by Ajax
  • And of course, you should always show status message indicating whether operation failed or suceeded

What is your experience with visualizing Ajax requests? Is there any specific method you prefer?

* * *


  • Davide Espertini (November 2, 2009)

    Nice tip Janko!
    Into the company where I work we use this technique from some time

  • Malte Hansen (November 2, 2009)

    Stackoverflow’s method is quite worth mentioning in my opinion.
    When some icon is clicked, it changes from "idle" state directly to the "finished" state, jumping elegantly over the "loading" state.

    If the action fails, a error message is shown, and the state of the element goes back to idle.

    That gives the illusion of a really really quick interface, and i really like it :)
    Ofc, that way of doing things can’t be used everywhere.

  • Marco (November 2, 2009)

    Hands down to you Janko – you really can wear your "UX Designer" title with pride. This is one great article to read and compares some great uses of visualizing AJAX requests.

    Keep up the great work!

  • Steffen Jørgensen (November 2, 2009)

    As always a very nice and well written blog post from you Janko. You raise some good points and point out the key factors in creating a good ajax interface for the users :-)


  • Mohamadreza (November 2, 2009)

    another great job done by Janko.
    very well written in a simple way. very useful

  • Arvii (November 2, 2009)

    Thanks for this great article!

  • Simon Hamp (November 2, 2009)

    Nice article Janko. A good roundup, and some points I will definitely be using.

    Disabling UI elements is a good idea if you don’t want to allow someone to perform the same action lots of times until the current request is finished (disabling the Submit button perhaps).

    However, to do this (as many apps do) across the whole interface seems opposed to the purpose of AJAX techniques. Isn’t the point of AJAX to be [i]asynchronous[/i], so that you could send work away [i]while[/i] you work on something else?

    If you’re changing an entire view using AJAX shouldn’t you really be requesting a new resource?

  • Greg (November 2, 2009)

    Very nice article. When designing interactive websites we need to clearly communicate with our users when we are doing something so that they don’t wonder. Giving that visual feedback is highly important.

  • Malte Hansen (November 2, 2009)

    @Simon Hamp: Exactly, it kinda ruins the point about asyncronus actions if you make people wait in another way, its still more sleek and more RIA like, than a normal web application..

    Oh yeah and i totally forgot, Janko, really nice article :)
    Keep up the good work!

  • Janko (November 2, 2009)

    Thanks everyone for the comments!

    Malte: interesting solution, I haven’t checked that.

    Simon, Malte: Good point. I think it depends on the case. You might want to disable other UI elements that could interfere with the result of a running request or that depends on it. Although Ajax [i]is[/i] asynchronous, there are cases when you need partial rendering combined with disabling several UI elements (and where new requests would be overhead). So, sometimes I would rather go with it, making it synchronous to users.

  • Medbranz (November 2, 2009)

    Disabling UX while loading is only needed on ver important tasks, for example, if you have a blog that loads post content and comments through ajax, you should disable it, since if user posts a comment the result will be shown on the next entry, however for tiny tasks like voting you shold leave UX unlocked. IMHO.

    Another thing I have found after some months of experience, placing loader at the same position for every ajax request is not a good idea, especally for users who have a wide screen, just imagine that you are viewing a left upper corner and indicator appears o n the right one (like picasa loading indicator), sometimes it will stay unnoticed by user.

    Another thing I have found very sensate is to use loader ONLY for loading, do not output any error messages there, use modal windows instead. The goal is to achieve user experience with a minimum of eye movements and let user concentrate only at the specific area of your web app.

    Facebook loading image is the best example of useability IMHO

    Regards, Mike

  • Guillermo Chavez [chepe263] (November 6, 2009)

    Nice entry, it’s gonna be really usefull for my project: Quitter ultraBeta

  • Milan Stosic (November 18, 2009)

    Hi Janko and the rest of you guys who added a comment! An hour ago I found this blog and I’m reading it’s articles for couple of hours :)

    My friends and I are in the proces of making RIA aplication (kind of a busines aplication) and use some of this elements Janko mentioned, which are very useful and interesting for the user (it looks like aplication is "comunicating" with the end user).

    I’m interested in opinion, based on expirience, which solution is better:
    1. to add a little animation (for example 3 animation dots) to every clickable link (Add, Edit, Delete, Suspend, etc), or
    2. to choose one place for some "global animation" and "fire" animation every time link is pressed (like Gmail uses in header)

    I know that using this elements depends of a type of aplication but I’m interested if someone has expirience and what are the conclusions?

  • Web Design Talk (November 28, 2009)

    Nice article.

    Have always thought basecamp did it ajax request feedback very well. So well in fact I use their method a fair bit in my projects :)

  • Imran (December 1, 2009)

    Thanks Janko ..for sharing this artical.