Ajax is shorthand for Asynchronous JavaScript and XML and refers to the technology behind single-page web applications or features that update dynamically without the need for a complete page reload. Even though the term “Ajax” has only been part of the web developer’s vernacular since early 2005, its correct use is one of the biggest issues of debate in the web community.
In the first of 2 articles on Ajax, we will focus on the usability issues developers must tackle if they decide to implement Ajax.
Introducing Ajax
Put simply, Ajax eliminates the need to reload an entire page’s content. Its functionality is illustrated in figure 1 of Jesse James Garrett’s seminal piece on the subject. Garrett coined the term “Ajax” when he wrote this piece in March 2005.
Ajax is a combination of the following technologies:
- XHTML/CSS
- A DOM accessed with a client-side scripting language such as Javascript
- The
XMLHttpRequestobject that exchanges data asynchronously with the web server.
Outside of its most obvious uses in single-page applications like Gmail or live.com, Ajax is also used in attempts to enhance traditional tasks like performing a search or filling out a form.
Live Search
Ajax Patterns explains the process of live search as “(while) the user refines their search query, the search function continuously shows all valid results.” Three very different implementations of a live search function can be seen on:
- Web designer Dunstan Orchard’s blog
- Orderedlist.com’s tutorial on creating a live search
- Google Suggest
Orchard’s blog loads the results below the search box. These can then be selected without any need for the “search” button. Orderedlist’s search works in a more traditional sense whereby results load below the search field once the user has selected the “search” button. Meanwhile, Google Suggest creates a drop down menu of possible search results while you type and allows the user to use the down key or a mouse action to select these.
Searching has been a ubiquitous part of computing for years and any change to the conventions that users are accustomed to may be problematic. Orchard’s live search goes against these conventions with its tab key behaviour. Pressing tab while in the search field will bring you into the newly loaded results. This is disorientating to users used to the traditional idea of tabbing from a search field to a submit button, and the process is completely inaccessible, as a screen-reader is unlikely to be alerted that the results have been loaded. Google Suggest and orderedlist’s functionality both replicate the conventions the user has come to expect from a search, in that a user input, whether that be selecting the return key or clicking on the “search” button, is required to generate results.
Forms
Forms are usually one of the worst offenders when a site undergoes usability tests. Confusion over what is a mandatory input means you will often get the form returned empty and/or without any explanation as to what inputs were ineligible. Using Ajax means that you can dynamically check the form inputs as they are entered and prevent the user from submitting the form until each field is filled in correctly. Standards-schmandards writes some of the key considerations for using AJAX forms are:
- Inform the user your form requires Javascript to be enabled in their browser.
- Make sure your user knows when information has been updated by using alerts when the page’s content has changed. Alerts are read by screen readers and are usually displayed together with a sound.
- Inform the user that the page is updated dynamically. This is especially important for screen reader users and will help them decide when to trigger a re-read of the page.
Users will encounter many side effects that occur as a result of using Ajax. These vary between users and platforms and may leave the user disorientated due to the differences in the technology of a page using Ajax.
Loading…
Because Ajax loads large amounts of data and then presents it dynamically, long loading times may arise. Ajax takes in large amounts of data and then transmits it internally, as opposed to a traditional html page that communicates with an external web server. This difference in architecture means the traditional page progress meter at the bottom of the browser is rendered inconsequential.
It is important to compensate for this loss in functionality to allow the user to know when the intermediate server is processing something. Gmail achieves this with its “loading…” message that is placed at the top of the screen while the application is in communication with the server.
Behaviour within a browser
One of the biggest complaints people have against web applications is the way they behave within the browser. Updates are not done by page reloads, so the address bar and the browsing history will only register you as visiting one page. This also means the back button may send you out of the application to the former site.
Luckily developers are creating work-arounds to make Ajax behave more like HTML in your browser. By using the backButton function in your Javascript you can force the browser to populate its history through the implementation of “iframes“. If used efficiently, the user will be able to switch between states of the application by using the browser’s back and forward buttons.
If a user is using Google Maps and tries to create a bookmark of a page of a close-up satellite photo of Dublin 8, the browser will only record the page’s default URL of “maps.google.com”. Instead of forcing the user to begin with a default view and navigate to their desired position on the map every time they visit the site, Google overcome the issue by offering a ‘link to this page’ text link which reloads the page with an identifying URL. Unfortunately the link is not very explicit and some users may still be confused. Google include an “Email” link which will open a compose window with the new identifying URL. Perhaps, it would be more beneficial if they created a “bookmark this page” which could perform the Javascript function of creating a browser bookmark and include the new relevant URL in it.
Conclusion
When Ajax first arrived on the scene, a lot of people encountered usability flaws straight away. However, there now appear to be workarounds for almost all of the major issues, so developers have no excuse for not creating user-friendly Ajax.
It is also interesting to note the advances that are slowly being made in the formation of accessibility standards for Ajax. Our next article will deal with the problems involved in trying to create accessible Ajax, as well as discussion of different viewpoints on its proper implementation.