Recently, Opera announced the availability of AJAX on mobile devices through their browser. Considering the popularity of Opera in the browser market (especially in the mobile browser market), this announcement is indeed very significant. Having been involved in creating mobile services for a few years now, I believe AJAX will replace both Java ME and XHTML as the platform of choice for developing mobile applications.

Before I do so, a caveat – I believe that Mobile Web 2.0 is far more than ‘AJAX on mobile’. Mobile Web 2.0 involves applying all seven of the Web 2.0 principles to mobility. Here, I am discussing AJAX only i.e. only one facet of Web 2.0.

What is AJAX?
AJAX is an optional addition to Web 2.0. It is not a single technology. Rather, it’s a combination of a number of existing technologies acting together, namely:

• XHTML and CSS for standards based presentation
• Document Object Model for dynamic display and interaction
• XML and XSLT for data interchange and manipulation
• XMLHttpRequest for asynchronous data retrieval and
• JavaScript to tie everything together

Until AJAX came along, it wasn't easy to replicate the rich and responsive interaction design of native applications. AJAX is different from other previous attempts in addressing this problem since it is based on existing, non-proprietary standards which are already familiar to developers.

In traditional web applications, most user action triggers an HTTP request. The server does some processing and returns the result back to the user. While the server is processing, the user waits! The ‘start-stop-start’ nature of web applications is good from a technical standpoint but not from a user interaction standpoint (since almost all user interaction is resulting in trips to the server and the user is waiting while the server is doing the work).

AJAX solves this problem by using the AJAX engine. At the start of the session, the AJAX application loads the AJAX engine. The AJAX engine is written in JavaScript as a JavaScript library and sits in a hidden frame. The user interacts with the AJAX engine instead of the webserver. If the user interaction does not require a trip to the server, the AJAX engine handles the interaction on its own. When the user interaction needs some data from the server, the AJAX engine makes a call asynchronously (via XML/XMLHttpRequest API ) without interrupting the user’s flow.

AJAX is ‘asynchronous’ in the sense that the AJAX engine is communicating with the server asynchronously to the user interaction. Thus, the user gets a seamless experience (i.e. the user is not waiting).

There's a momentum behind AJAX at the moment. Developers are already familiar with the technologies underlying it. All the technologies making up AJAX are mature and stable. AJAX is the foundation for many new applications on the web like Google suggest, Google Maps, some features of Flickr and Amazon’s A9.com.

Mobile Application Development Models and Their Shortcomings
From the above discussion and from the articles referenced , we can see that AJAX clearly solves two problems,  namely a superior UI and a standardized form of data retrieval. These two problems also apply to mobile devices and by extension, AJAX addresses them as well. However, I believe that it does far more! Specifically, it solves the following problems in the mobile context:

1. The problem of market fragmentation
2.  Porting woes (specific to downloading applications like those built on Java ME)
3. Application distribution without ‘walls’

Additionally, it has the developer community behind it – which is a significant plus!

Let's consider existing mobile applications development. There are two principal ways to categorize mobile applications – Browsing applications and Downloading applications. There are others (like Messaging applications, SIM applications and embedded applications) - but a vast majority of the applications we see today fall under downloading or browsing applications.

Browsing applications: Browsing applications are conceptually the same as browsing the web but take into account limitations which are unique to mobility (for example - small device sizes). Similar to the web, the service is accessed through a microbrowser which uses a URL to locate a service on a wireless web server. The client is capable of little or no processing.

Downloading applications (Smart client applications): In contrast to browsing applications, downloading applications are applications that are first downloaded and installed on the client device. The application then runs locally on the device. Unlike the browsing application, a downloaded(or smart client) application does not need to be connected to the network when it runs. Downloading applications are also called ‘smart client’ applications because the client(i.e. the mobile device) is capable of some processing and / or some persistent storage (caching). Currently, most Java based games are downloaded applications i.e. they are downloaded to the client, require some processing to be performed on the client and need not be always connected to the network. Enterprise mobile applications such as sales force automation are often also examples of smart client applications.

Java ME is the most common mode of developing downloading applications and XHTML is most common way of developing browsing applications. Let's elaborate on the problems I have outlined before and then discuss how AJAX will solve them – potentially making XHTML and Java ME less relevant.

Problem One - Market fragmentation
Mobile applications are primarily consumer applications. The mobile data industry is an emerging industry. As with many industries in this phase of evolution, it is fragmented. To be commercially viable (especially considering the need for the network effect ), consumer applications need a large target audience.

This can come about either by a single proprietary standard such as BREW from Qualcomm (which obviously has its disadvantages) or through open standards not controlled by any one entity with few industry barriers.

To illustrate how market fragmentation affects commercial viability of a new service, I often recommend the following approach (most of the figures can be easily obtained from the web). The idea is to think in terms of ‘concentric circles’ in trying to find out the target audience for your application. 

Here's a sample set of steps I use:

1. What is the population of the country where you are launching your application?
2. What is the percentage of handset penetration amongst this population?
3. Which operators are you targeting within this population? (Most countries have more than one mobile operator)
4. Which handsets are you targeting within this population (not all operators support all handsets)?
5. What is the technology of deployment for example Java, SMS, WAP etc?
6. Does the application have any special technology needs such as location-based services? How many people have handsets equipped with this technology?
7. What does a segmentation analysis of the subset reveal? (Simplest segmentation is male/female. Prepay/postpay etc)
8. What are the channels to market for the segments we are targeting?
9. What proportion of this subset do we expect to hit and convert to customers based on our marketing budget? (i.e. the conversion rate which can be typically 2% )

This will give you your target audience, and this target audience times number of potential downloads per month should give you an idea of your monthly revenue. This could then be tied against your cost base including your development costs, porting costs etc to arrive at a more tangible picture of success/failure of the new service.

The above methodology illustrates the problem of fragmentation and it implies that very few mobile services are profitable today. Thus, we have a proliferation of ‘broadcast content applications’ – e.g., ringtones, pictures but very few utility applications at a mass-market level.

Problem two - Porting woes
This problem is specific to downloaded applications (and more commonly Java ME). Write once run anywhere is a joke in the mobile context! – and through no fault of Sun. Consider the case of mobile games (a downloaded application) typically developed using Java ME.

First the good news...

• Carriers such as Sprint and Vodafone report that mobile games and other data services now account for roughly 10 percent of their annual revenues;
• Industry consulting firm Ovum notes that there are now more than 450 million Java-enabled handsets globally, in addition to the 38 million and 15 million BREW- and Symbian-enabled handsets;
• Mobile-game publishers racked up $1.2 billion in global sales in 2004 and expect an even stronger year in 2005 as more and more consumers discover the tiny gaming consoles already in their pockets.

BUT then the pitfalls ..

• Game porting generally requires developers to adapt to differences in screen resolution, processor speed, memory thresholds, and sound capabilities, all of which can vary wildly from device to device.
• For publishers, this can not only exponentially increase game development and asset creation time, but can also cause them to miss critical time-to-market windows in a hyper-competitive industry.
• As an example, imagine that you are a mid-sized game publisher with 30 games in your portfolio. To make your games available worldwide in five languages and on only 50 devices, you would need to create 7,500 different builds. At $2,500 per build, you would require a budget of nearly $19 million simply to handle porting.

This limits the business model severely and very few mobile games are profitable. (Author's note: original source for this section as per my blog Porting – the big barrier to entry with acknowledgements to Sameer Bhatia as per the blog)

Problem three - Application distribution without walls
The predicament of using Java ME as per the preceding example shows that it’s not enough to merely set up a community process as Sun has done (which works fine as far as the technology is concerned). The technology and the applications built upon it must remain homogeneous and interoperable to enable the network effect and gain critical mass. The fewer the ‘choke points’ for a platform, the better it is for the industry as a whole.

Why Will AJAX Replace Java ME and XHTML As the Preferred Mobile Development Platform?
Can AJAX solve the preceding problems? In my view, yes. AJAX is accessed through the browser. There are two ways a customer can get the browser – either the browser can be pre-installed on the phone by the manufacturer or it can be installed as a separate application

Anyone can download a browser for a smartphone as this Opera link shows for series 60 phones. This means all customers can potentially install their own browser and if enough people do, then we have critical mass with few ‘choke points’ – such as specific restrictions created by mobile operators. In other words, a means to bypass the walled garden.

Further, AJAX offers a superior user experience and already has the developer community supporting it. The possibility of attaining critical mass (due to fewer choke points) means more chance of monetizing the application – leading to a virtuous circle of better applications.

Java ME as it stands today is seriously flawed (not the technology but the business model). XHTML will be an ‘also ran’ because AJAX will offer a superior user experience. Hence, my belief that AJAX will be the preferred platform of choice for mobile applications at the expense of Java ME and XHTML.

Supporting Notes

• I have said ‘preferred’ and not ‘replace’ i.e. I don’t expect AJAX to replace any technology
• AJAX won’t solve all problems. You still need to create a service which is useful for mobile customers
• AJAX is not the only attempt to create a better interface. There have been others with limited success but they are not across the industry(or are proprietary). For example mobile SVG from bitflash , superscape’s swerve technology for 3D gaming (which is the implementation of JSR 184 - Mobile 3D Graphics API for Java ME) and Macromedia (now Adobe) Mobile
• Not a lot of people are actually browsing the mobile internet. Although WAP usage shows phenomenal growth, these figures include the use of WAP as a transport mechanism – typically for downloading content. In other words, every time you download a ringtone, you implicitly create a WAP page impression. I suspect the real figures used by consumers to actually browse the mobile internet are very low
• Very few mobile operators have tried to engage with the developer community as such. Practically the only example I can think of is source o2
• The plight of small developers can be illustrated from my discussions with a Korean vendor when I spoke at imobicon in Seoul. The vendor had finally managed to get his game listed on a UK portal. However, that was because a Korean aggregator managed to get a deal with a UK aggregator. Thus, he now had two aggregators and one operator taking a slice of revenue! Leaving him with very little. A sorry state of affairs. Surely, there must be a way to create and distribute applications globally i.e. you write for the browser and anyone who uses that browser can download and run your application
• Mobile operators often argue that they handle billing and location services etc. That’s fine – but let’s first worry about getting the numbers. Also, billing comes at a cost and there may be better billing mechanisms on the web.

Summary
To recap, mobile applications are primarily consumer focused. They need critical mass. Currently, the market is fragmented and the current commercial model is broken. AJAX offers a potentially better solution in comparison to the incumbents (Java ME and XHTML) due to a combination of fewer potential choke points because of its distribution mechanism. The economic models do not favor Java ME and AJAX offers a superior user experience to XHTML. It has the support of the developer community.

Finally, note that I say AJAX will be ‘preferred’ model and not the ‘only’ model. I don’t expect AJAX to replace either Java ME or XHTML.

For a daily dose of Ajit Jaokar, readers might like to visit www.futuretext.com.