Feature
AJAX (Asynchronous JavaScript and XML): This Isn’t the Web I’m Used To
By Jason A. Clark
Have you heard of Ajax? No, not the kitchen cleanser, the Dutch soccer (football) team, or Sophocles’ play. In the technology world, Ajax (sometimes spelled AJAX) is an acronym for Asynchronous JavaScript and eXtensible Markup Language (XML). It’s one of the hottest new technological buzzwords. Depending on the source, you might hear that Ajax will reinvent people’s expectations of Web sites or that it’s the latest Web trend that’s bound to fizzle. The truth is somewhere in between. Ajax changes how users are able to interact with online content by allowing Web page data updates without the usual routine of clicking from Web page to Web page. Chances are good that you have seen Ajax before; you just didn’t know it. Popular Web sites such as Google Maps, Amazon, and Flickr are leading the Ajax charge. It’s only a matter of time before these implementations trickle down into library catalogs and Web sites.
What’s in it for Libraries?
Libraries and information agencies have been slower to embrace Ajax, but it’s not for a lack of library-use cases. In a library setting, Ajax could be used for speeding up digital library search applications using a link to activate a process that matches multiple ISSNs to compile a list of electronic journals, or even making quick requests to validate a user’s personal information as they log into a “My accounts” section of the catalog.
Let’s look at registering for an Interlibrary Loan (ILL) and requesting a book. Say Susan, a hypothetical academic library user, needs to perform these tasks. In a traditional Web interaction, she would have to navigate through the registration form to enter data for basic contact info, a username, and a password. She might have to submit possible usernames, wait for the form to talk to the server, only to come back and tell her that the username she entered is taken—at which point she also realizes that every bit of data she entered into the form has disappeared. An Ajax Web interaction can provide shortcuts to this process. Rather than sending the whole form to the server for an answer, the Ajax method sends a request on the piece of the form in question behind the scenes to see if Susan’s chosen username is already in use. Because the response from the server is returned almost immediately, Susan receives instant feedback telling her to choose another username. There’s no loss of data or waiting for pages to reload for an answer.
Later in the process, Susan is using an ILL form to request a book. In a traditional Web interaction, there would be lots of typing and cutting/pasting from the catalog to enter the book information into the request form. Ajax can make this process less onerous. As Susan types into the book title section of the request form, she receives a list of the possible titles right below the form field that match her keystrokes. She sees her book title, clicks on it, and the book title section is populated. Behind the scenes, Ajax has made a query to a library catalog title list matching Susan’s keystrokes to entries in the title list and then pushed that data back to Susan as she types. Susan has similar experiences with the author and ISBN sections of the request form. She finishes quickly and moves on to continue her research with a smile on her face.
Ajax can also make searching and browsing library resources easier. Consider the case of John, another hypothetical library user, who has been surfing the Web looking for sources for a paper on biotechnology. In time, he makes his way to the library Web site and finds the pages listing the library’s licensed databases and indexes. If the Web page was set up for a traditional Web interaction, he would click from page to page looking for subjects that might match his research needs—biology, engineering, and health sciences. He would click a link, the page would process and reload, the new page would appear, and so on.
An Ajax-enabled page would take advantage of John’s research needs without pushing him through a series of pages. With an Ajax interaction in place, John visits the library’s licensed databases and indexes page. He rolls over a link to a list of subjects and is presented with a list of all the subject categories for the library indexes and databases. In the background, Ajax has made a request to grab an XML file holding the list of subject categories. The list is retrieved and it then populates the pop-up list that John sees. For John, the feedback is immediate. He gets an instant snapshot of the subject categories and begins moving forward with his research. Later on, John clicks the biology subject category link. A section of the page changes and shows John a listing of the top biology indexes and databases as well as related subject categories such as health sciences and chemistry to investigate if needed. Ajax reduces the need to click through to more information, bringing data into the user’s working environment. John continues his research happily, unaware that his life was made easier by Ajax.
AJAX AT WORK IN LIBRARIES
Although I could go on with hypothetical possibilities that warrant some of the hype surrounding Ajax, it’s not necessary to restrict the discussion to the hypothetical. More and more libraries are starting to use Ajax for actual projects.
At OCLC research, you’ll find the Phoenix Live OPAC [http://phoenix.orhost.org], a “livesearch” (instant search) of a WorldCat subset of the Phoenix Public Library’s collection. As a user types search terms, quick queries are made to the WorldCat database and the results are displayed almost instantly beneath the search form. It’s amazing to watch a search of a significant public library collection take place in seconds using Ajax.
In Perth, Western Australia, the Curtin University of Technology Library is using Ajax to power its federated search function [http://library.curtin.edu.au/cgi-bin/search/search.cgi?query=&submit=Search]. A single search across several library databases using multiple behind-the-scenes server requests brings all of the data together into targeted sections of the original search page. Curtin’s implementation is a good example of the asynchronous nature of Ajax. The requests continue firing and the search page is populated with separate results at different intervals.
A fun Ajax add-on to the library catalog exists at Virginia Tech Libraries [http://addison.vt.edu]. Called Guesstimate, it lets the user mine the catalog for the popularity of their search terms. As a user types in keywords, Guesstimate “presearches” the library catalog for the user’s search terms and displays the number of hits before the user has to actually perform a full catalog search. It’s some nice added functionality that provides the user with a sense of the strength of their keywords.
Many of these example applications have a search focus that is a logical first step for libraries. As users become more familiar with Ajax, we can expect that Ajax would move into other areas of library Web services, such as RSS feed update displays or dynamic navigation links that present different page views to a user.
HOW AJAX WORKS
Ajax is not a single programming language, but rather a series of component technologies tied together by a single goal. The goal is to quickly process data and push the data into a localized page update. Ajax achieves this effect by working asynchronously, meaning that you can make a request to a server via Hypertext Transfer Protocol (HTTP) and continue to process other data while waiting for the response. But what does that really mean? Consider the earlier hypothetical examples. In the ILL form example, it means you can make requests to a server to retrieve data about what usernames and passwords are already in use by the ILL database without refreshing the whole page. In the searching and browsing library resources example, it means you can simply load an XML file to populate the subject categories section of your indexes and databases Web page without refreshing the whole page. Let me repeat that last part one more time: without refreshing the whole page. This is what makes Ajax implementations recognizable. Ajax is able to target pieces of content on a page and run micro-requests behind the scenes to update those pieces of content. On the user end, you see an almost immediate update or page change without the usual full-screen reload.
Because Ajax exists as a series of component technologies and is able to make these components work together, today’s Ajax-enabled Web applications are able to avoid the pokey, page-at-a-time, data request/response model. Here’s a quick rundown of the suite of technologies that make Ajax go:
(x)HTML and CSS
Ajax applies these familiar Web standards for styling the look and feel of a page and to markup those areas on a page that will be targeted for data updates.
DOM (Document Object Model)
Ajax uses the DOM to manipulate dynamic page views for data. The DOM enables certain pieces of an Ajax page to be transformed and updated with data.
XML, JSON (JavaScript Object Notation), HTML, or Plain Text
Ajax can use any of these standards to provide structure to the data it passes to and from a page.
XMLHttpRequest Object
The heavy lifter for Ajax: It’s a JavaScript object embedded in most modern browsers that sets up data request/response pipelines between client and server.
JavaScript
Ajax uses lightweight programming language for instructions to bind all of the components together.
One thing might strike you about this list: None of these technologies are particularly new. What has changed since their creation in the 1990s is how people access the Internet today. Broadband access, coupled with speedier processing and storage on personal computers, makes Ajax a viable approach to Web applications. Unloading some processing onto client computers, along with proof-of-concept, large-scale Web applications such as Google Maps, also contribute to the acceptance curve and excitement surrounding Ajax.
EVEN Ajax isn’t perfect
Every new technology with potential is celebrated and Ajax is no different. Advocates for the technology point to the fact that it is built with open standards: (X)HTML, CSS, JavaScript, and XML. Open standards are nice feathers to have in your cap because the need to develop in a closed environment or to depend on proprietary technologies that a user may or may not have is removed. (Forget about downloading Flash plug-ins or Java applets.)
Another benefit involves the Ajax single-page model. Reducing the number of pages needed to perform a task presents users with faster, streamlined interfaces and seemingly on-the-fly data updates. Because Ajax works to pass only targeted bits of data for a page, it is a very efficient use of bandwidth for data presentation. There is a great advantage to having static pieces of a Web page remain static while micro-requests go to the server to grab and bring down targeted data. Gone are the days of watching the hourglass spin.
Advocates also point to the very active Ajax developer community, which is always looking at improvements to current Ajax behaviors. Already, a number of Ajax code libraries have sprouted up that simplify Ajax requests and actions. (See prototype at http://prototype.conio.net/ and script.aculo.us at http://script.aculo.us.) In addition, the popularity of Ajax has garnered enough support that the W3C Web APIs Working Group will soon be standardizing the XMLHttpRequest object for all new browsers and updated versions of current browsers.
Of course, Ajax is not without its warts. Because the XMLHttpRequest object is essentially a de facto standard, its implementation across browsers can be a bit buggy. Most modern browsers support the XMLHttpRequest object, but there are some quirks with Opera’s implementation, screen readers, and text browsers such as Lynx. The XMLHttpRequest object is also limited in the requests it can make across domains; it can be tricky to get Ajax to request data between different servers. Another limitation of Ajax is the way it breaks down the traditional Web page model. Users are accustomed to recognizing the changing status of Web pages through the cue of a changing URL in the Web address bar of a browser. Ajax subverts this model by leaving the URL unchanged after a page update. This hampers the ability of a browser to use the back button or even link to an actual Ajax results page. (The back button and direct linking are Web conventions expected by most users; Ajax developers have started to develop workarounds to bring back this functionality for Ajax. See Mike Stenhouse’s article, “Fixing the Back Button and Enabling Bookmarking for AJAX Apps,” at http://www.contentwithstyle.co.uk/Articles/38.)
Finally, the speed of Ajax presents a couple of problems. On the usability end, immediate page updates can leave the user wondering if a request was answered. Blink and you might have to scan the page to determine if the link you clicked really did bring in that new set of subject headings. On the processing side of things, users with computers not equipped to carry out processing in their browser lose out on the functionality of an Ajax page. Sloppy JavaScript programming practices that tax a user’s CPU unnecessarily or even the savvy user who has turned off JavaScript in their browser won’t get all the bells and whistles from an Ajax application.
When and how to use Ajax
The question remains: When should you use it? Anytime there is a search function, you could apply Ajax. Whenever there are multistep processes (think logging into a “My accounts” section of the library), Ajax should be a consideration. While processing large or distributed data sets (think Federated Search), Ajax would be a nice option. Anytime you need to validate complex forms (think ILL), Ajax might be an answer.
The caveat I would add is how to use Ajax. It’s not the answer for all situations. Ajax is well-suited for a predictable, controlled user environment. A company’s intranet application or a library’s public machines are solid candidates for Ajax implementations. Another important consideration is how Ajax should be applied. When applied, Ajax should provide supplemental rather than essential application functionality. If someone shows up at your Ajax-dependent library catalog with JavaScript turned off, make sure you are still able to give them a working catalog minus the bells and whistles.
Even with its limitations, Ajax is intriguing enough to warrant the widespread attention it is receiving. At its core, Ajax shifts the expectation of what a Web page is and what you can look forward to from Web applications. By relying on a user’s computer and browser to process data, carrying out multiple data requests behind the scenes and targeting single sections of a Web page for updates, Ajax presents users with a seamless interaction that rivals what you might see in a desktop application such as Word. It opens the door to a whole new breed of Web applications.
|
