Premature Ajaxification
I hear a lot about Ajax these days, now that it’s making its presence felt in the mobile space. About a year ago, Opera announced Ajax support for mobile devices. Today, there are a few more browsers out there that have the necessary JavaScript and XmlHttpRequest capabilities, and applications making use of these features. (SoonR comes to mind.) The trend is welcome, as it grows the potential for mobile devices.
But what are people expecting? On the PC, the introduction of the Ajax approach created a wow response. The interaction was more responsive. Looking just beneath the surface we see that this is achieved through asynchronous background updates and partial refresh of the currently displayed page.
The request/response delay is still there, but you don’t notice it because:
- You may be busy interacting with the current page (such as dragging a map around or reading the last sub-page refresh), or
- The refresh only applies to a small subset of the displayed page, so you don’t see the usual flicker/blank and redraw that is characteristic of normal hypertext navigation.
So, if a mobile Ajax technology is to have the same wow effect on the interactive experience, we should consider how to achieve one or both of the above delay-masking factors. Let’s consider these in a mobile device context.
Keeping the user busy during an update
The usable display area poses a little problem for keeping the user occupied. It is likely that the user will be able to consume (read) the entire screen in a very short period so by the time an Ajax-based update is initiated, there’s nothing on display to occupy the user. Unless the display is dynamic (e.g. showing some animation) or interactive (e.g. a form to be filled in or a game to be played). Here an SVG, SMIL, Flash/Flex or even a JavaScript-based interface could keep the user busy while the async update takes place. Trivial time-wasters, like progress bars, don’t fulfil this requirement.Restricting the refresh to a subset of the page
A subset of a small mobile page could be very small indeed. So small that the user may not even notice much of a difference between a partial refresh and a full page refresh. Refreshing/updating the displayed content via Ajax is therefore unlikely to produce much of a wow response from the user.
In my opinion, neither of these is going to produce the kind of response we typically get from Web users the first time they encounter a PC-browser Ajax application. Instead, take a look at Google Suggest, an Ajax-enabled predictive search interface. As you type, Suggest tries to predict what you are going to type next, and displays a list of potential search phrases with the number of hits likely to occur for each suggestion. Now consider how difficult it is to type text using a typical mobile device. This is the kind of application that could produce the elusive wow response.
Before you get carried away with the possibilities opening in front of you, think again about the Mobile Suggest idea. For it to work, the Ajax code on the device has to send search keys to the search server every time you press a key, and get a response back in time to update the suggestion list before you press the next key. Given the round-trip delays of a typical mobile network, this is unlikely to work. You could try being a little more clever by letting the server look ahead by a character or two, and send back a bigger list of all the suggestions so that the script on the client can filter the list based on the character typed by the user during the round trip. This would increase the response payload size (thus slowing it down a little, and possibly increasing the cost to the user) and would put a greater load on the search engine.
Bottom line: it’s a little premature to assume that even the most basic Ajax applications are going to be portable to the mobile space. Ajax on mobile is not just a mobile version of fixed-Web Ajax. You need a bit more imagination.
Categorised as: Uncategorized