perspectives, RIA

Taking Adobe AIR beyond Twitter clients…and why AIR matters.

Adobe just announced that the number of AIR runtime installs has crossed 100 million and this milestone achievement has been echoed by several others. Several folks including thought-leaders like ReadWriteWeb have rightfully questioned the validity of this claim, perhaps not so much in terms of challenging the absolute numbers themselves but in terms of judging the impact that AIR has had so far on the general application landscape.

Our own take on this is that despite providing such a staggering data point as proof of general acceptance and availability, the story so far for AIR has been a case of unrealized potential. The reason for this does not have as much to do with the merits of the platform itself as it does with the nature and quality of the applications that have been built on top of AIR.

The most popular AIR application seems to the eBay desktop which recently crossed the 1 million installs milestone. If the most popular AIR app accounts for just 1% of the runtime downloads, it means one of two things – there is a long tail of other AIR applications that have collectively lead to the spread of the runtime or there is another channel beyond application-propelled installs that has lead to the spread of the runtime. While I would have loved the first scenario to be true, the latter scenario is unfortunately the more likely possibility. Given that Adobe bundles the AIR runtime with every install of both Adobe Reader 10 and CS4, both enormously popular applications, a big part of the 100 million figure is likely to have come from this source.

Apart from the eBay desktop, the most popular AIR applications are Twitter clients like Thwirl and TweetDeck. While Twitter is an interesting application, it breaks my heart to see AIR being relegated to this niche! Firstly because, notwithstanding its growing popularity, Twitter is still a niche application in many ways and secondly, AIR Twitter clients add very little incremental value to the original browser-based Twitter experience.

The problem really has been that there is no ground-breaking AIR application that has proven to be so compelling that it has swept popular imagination both in terms of installs as well as mindshare. One of the reasons for this is that Adobe itself has not produced any path breaking AIR application thus far – Buzzword was ostensibly acquired to serve as a proof-of-concept showcase for Flex and AIR but to date, Adobe has not released an AIR version of Buzzword – Buzzword would have been an ideal candidate for demonstrating the power of AIR for two reasons – one, people can relate it to the desktop applications that they use today like Microsoft Word rather than the web applications that they use today and secondly, it would have provided a great opening to demonstrate the seamless online-offline sync capabilities of AIR as well as desktop integration capabilities. I am not sure why Adobe has still not released AIR versions of Buzzword – is it because the online-offline sync issue is a particularly tough nut to crack or because they do not want to be seen as competing with other software developers (AIR’s primary audience) by aggressively releasing AIR applications of their own? I guess only the powers-that-be at Adobe can answer this…

So what does AIR mean to us and where do we fit in all of this?

To us, AIR is not just about bringing web applications to the desktop – that is a facile use case, rather AIR provides us with a mechanism to bridge the gap between the desktop and web in terms of user expectations as well as user experience. People expect desktop applications to be fast and responsive and to function whether they are connected to the Internet or not and equally, they expect web applications to be lightweight and collaborative. AIR allows us to develop applications that meet both sets of imperatives at once – offering a “Software & Service” application experience that merges the best attributes of the desktop and the web without forcing user to choose one over the other. This Software & Services experience is something that no other technology, past or present, has been able to facilitate thus far.

Microsoft is espousing a Software + Services (S+S) world view that is attempting to envision something similar but unlike AIR which is available today, S + S will be fully unfurled at some unknown time in the future and secondly, unlike the Microsoft view where the services part is a poor second cousin to the primary desktop participant (an architecture motivated no doubt by Microsoft’s anxiety to perpetuate its desktop hegemony), in the AIR-propelled Software & Services world, the desktop and the web are equal partners. In the Microsoft world, the service version is a stripped-down emasculated version of the desktop software but in the AIR world, the functionality available within the application is more or less the same irrespective of whether the user is using the browser version or the desktop version and whether she is online or offline. Equally importantly, the switch between the desktop and the browser or between offline and online modes is seamless – for instance, a user can create a document in the browser and at some later point, open the same document in the desktop version and continue seamlessly. Similarly, any change made to a document when offline is automatically propagated to the server the next time the user goes online.

One of the reasons why it has taken us longer than we would have liked to release our applications is that we have provisioned for leveraging all of AIR’s capabilities right at the get-go. For instance, our presentations application, Live Presentations is available as a full-featured AIR-powered desktop application as well as a browser-based service! It offers full offline functionality – users can create, view, edit and present documents even when there is no Internet connectivity – and all offline changes are automatically synced back to the server the next time the user goes online. As we progressively unfurl the other applications in our suite, we hope to do our little bit to evangelize AIR and its capabilities by action rather than by lofty proclamations!

Undoubtedly, AIR still has some way to go before it is generally regarded as a mature platform for developing desktop applications (for instance, the application sandbox is still unduly restrictive and if not handled with care, AIR is a bit of a memory hog) but rest assured, it is by far the most promising web-desktop bridge platform out there in the market currently!

(For the Live Documents team)

Postscript: One last bit about Twitter – incidentally, we have a neat feature within Live Presentations where you can use Twitter as a feedback channel to get audience questions and reactions during a conference type presentation. More details on how to do this here.

Flex and AIR…

Chanced upon an interesting blog post about Google Docs on ReadWriteWeb that evoked some equally interesting responses. One commentator in particular was very vociferous on how Google docs fails the cut in so many basic ways. To this, Ryan Stewart of Adobe came up with a riposte post that basically posited Adobe AIR as the solution for many of the noted shortcomings. While we at InstaColl are bullish on AIR, I am not sure if AIR can indeed be the “silver bullet” the way Ryan has laid it out to be. 

For instance, Ryan states how the AIR version of Buzzword can support pasting images saved in the clipboard and concludes that Google Docs can achieve the same functionality aspect by moving to AIR. Unfortunately, this is not quite accurate.

While an AIR application does have greater control/proximity to the system clipboard, the individual application must be specifically programmed to handle clipboard content intelligently. I am pretty sure that, in the event, Buzzword is supporting seamless pasting of image content the way Ryan has described, the Virtual Ubiquity/Adobe team has had to do quite a bit of custom coding to support this.

Clipboard content can be quite diverse and complex – ranging from simple text content to formatted text to html content to images to proprietary content like autoshapes (for instance try copying and pasting a square or oval from a PPT to a Word document…it should work. Now trying pasting the same content in a browser…this will fail – Microsoft can handle this because each of the participating applications (in this case PPT and Word) can recognize and render these objects correctly) but other applications cannot make sense of this binary clipboard content.

AIR might be able to tell you what type of content the clipboard currently holds but managing this content intelligently (which is the true challenge) is beyond AIR’s purview. So extending Google Docs as an AIR application might be simple but it will not support this type of clipboard handling functionality.

Ryan is right on one count though – if the native web application was originally a Flex/Flash application as opposed to an AJAX application, programming for features like this is a lot easier. Ditto for capabilities such as dragging and dropping an image into an AIR application – a Flex application can be easily tweaked to seamlessly embed the image into the content frame but in an AJAX application, the most likely scenario is that the image will replace the entire content (irrespective of whether the AJAX application is running in a browser or as an AIR-enabled desktop client).

The other comment in Ryan’s post that I found interesting was this:

“If you want to “beat” Microsoft and desktop applications with online apps, you need a platform that provides more functionality but stays true to the web.”

He is obviously referring to Flash/Flex/AIR and interestingly enough, using the same technologies as pivots, Buzzword also attempted to portray their application as the “First true word processor for the web”.

Now, we are using these technologies extensively too but I will be the first to admit that Flash is not a “web technology” by any stretch of one’s imagination – the fact that the Flash player is installed on most people’s systems and thus Flash content can be played within the browser is the reason why Flash is wrongly assumed to be a web technology. The browser’s presence in rendering Flash content/applications is entirely incidental – which is ironically the primary motive why we chose Flash instead of AJAX as our RIA paradigm.

In any case, this is just a matter of semantics and in the final analysis, end users just want compelling applications – it does not matter what is a true web techology and what is not….

– Sumanth (for the Live Documents team)