Ajax, not “AJAX”: A User-Centered Definition

Many equate Ajax to “Is it using XMLHttpRequest?”, which I think is taking the acronym too literally. There’s a reason why I’ve learned to say “Ajax” rather than “AJAX”: the term is user-centric, not techno-centric, and best defined in terms of what it gives users rather than how you deliver it. And what it gives users is a rich, continuous, experience to rival the desktop, with standards-based technologies.

Jesse James-Garret, who coined the term, doesn’t define Ajax in terms of specific technologies. Here’s what he said in the recent Ajaxian.com podcast interview: “In my opinion, Ajax refers simply to using browser-native technologies, open standard technologies, in ways that depart from the traditional interaction model of the web – the kind of call-and-response interaction model where every user action is tied to some kind of server communication, and while that server communication is going on, no user actions can take place. Any time you’re decoupling the flow of user interaction with the application from the flow of server communication, and you’re doing that with browser-native standard technologies, I think that’s Ajax.”

If you can pull off a rich browser client using HTML 1.0, you got Ajax! In reality, you’ll end up using a mix of technologies suggested by the acronym (“Asynchronous Javascript and XML”) and some other things too (“DOM/DHTML/CSS”), but not necessarily all of those things. Having peeked under the covers of various high-profile Ajax sites, it’s clear that many are using custom-format messages, rather than XML for transfer. Similarly, XMLHttpRequest is not the only valid means of transfer. Google Maps uses IFrames, I’ve come across various enterprise systems that do the same, and I expect other Ajax apps do it too (and still on the lookout for examples BTW).

Agile: Not Just an Attitude

Agile is a big theme these days. Not surprising that it should be a big part of “Web 2.0”, since Web 1.0 is often attributed as an inspiration. Paul Scrivens reminds us of [37Signals’ association with agile principles](http://9rules.com/whitespace/fear_is_a_good_thing.php] and that’s evident, for example, in this talk by Jason Fried. Similarly, the agile manifesto was mentioned in a Web Essentials talk last week (I think Kelly Goto’s talk, towards the end). And, of course, you’ll see “Agile” bandied around in most magazine ads run by consulting and IT companies, complete with obWhiteboardSketches.

What you don’t hear much of, in these bite-sized message, is how to do agile. I’m sure the speakers and their organisations know how (though I’m not sure about all the magazine advertisers), but how about the audience? I have visions of some people thinking, “1. Loosen up a bit. 2. ???. 3. Profit!!!!!!”. Hopefully, some of them will do some investigation and learn the how part, but for others, this has the potential to end in tears.

To clarify:

  • Agile is not just taking your tie off.
  • Agile is not just the manifesto.
  • Agile is not just whiteboards.
  • Agile is not just programming.
  • Agile is not just adding functionality.
  • Agile is not just setting up a wiki.
  • Agile is not just “we have to try harder”.
  • Agile is not just taking your tie off.

Here’s why:

  • “Agile is not just taking your tie off” because you need specific technologies, technical skills, and techniques.
  • Agile is not just the manifesto, because that’s a set of principles, not a manual.
  • “Agile is not just whiteboards” because no-one ever got paid for delivering a whiteboard. (With the obvious exception of whiteboard manufacturers, and it’s also likely some retailers in the corporate sector have made a tidy profit in the whiteboard market.)
  • “Agile is not just programming” because it’s also continuous design and testing.
  • “Agile is not just adding functionality” because it’s also refactoring existing functionality.
  • “Agile is not just setting up a wiki” because it’s the content that counts. (And in any event, use the wall instead of a wiki. Support your local whiteboard manufacturer today.)
  • “Agile is not just “we have to try harder” ” because that’s not sustainable, and even if it was, it’s not optimal.
  • “Agile is not just taking your tie off.” No, really. Keep it on if you like. It makes no difference. A black polo top doesn’t make you more agile.

(Vaguely inspired by hearing that Dave Weinberger’s going to be talking about what blogging’s not.)

What I like most about Extreme Programming is that it makes the practices explicit, whether you agree with them or not. “Refactor Mercilessly”, “You Ain’t Gonna Need It”, “Test-Driven Design” – they might sound like mindless mantras to the uninitiated, but they actually reflect a lot more concrete, rich, advice than “Chill Out”, “Loosen Up” and “This agile thing’s a breeze … (something about whiteboards) … profit!”.

New Patterns: XMLHttpRequest Call and IFrame Call

Full drafts are now online for the two big Web Remoting patterns: XMLHttpRequest Call and IFrame Call. There are also a couple of new demos to illustrate GETting and POSTing with both call types: XMLHttpRequest Example, IFrame Example.

A few extracts follow, but first, let me ask you: Do you know of any public IFrame remoting examples? Google Maps is the only public example I know. All the other examples here are tutorials and framework demos.

The XMLHttpRequest alternatives was the most fun thing here (headings shown below). I went through the various techniques I’ve seen, read about, and tried out, to list as many ways as possible to programmatically call the server. As you might expect for these “Foundational Technology” patterns, there’s a lot more code in the Solutions than in later patterns, where the focus shifts more towards the -ilities, particularly usability and maintainability.

As usual, feedback much appreciated. (Mainly on the content, rather than woeful spelling and outright grammatical disasters at this stage.)

XMLHttpRequest Call

Solution: Use XMLHttpRequest objects for browser-server communication. XMLHttpRequest is a Javascript class capable of calling the server and capturing its response. Just like a browser or a command-line web client, an XMLHttpRequest issues standard HTTP requests and grabs responses. Note: The code shown throughout this demo is closely based on an online companion demo (http://ajaxify.com/run/xmlHttpRequestCall/).

The above example hopefully illustrates that the fundamental technology is pretty simple. However, be aware that it’s a very basic usage, not yet fit for production. Fundamental questions remain:

* How can XMLHttpRequests be created?
* How does an asynchronous call work?
* How do our code detect errors?
* What if the service requires a "POST" or "PUT" request rather than a "GET"?
* Which URLs can be accessed?
* How can you deal with XML responses?
* What's the API? 

The following sections address these questions and show how the code above needs to be modified. …

Decisions

6.1 What kind of content will web services provide?
6.2 How will caching be controlled?
6.3 How will you deal with errors?

Alternatives:

9.1 IFrame Call
9.2 Persistent Connection
9.3 Richer Plugin
9.4 On-Demand Javascript
9.5 Import XML Document
9.6 Image-Cookie Call
9.7 Stylesheet Call

IFrame Call

Solution: Use IFrames for browser-server communication. IFrames are page-like elements that can be embedded in other pages. They have their own source URL, distinct from their parent page, and it can change dynamically. IFrame Calls work by making the IFrame point to a URL we’re interested in, then reading the IFrame’s contents once the new content has loaded.

Flock: A Tribute to Unusability of Firefox Extensions?

You’ve probably noticed the buzz around Flock, a browser built on Firefox. Information’s limited, but it seems to pick up on the “social” buzzword – tagging, annotations, RSS etc. Thing is, all of these things are possible in Firefox too via extensions. But extensions haven’t really taken off, and the reason is, quite frankly, poor usability. Firefox is a great browser with a plugin architecture that’s pretty good too. The problem is at the last mile: helping users install and manage their extensions.

Sure, developers will install programming extensions and uber-geeks will set up mouse gestures, but it won’t get beyond that in its current state.

So here’s how a plugin architecture should work:

  • Installing plugins should be dead simple. Pull up a list of plugins and click to install … that’s it! Come on, you own the whole browser and the server too! Make them work together. The current task is something like “visit extensionroom, search for extension, jump into extension page, click Install, Notice security dialog box about this subdomain if you’re lucky, Allow the subdomain, Click Install again if you’re savvy enough to realise what just happened, Watch it download, Click Install, Restart the browser if you’re still interested”. If the version’s incompatible, you’ll only find out at the end of all that (except the restart). True, the version number’s shown when you install it, but that’s really making the user do something the computer should do immediately. Also, most users don’t remember what version they’re running, and I’ve even seen extensions with the version labeled as “Deer Park”.
  • The standard distribution should have a set of extensions pre-installed. Just because you’re using a plugin architecture doesn’t mean you have to ship with a bare-bones distribution. I know there are potentially licensing issues, but shipping with plugins seems to work OK for Eclipse and similarly for the Linux distributions. Satisfy the slashdot crowd with a minimal distribution too, by all means, but mainstream users would rather not spend three hours working out how to install extensions, finding out which are popular/useful, discovering incompatibilities between different extensions, etc. There are plenty of extensions that enhance basic functionality – e.g. All-In-One Sidebar, Adblock, the improved search bars, the improved RSS aggregators – why not take advantage of them? In addition, there’s great scope for specialised distributions, e.g. Developer, Socialite. I know anyone could probably make them and distribute them, my main point here is that Firefox itself should at least distribute a more powerful default distro.
  • Don’t rely on third-party extensions for fundamental functionality. Tabbed browsing works OK in the basic distribution, but the Tabbrowser extension gives it much more power – certainly it brings it up to Opera standard. Yet, it’s been unsupported for over a year, confusing, and buggy at times. Something like this is too important to leave to a third-party. Develop it as an extension if it’s architecturally convenient to do so, but make it mandatory, so that other extensions play nice with it.
  • Provide update notifications. Indicate when updates are present and offer to do the update automatically.

Greasemonkey took off so quickly because it’s so easy to develop, modify, and install GM scripts. Hopefully, the lessons of Greasemonkey and the imminent release of Flock will offer some lessons, and help make Firefox an even greater browser.

Tag Me, Tagyu

Tagyu (via Lifehacker) accepts a URL (or some text) and gives you some tags.

Tags for AjaxPatterns:

ajax javascript programming web

Tags for SoftwareAs.com:

ajax tech webdesign design blog webdev web_2.0

Consarn it! It actually did a good job! I was hoping something off the mark. “ajax beethoven web anime french_history software” would be more like it, thanks.

Chat: The “Hello World” of Ajax?

Day Barr:

Chat is not quite the Hello World of Ajax, but it’s one of the simplest yet useful things I could do. I didn’t learn very much by writing an Ajax Hello World example and it’s completely pointless :-)

As many are learning, an Ajax “Hello World” is pretty easy, provided you’ve already got a grounding in web/JS programming. So beyond that, what’s the quintessential Ajax tutorial app? Some of the Ajax texts are beginning to pour out, so maybe a pattern will emerge. But, for now, the learning apps of choice seem to be:

I’m surprised we haven’t seen more people playing with Ajax wikis and RSS aggregators, but I’m sure they’re coming.

BTW, a basic “Hello World” might be easy, but it’s also a useful springboard for some important variants. e.g. Add a long delay in your server and see how the browser script handles a timeout (or simulate a delay with Julien’s GM script. e.g. Host the service on another domain and have the server act as a proxy. e.g. Apply a visual effect like the famous Yellow Fade Technique when the message comes in. These variants aren’t just interesting exercises – all are important for real-world Ajax development.

Another DHTML “Game”

A new DHTML boxing “game” from the Man In Blue. Not quite DHTML Lemmings or Super Maryo World, but still more fun than it should be. A bit like the Ruby On Rael thing in reverse.

Also from the same presentation is an eerily lifelike OSX clone (Firefox-only). More evidence that Ajax might be useful in prototyping desktop apps. And since prototypes usually go on to become the real thing …

Thanks to the Web Essentials organisers for podcasting the talks. Safran on Sunday will have to go on hold for a while.

Ajax can *Improve* Performance Too

Recent Ajax apps like Kiko are sluggish according to Alexander Kirk’s “Rise of Slow Ajax Applications (via AjaxDeveloper):

Pages get more voluminous because so much code has to be loaded to the browser (which makes the browser slow again) so you could just begin to use the application. This somehow reminds me of all the flash apps. Waiting for hours to load the page and you’ll stick to that page for half a minute.

The initial delay is due to loading of Javascript and data too. Fast startup is certainly a big motivation for Ajax, so it’s a problem if that’s not happening.

Alexander gives four tips:

  • Keep it bookmarkable. Don’t load everything to one page, let users return to a certain section of your app via their bookmarks.

This is sort of mixing two concepts together. Using Unique URLs, it’s possible for an Ajax app to be bookmarkable, but still the same “page”. I think the advice here is to use real page refreshes rather than making an entire website a single Ajax application. I think that’s fair for a big corporate website, but for a standalone app like Kiko, it’s best seen as a last resort. Saying that, a reasonable use might be in switching between a general login/menu page and the core app itself. Or, in Writely, switching between the different tabs – editing, blog it, etc.

  • Don’t overuse AJAX. Often simple Javascript without server interaction will do. Try to reduce the server callbacks.

Agree with the tip, though not necessarily the implicit definition that Ajax == server interaction. Rich, standards-based, Javascript is Ajax in my book, and certainly a good way to improve performance.

  • Minimize the code to be loaded. When you don’t have any other choice, consider code downloading.

Code downloading – or On-Demand Javascript – is actually quite easy to do. It involves loading some basic Javascript immediately and continue to load the rest in the background or as needed. You can load the JS by tweaking the head element, or alternatively by pulling it down with XMLHttpRequest and eval’ing it. As an extension of multi-stage code loading, there’s also Multi-Stage Download – downloading an initial structure upfront and populating it with further calls.

  • Speed up your apps with AJAX. Use AJAX for what it was meant for: tune your existing application at points where postbacks need to reload the same page with only little change.

Great point. <rant>Too often, Ajax is blamed for making the web slow, unaccessible, unusable, etc. But what if we stop a minute and ask “What if Ajax could improve performance/accessibility/usability? How could that happen?” By attempting to answer these questions as effectively as possible, even if we disagree with the premise, we’re better equipped to weigh both sides of the argument.</rant>

In the case of performance, there are plenty of ways Ajax actually improves the situation. For starters, you don’t need to download an entire HTML page every time you talk to the server. More specifically, smart Javascript can do stuff like caching, guesstimating, and pre-fetching.