More on AJAX and federated search

I’m about to add a little bit of AJAX to some software I’m writing so I’m reading up on the technology. So, when my Google alert for “federated search” turned up 5 things you didn’t know about AJAX I was curious to read the article, which appeared in the blog for the Task Force on Social Networking Software for the Medical Library Association. Read my previous article, The interplay between AJAX and federated search, for background material on the intersection of the two subjects. That article introduces AJAX:

AJAX stands for Asynchronous JavaScript and XML. Asynchronous refers to the fact that a program using AJAX can request an update to bits of a web page without having to reload the entire web page. JavaScript provides the mechanism that the web page uses to communicate with the HTTP (web) server. XML is the standard that is sometimes, but certainly not always, used to encode the data given to the web server. AJAX is basically a set of standards and techniques that a web programmer can use to create HTML-based web applications that are browser-independent where parts of the page refresh smoothly without requiring entire page reloads.

The “5 Things” blog article (item 3) links to a few instances of library sites using AJAX. Of special interest is the Curtin University Library in Australia, who is said to have built their own federated search application with heavy use of AJAX. The blog article provides some links to learning more about AJAX, including one to the slide presentation that is the topic of their article.

Later in this article I’ll list seven examples of how AJAX is used in a federated search application that I’m pretty familiar with. Before doing that, though, I’d like to make an important point that you’ll want to keep in mind while you read my list of examples. The “5 things” article misses this point:

In order to add AJAX to an application, you need to either have access to the source code of the application or (more likely) access to an API (application programming interface) to gain access to information that the user interface doesn’t have.

I’m sure that the above statement only makes sense to techies so let me illustrate what AJAX does with an example. Let’s say you have a federated search application that tells you, while your search is running, how many sources have returned all of their results. That count needs to change as more sources return their results. Also, you don’t want the application to redraw the entire screen every time the count changes. AJAX is handling the updating of the count and AJAX is also responsible for the fact that just a small piece of your web page is updated. And, related to my “missing point” statement above, this seemingly simple updating of a count is only possible if the AJAX code running on your browser is able to somehow ask the server performing the federated search how many sources have returned their results. Federated search applications that allow their users to add AJAX to the user interface MUST provide a mechanism for the user interface to get information from the server, which controls searching and processing of search results.

Now that you have some idea about how the client (user interface running on the user’s browser) needs information from the server, let’s look at seven places that WorldWideScience.org uses AJAX. (There are more than seven; I just figured seven would be plenty.) For the sake of disclosure, Deep Web Technologies, the sponsor of this blog, built the search engine behind WorldWideScience.org.

1. Status bar showing number of sources complete. The browser gets the count from the server and updates the count and the “thermometer” showing the count visually.

2. Count of ranked results and total results at the source. The browser asks the server for the two values.

3. Dialog box of additional results available. WorldWideScience shows whatever result it has a few seconds after the user submits the search. Once the search is complete, the browser displays a dialog box telling the user how many more results are available and asking the user if he wants to incorporate the new results into the set the user is viewing. It’s the server that tells the client how many more results there are.

4. The “Sort by” menu. Notice that when you change how the application sorts results (by rank, date, title, or author) the results are sorted and redisplayed but the rest of the web page isn’t. The sorted results are provided by the server.

5. The “Limit to” menu. You can limit results to a single result and, just like in the “sort by” example, the server provides a new set of results and only a piece of the web page is updated.

6. Displaying results from a cluster. When a user clicks on a cluster name, the server is queried for the set of results pertaining to that cluster. Only a piece of the results page is redrawn.

7. Page navigation. When a user clicks on the arrow keys or links to page numbers, very little changes in the screen, other than the search results. At least the first time that a particular page of results are downloaded to the browser for a particular page they must be requested from the server.

I hope I’ve illustrated my point: intimate interaction with the server is required to get the information needed to perform the AJAX for page updates. The “5 things article” did hint at the technical level of expertise necessary to use AJAX:

One of the things I realized during this class was how much more I needed to learn about xml, css, php, sql, and various other programming-related acronyms in order to implement anything scripted in Ajax on my library site.

I would add JavaScript to the list as well as API programming. These two are critical in getting the information you need from the server. Plus, depending on the application, AJAX may also need to send information back to the server.

One last thing. Point number 2 in the the “5 things” article says that WordPress uses AJAX. I couldn’t think of any place that a user would notice that used AJAX (other than some plugins) so I Googled for AJAX and WordPress and got this, from the WordPress Codex:

Because of its responsiveness, Ajax technology is being adopted by all sorts of web sites — and WordPress is no exception. Currently, the core of WordPress uses Ajax only in the administration screens. For instance, Ajax is used for instant updates when you are doing comment moderation, and when you are adding and deleting items from lists such as categories, blogroll, and posts…

If you enjoyed this post, make sure you subscribe to the RSS feed!

Tags: federated search