In spite of the issues mentioned on the previous page, I believe that Ajax will lead to resurgence in browsing applications and will overcome many of the problems we now face because

a) The level of abstraction shifts to the browser. Browser based applications are relatively easier to update and can be used across operators. This leads to a greater target audience for the application. Developers could have access to a critical mass of customers to make application development worthwhile. The browser also reduces fragmentation by providing a universal client(i.e. one client to for all application types as opposed to a separate client for each application type)

b) Ajax is making the browser experience and data management capabilities better

c) Developers are supporting Ajax on the internet and by extension the mobile internet. Industry heavyweights are shifting their support to Ajax(for example IBM’s support for Open Ajax )

d) The concept of widgets is not new. It has been around for some time on the Mac. In this context, a widget is a downloadable, interactive software object that provides a single service such as a map, a news feed etc. Ajax provides a mechanism to implement widgets on browsers.

e) Finally, Ajax could foster the creation of the widget authoring market similar to Apple widgets or Opera widgets

The resurgence of browsing applications is not new. Other bloggers such as Russell Beattie have also spotted the same trend.

However, I believe that Ajax will take it one step further by providing a combination of richer experience, bigger target audience, data management capabilities and widget authoring capabilities.

In addition, the support of developers - both on the web and on the mobile internet - could lead Ajax to morph into a system with greater capabilities than we currently envisage.

THE EVOLUTION OF MOBILE AJAX AND THE SIGNIFICANCE OF OPERA’S ANNOUNCEMENT
Part one of the article was written in context of the Opera platform’s support for Ajax .

As per it’s definition, the Opera Platform comprises:
- Opera web browser running in full-screen mode.
- An AJAX framework for running multiple widgets/applications.
- Access to the phones native functionality through an abstraction layer

Opera already supports AJAX in the 17 million shipped mobile browsers in 2005. This means that - with the existing Opera browsers you can use desktop AJAX services such as GMail, Google Maps etc. This much is quite apparent and has been covered by other analysts before.

However, there is more to the announcement than merely support for Ajax.

The significant elements are

1) The Opera Platform is the first mobile AJAX framework. It also has a corresponding browser framework. However, unlike other frameworks such as Zimbra (zimlets) and Backbase it is fully designed for mobile devices – in the sense that it uses the same codebase on the browser and the mobile device. With minor configuration changes, the desktop/browser widget could also run on the mobile device Thus, from a developer’s perspective, there are more than one ways to monetise the widget(desktop, mobile and browser). This factor, coupled with the large installed base – makes the Opera announcement significant from the mobile applications development standpoint

2) Widgets could call other widgets. Complex applications could thus be developed from simple, browser based components

3) The Opera platform allows access to device APIs
To appreciate this concept, we have to consider the architectural drawbacks of the browser model (corollary ‘a’ as discussed above)

The browser model is document centric i.e. based on mark-up languages. In contrast, downloaded and native applications are application centric since they are based on a programming language.

To be really useful, any mobile applications development model must have the capacity to access data elements that are tightly coupled to the device itself. These include the telephony API, phone book, text messages, the messaging API, call records, the SIM card, the calendar, the Bluetooth stack, media player, the file system and so on.

Applications running on the phone can access these services through APIs. For most part, applications running on browsers could not access these functions(with the exception of a few proprietary solutions).

The opera platform is a browser based programming environment that abstracts the native device APIs through a set of Javascript APIs and thus provides developers access to the low level functions on the device from the browser
-
This is VERY significant and has the possibility of creating richer browser based applications.

Knowing what we know now about Ajax, widgets etc – lets return back to the example of ‘lawn bowls’.

The power of Ajax lies in it’s ability to create widgets at the desktop level. Using the Opera platform approach, the same widget could be used for the mobile device. These widgets have the ability to harness revenue from the long tail. In the commonwealth games scenario, it should be possible to create a low cost widget catering for the lawn bowls fans. These widgets could run on the desktop browser as well as the mobile browser(using the Opera approach outlined above). There in lies the significance of the Ajax approach!

One would argue that this approach is not a purely browser based approach (because the client in this case needs some form of ‘software’ running locally). Note that – the platform approach is not the same as using a plug-in because a plug-in can be downloaded. In contrast, the platform is a part of the device itself and is installed by the manufacturer.

I agree that this approach is not ‘pure’. However, developers will have to deal with few (perhaps less than ten) such platforms as opposed to the ‘hundreds’ of variants that they have to currently contend with (see notes below).

Nor is this approach ‘open’ – in the sense that an application programmed on one platform will only run on that platform.

Nor is it ‘endorsed’ by OMA as far as I know. The whole issue is still also too early for the mobile operators since it has yet to flow up from browser vendors to the device manufacturers and only then to the operators. However, the W3C mobile web initiative may also be a standards body in this case in collaboration with OMA.

Finally, the approach is still not ‘rich’ enough for certain types of applications such as games( see more on games below).

Nevertheless, it’s a huge step forward because we now have a much more uniform playing field across operators.

Historically, popular technology has often morphed depending on industry support. Take the humble old 'SQL' . Every vendor(such as Sybase, Informix etc) - introduced a procedural version of SQL (PLSQL in case of Oracle). SQL and PLSQL are a contradiction in terms because SQL is set based (and thus by definition not procedural) whereas PLSQL is procedural.

However, ‘procedural’ SQL exists because there was an industry demand (read developer support) behind it. We are witnessing the same phenomenon here with Ajax.

NEXT PAGE: Walled Gardens, Open Gardens in the Context of the Above Approach

• AjaxWorld Magazine: AJAX for Mobile Devices Will Be the Hallmark of "Mobile Web 2.0" in 2006
• Ajit Jaokar's Mobile Web 2.0 Blog: "Web 2.0, Blind Men and the Elephant"