I have used the image of the ‘Leonardo in the walled garden’ for this blog from its inception.

The perplexed Leonardo in a walled garden – symbolizes everything this blog is all about

Originally, the image was meant to be used on the cover of my first book OpenGardens, but for various reasons, we did not end up using it

The Leonardo represents garage/grassroots developers i.e. the people who have the talent and the courage to create new vistas (applications). However, the Mobile data industry, as I understood it then, (and to a large extent even now) .. is not an optimal place for the innovator due to its fragmented, proprietary standards and walled gardens approach.

Hence, the perplexed Leonardo .. painting his Mona Lisa within the confines of a walled garden.

On a more serious note, that’s the reason why this blog advocates open standards, non proprietary technologies and the ethos of the web(and will continue to do so!).

As is typical of Dion, his blogs contain a lot of information in simple bullet point form

Two things strike me about this blog: firstly Ajax is only 18 months old! – and yet it has become so much mainstream. Secondly, as I have said before in the case of SQL, popular web technologies morph into unintended applications i.e. Ajax was never originally meant to do what it is doing now!.

With that extended usage comes complexity and a steep learning curve. This is largely the point of Dion’s blog. Expect more of Ajax from both Dion and I since Ajaxworld expo starts at Santa Clara next week – and we are both speaking there! Please email me if you are attending Ajaxworld next week and let’s catch up(ajit.jaokar at futuretext.com )

Meanwhile, have a read of Dion’s blog .. here is a snippet from the blog. The full link is HERE

Ajax Is More Involved Than Traditional Web Design and Development. The loss of HTML user interface conventions, the almost limitless potential for hidden or latent functionality, the programmatic creation of page elements instead of declarative, and other intrinsic aspects of the Ajax approach throw out much of what we know about Web design and development. Web designers must much more deeply understand the capabilities of the DOM, Javascript, CSS, and how the browser renders graphics, layouts, and elements. Developers find testing both difficult and tedious. Though tooling is continuing to improve across the board, it will take years for the industry to develop best practices, lore, patterns, and shared knowledge to make Web application development straightforward. Huge kudos to folks like Yahoo!’s Bill Scott for trying to fix many of these problems — particularly the loss of GUI standards — by actually moving the state of the art considerably forward with things like the Yahoo! UI Design Patterns library. The bottom line: Ajax development, at least for now, usually takes quite a bit longer than traditional Web development and requires a higher level of skill.

I believe Mobile Ajax applications are a new and emerging class of applications, and this service is a trendsetter of a new wave of Mobile Web applications.

Here are some of the aspects of the service which showcase the power of this new class of applications:

a) The application is completely browser based – no software to install on the client

b) It uses the power of Ajax to manage data, reducing latency , loading time and increases response time

c) It provides a better user interface using a web application that is closer to a native/PC based application than a typical web application

d) Distribution is via the web (but the application can also be distributed by the carriers)

The application itself provides a simple but useful service. In a nutshell, the SoonR service lets mobile users access their computers from any Internet-connected mobile handset.

A SoonR service runs on the desktop. People can use their Desktop to search and access documents, images, Organizer for email, scheduling, contacts and ‘SoonR Talk’ for mobile VoIP.

The key aspect here is; all this information is available to any mobile client without the need of synchronization or any additional software on the client. Much of this is achieved through the power of Ajax, very much on the lines of Mobile Web 2.0 which I have been talking about in my book.

To recap from the first principles of Mobile Ajax: The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This improves interactivity, speed, and usability and a dramatically better user experience.

Contrast this with the WAP/XHTML.

We have a relatively poor user interface in a WAP application. The disadvantages of a WAP application are:

• Limited style and feedback elements in the UI

• Lengthy lists of menu options

• Slow load times for pages and large pictures

• Lack of screen real-estate for more dynamic menus or help screens

• Incessant blinking as page elements are refreshed

On the other hand, one of WAP’s main advantages is: It is browser based.

Hence, unlike Java ME or other similar applications which needs the application to be downloaded to the mobile device (bringing with it all the complexities, compatibility issues etc), WAP offers some advantages.

The power of the Mobile Ajax approach is: it gives the best of both worlds.

Let us explore these ideas in greater detail.

The aesthetics of the interface itself looks slicker i.e. much more ‘native’ with moving menu bars, icons etc.

But the power of the architecture becomes clearer when you move beyond the ‘pretty face’.

With Ajax, the UI is presented and while the data is loading, users get a nice animated indicator. With WAP, until the server responds with all the data requested.

Often there are dozens, if not hundreds of items in the list. The application will display the main interface quickly while the folder list is being populated in the background (just as you would expect an Ajax application to work). During loading, a clear prompt with an animated progress indicator lets the user know that an operation is in process.

When the loading is complete, the information is displayed without a round-trip screen refresh to the web servers. This animated indicator will re-appear in other parts of SoonR as potentially lengthy operations are executed. By presenting the interface first, the user can start to explore and to understand what is available thus minimizing the time lost waiting for data to load.

Now, take the case of loading pictures.

Pictures in your folder can be viewed with transitions and an active menu. Entering the slide show, the selected picture is full screen and a navigation tool appears in the upper right. If the user doesn’t provide any input after a few seconds, the navigation tool will hide itself and the slide show will progress with smooth transitions between the slides. If you see a picture of particular interest, you can choose the “magnifying glass” icon in the navigation tool and get additional functionality for zooming and panning the picture. To the right, we see the picture with a high level of zoom, the zoom and pan control active.

Ajax techniques enable retrieval of the photo in the background for smooth transitions.

There are also other features leveraging Ajax such as ‘live filters’ which also helps to dynamically reduce the size of the list to a more manageable amount.

Similar to a resident application, the list is filtered as the user types. SoonR implements this functionality across three areas:Contacts – In Outlook organizer integration, Talk – for Skype buddies, Search – for live searches across multiple computers supporting Desktop Search applications from Google, Yahoo, X1, Windows, and Spotlight on the Mac.

The SoonR service is mature in terms of user base since it has been tried on over 500 different devices in over 140 countries. However, the Ajax element is new. The user can either get Opera 8.6 downloaded to the phone or the user can also use any other Mobile Web-browser (WAP version > 1.x). If the user is not using Opera 8.6 or above, the user will get a standard XHTML based interface.

Currently SoonR is available free for charge from www.soonr.com

Any comments welcome.

The SoonR service shows a trend which I believe is significant (and one which I have highlighted before) i.e. mobile browsers and rich mobile browsing applications (like the SoonR/Mobile Ajax case above) will be significant drivers of the new Mobile Web.

If there are any more examples/launches of mobile Ajax, I am happy to cover them. Please contact me at ajit.jaokar at futuretext.com

Having been involved in creating mobile services for a few years now, I believe AJAX will replace both J2ME and XHTML as the platform of choice for developing mobile applications.

In this article, I will outline my reasoning.

Before I do so, a caveat – I believe that mobile web 2.0 is far more than ‘AJAX on mobile’. Essentially mobile web 2.0 involves applying all seven of the web 2.0 principles to mobility. I will be discussing mobile web 2.0 in subsequent blogs. For a more complete discussion see my article on mobile web 2.0.

Here, I am discussing AJAX only i.e. only one facet of web 2.0.

Overview

In this article, we will discuss

1) What is AJAX (an overview)

2) Current Mobile applications development models

3) Problems the industry faces (in other words shortcomings of the current mobile applications models) and finally..

4) Why AJAX will replace J2ME and XHTML as the preferred development platform

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 was not 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 it’s 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.

In this sense, AJAX is ‘asynchronous’ because 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 is a momentum behind AJAX at the moment. Developers are already familiar with the technologies underlying AJAX. 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 applications 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 standardised 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.

a) The problem of market fragmentation

b) Porting woes (specific to downloading applications like those built on J2ME)

c) Application distribution without ‘walls’

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

Lets consider existing mobile applications development. There are two principal ways to categorise 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.

J2ME is the most common mode of developing downloading applications and XHTML is most common way of developing browsing applications.

Let us elaborate on the problems I have outlined before and then discuss how AJAX will solve them – potentially making XHTML and J2ME 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 it’s 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. A sample set of steps I use is as below

a) What is the population of the country where you are launching your application?

b) What is the percentage of handset penetration amongst this population?

c) Which operators are you targeting within this population? (Most countries have more than one mobile operator)

d) Which handsets are you targeting within this population (not all operators support all handsets)?

e) What is the technology of deployment for example Java, SMS, WAP etc?

f) Does the application have any special technology needs such as location-based services? How many people have handsets equipped with this technology?

g) What does a segmentation analysis of the subset reveal? (Simplest segmentation is male/female. Prepay/postpay etc)

h) What are the channels to market for the segments we are targeting?

i) 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.

Thus, 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’ – ex 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 J2ME). 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 J2ME.

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.

The predicament of using J2ME 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.

We will discuss this more in the next section(where we talk of how AJAX could address this problem).

Why will AJAX replace J2ME and XHTML as the preferred 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

This means, all customers can potentially install their own browser and if enough people do – 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 monetising the application – leading to a virtuous circle of better applications.

J2ME 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 J2ME and XHTL.

Supporting notes

a) I have said ‘preferred’ and not ‘replace’ i.e. I don’t expect AJAX to replace any technology

b) AJAX won’t solve all problems. You still need to create a service which is useful for mobile customers

d) 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

e) 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

f) 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 sad 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

g) 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.

Conclusions

To recap, Mobile applications are primarily consumer focussed. 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 (J2ME and XHTML) due to a combination of fewer potential choke points because of its distribution mechanism. The economic models do not favour J2ME 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 J2ME or XHTML.