Now blogging at diego's weblog. See you over there!

on ajax

One of the latest buzzwords to make its way around the web is AJAX (short for Asynchronous Javascript and XML, is that a "buzzcronym" then, rather than a buzzword?), which strikes me, as well as others, as one of those there and back again technologies, old ideas reborn in a different form. Recent weeks have seen the appearance of various AJAX toolkits, from SAJAX (for PHP) to JSonRPC (for Java). JPSpan, another PHP toolkit, is a little older.

But first, what is AJAX? Here's a good intro article on it. The basic concept is a simple one: turn a web browser into a more responsive client by making asynchronous requests to the server on another thread, handled by Javascript (there's nothing that says that this couldn't be done with, say, Flash or Java, but Javascript is a more universal platform on which to implement this). This separate thread can create the appearance of a more responsive UI by managing the requests in a manner transparent to the browser's default navigation mechanisms (e.g., Back, Forward, etc.).

Why do I say that AJAX is an old idea reborn in a different form? To answer that, allow me to take a little detour.

How web apps (used to) keep state, or the thin client way

Originally, a browser+HTTP+server combo was a stateless content-retrieval system. As more complex logic was added, browsers remained "thin" in that held very little state information. Cookies (on the client side) and Sessions (on the server side) were created to address that as more complex applications were brought online. But the limitations of cookies for data storage mean that they are used primarily for two things: initialization information (e.g., automatic login to websites) and historical or subscription data (although even in this case cookies are largely used as browser-held keys that point to more complete server-side DB records). Sessions, therefore, have remained the primary method to maintain state through the lifecycle of a web application (Some data can be held in the web pages themselves, e.g., hidden form fields, but that data has to be passed back to the server on each request). The problem with keeping sessions in the server is that, for nearly all significant operations, the client has to go back to the server to present a result, and it has to do it through the core UI thread, leading to a diminished user experience.

The problem this creates is that as long as we're not all accessing the Internet over low-latency T3 lines, and as long as servers experience load spikes, unexpected loads, etc., the user experience of web applications (via thin clients) differs significantly from that of client-side applications (fat clients). AJAX bridges this gap by creating what amounts to (cue reference to Douglas Coupland's Microserfs) a "thin-fat client."

AJAX: web client/server, or the rise of the "thin-fat client"

In the early 90's, the buzzwords du jour were "client/server systems". These were systems where PCs actually performed a certain amount of processing on data obtained and passed back through tightly coupled connections (typically TCP). As important as servers were in that scheme, one of the keys of client/server computing was that the client maintained most of its state. True, the server did maintain a certain amount of state and logic (just keeping state on a TCP connection would count, for instance), but it was the client that drove the interaction, that kept information on a user's location in the dataflow, etc. The web, however, changed all that.

If the web thin client model decoupled UI from processing (at least relative to client/server), AJAX allows for a flexible "free form coupling" when necessary. By pulling more data-management logic back into the client, AJAX goes back to a more traditional client-server model. True, the server could maintain state if necessary, and undoubtedly some AJAX-powered applications, such as Gmail, do so to some extent. But consider the difference between Google maps and, say, Mapquest. Mapquest stores the current view's data in hidden fields in the page, which have to be sent back to the server on each request. While this is, speaking strictly, stateless operation, the server has to re-create the state of the client for every request, modify it as necessary, and then send it back. Google maps, on the other hand, can keep the state on the client, requesting new data from the server as the user moves around the map, zooms, etc. The result? The server is freed from creating/keeping/updating state and goes back to doing what it does really well, which is serve data.

So does this mean that we're going back to client/server? Doubtful. There is no silver bullet. As cool as AJAX apps (like Google Suggest, Google maps, or A9) are, I suspect that AJAX's greater value will be to add another tool to the toolset, allowing for hybrid thin client/fat client applications that improve web UI interactions and bring us to the next level of distributed applications.

Posted by diego on March 18, 2005 at 8:59 AM

opml, icons, and the nooked rss directory

A couple of months ago I was looking for options for identifying OPML output while going through the design stage of the Nooked RSS Directory.

The question was: if the white-on-orange XML icon is a common way to identify RSS feeds, what's the equivalent for OPML?

One answer was to use the same icon, which is in fact generic, to represent OPML as well. This solution, however, can be used when you have either one type of output or the other, but not both at the same time. Another possibility was to use one of the many different icons that turn up in a Google Image search for opml. Another option was of course to create an entirely new icon. The problem was to come up with something that a) wouldn't be unfamiliar to users, b) would be unobtrusive and c) would maintain the value of the XML icon for the RSS feed.

On one hand, the line was crossed long ago when different applications overloaded the XML icon, and even its Look and Feel, while changing its contents (Yahoo! for example has modified the original icon here and they also have a similar-looking icon with "RSS" instead of "XML" to subscribe to Yahoo! Groups, example -- there are many others, I'm not singling out Yahoo! in particular). On the other hand, there's no need to create even more confusion. Dave has advocated the use of the XML icon for the appropriate XML output for a page (be that RSS, OPML, etc), and, maintaining the value of the icon by avoiding changing its contents while keeping the look and feel intact. After some thought, I concluded that in this case the second approach made more sense: barring a particular design or business need (for which there are many good examples, but that weren't a factor in this case) simplicity was the best option. Additionally, avoiding possible user confusion that would result from a non-standard icon is definitely a good thing.

So what I ended up doing was to maintain the common XML icon to point to an RSS feed (the most accepted use of it by far) and to link to the OPML using a simple text link, enough to be unobtrusive while remaining usable for those that know what they're looking for (after all, not everyone knows what "OPML" is). As it turned out this was a fourth option: have no icon at all.

For example, check out the directory's Arts & Humanities page. The same page can be viewed as OPML and as RSS. (The link to the OPML view is still there, to the right --- Nooked replaced the link that directs to the RSS view with a small ad after I delivered the app, so essentially imagine that the white-on-orange XML icon is where the Nooked ad is).

Interestingly, this solution was also pretty good in terms of matching the functionality needs that we had (unobtrusive and at the same time easy to identify for experienced users).

Related: there's some cool stuff that can be done by using the OPML output as a start, for example, reading the OPML of feeds listed in a category and presenting a full RSS data view of them (different from showing the entries of the directory in RSS, which the directory does) with little coding. Then the loop could go on by creating OPML views of the category feeds, and so on... interesting possibilities for meta-aggregation and possibly other kinds of data processing/analysis.

Categories: technology
Posted by diego on March 18, 2005 at 8:45 AM

Copyright © Diego Doval 2002-2011.