AJAX and mobiles...

If you frequent the knowledge circles of web designers and architects, then you can't have failed to come across AJAX.

No, it's not a famous scouring powder in the UK for scrubbing baths. It's a design approach for browser-based applications. Some disgruntled web-heads are upset about the new term, as it's possibly just a marketing spin for something that already existed.

Renaming old things can be a great way of creating a buzz. Whether Adaptive Path should have come up with a new term or not, they have certainly succeeded in generating a buzz and attracting interest in this approach. After all, here I am writing about it!

My interest, naturally, is in the potential of AJAX for wireless applications. To spare ourselves all the sordid detail about AJAX, the key concept of this design approach is the ability for a web page to pull new data in from a web server, as opposed to the browser. To see this in operation, you could try the interesting Google Suggest interface.

Notice how an area ("panel") appears below the text box and starts to fill with search terms that match the letters you type. What's essentially happening is that a small piece of code (JavaScript) associated with the web page is fetching search terms from the server. This allows the suggestions to dynamically and rapidly populate the panel area. If the entire web page, graphics and XHTML had to be fetched, instead of some relatively light weight search terms, this whole process would be slow and cumbersome.

That's the problem - slow and cumbersome - with a lot of web (WAP) browsing on mobile devices, which makes it painful much of the time. It therefore seems sensible that this approach would be a good fit for mobile. Interestingly, it is supported on Windows Mobile Edition 2003! Not surprisingly perhaps, as the heart of that piece of JavaScript that pulls the info from the server was invented by Microsoft (called the "XMLHttpRequest" object ).

The reason that AJAX and this XMLHttpRequest object are worth talking about is that whilst the user is interacting with the page interface (i.e. reading, thinking, contemplating, typing), the page can be pulling in new data without waiting for an explicit request from the user. In other words, asynchronously to the user commands, which is where the A in AJAX comes from.

Let's think of an application to illustrate the possible advantages of AJAX in the mobile context. Let's choose one of the most popular portal experiences, which is surfing for downloadable ring tones. Sorry if you don't use custom ring tones, but a lot of people do. Even if you don't, I suggest surfing your operator portal to get a feel for the pain involved.

(For this example, we have to put aside the fact that most browsers don't or couldn't support AJAX. Not only is the XMLHtt.... bit missing, but the necessary scripting and CSS support is missing too. However, we need to think seriously about what a mobile web browser should be able to do, and this is an important topic that I hope to return to. Fundamentally, as I have suggested many times before (and in my book), the logical progression from desktop browsers to "desktop-browser-lite" was, and is, flawed.)

The ring tones are usually listed in alphabetical order for each genre, like rock, 80's pop, indie, etc. Most portals seem to insist that users have to page through lots of listings to find the one they want to try (or buy). It would be much more efficient and usable to allow the user to scroll through a list of tones, or use a suggestion-panel, to home in on the desired tone. Also, if it's a midi tone, then it can also be pulled into the page without re-loading and allow a helper object to play the tone.

Of course, this is speculation. I'm not in a position to try this out with a mobile device and the actual performance and usability improvements are guess work. However, I suspect that the improvements would be real.


Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book