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.
Standard
design, perspectives, RIA, startup advice, technical

Why we chose Flex

When we started developing our web-enabled Office suite, we used AJAX as that was the technology du jour in circa 2006. We had quite a bit of experience both in Javascript as well as in XML handling and quickly came up with our versions of AJAX-driven, browser-based applications for word processing, spreadsheets and presentations. While these prototypes were comparable to the likes of Google Docs and Zoho in terms of features and performance, we saw that as just the starting point as our primary benchmark was the equivalent Microsoft Office application rather than these online office applications. Not only did we want to emulate all the useful features in these desktop applications that we reckoned users would care about but also build out new unique capabilities by virtue of “web-aware” unlike Microsoft Office which has never heard of the Internet!

But as we set about building out our apps, we soon hit a bottleneck – the problem was that we could only do so much with AJAX and as we attempted to build out progressively complex features, we found it increasingly tougher to do so using AJAX – in addition, the fact that each browser handled Javascript differently in subtle but material ways impeded our progress as we had to provision significant time to test and validate each application on every major browser.

Then we chanced upon Flex. We were intrigued about the possibility of using Flash as a development platform but we were not absolutely sure that firstly, we could achieve what we wanted to do using this platform and secondly, whether we had the technical expertise to do this given that we didn’t have a single member in our team who had ever done anything with Flash previously.

We began testing the waters by building out a prototype of one of our applications. It was not difficult to reach feature-parity with our AJAX versions – we managed to do so in a matter of a few weeks and what’s more, the user experience was miles ahead in terms of richness, responsiveness and the general look-feel (compared to other RIA technologies, Flex apps can provide a more tactile interface and user experience). Once we reached this milestone and were convinced that Flex had passed the litmus test, so to speak, we decided to go the whole hog and pivot our entire front-end strategy on Flex and ActionScript. In due course, Adobe released AIR and this complemented our web versions to a T. Now, as we look back on our journey of roughly a year and a half of using Flex, we are completely satisfied with the decision to make this switch and believe that we will go from strength to strength from this point on. Here are a few salient points that we want to highlight that might help other folks who are in the process of choosing an RIA platform for their products:

  1. In at least one dimension, Flex is the proverbial “Silver Bullet “: Flex/Flash is way better than Javascript in one major aspect – it is relatively agnostic to browser idiosyncrasies. This means that you need to spend far lesser time dealing with and validating that your applications looks and works the same across different browsers and platforms. There have been a number of attempts to create Javascript libraries to abstract out the browser complexities but none of these come anywhere close to Flash.
  2. Don’t worry about lack of prior experience with Flash: When we started off, we had zero experience with Flex or Flash but the learning curve was not difficult to traverse – both our Java and our C++ developers managed to be proficient Flex and Actionscript developers in a short period of time.
  3. Judicious and pragmatic use of off-the-shelf components: One nice thing about Flex is that there is a huge library of easily-available components that make it easy to get started and develop prototypes quickly. However, one needs to be careful to avoid being over-reliant on these components as they will not pass muster in a production environments in dimensions such as performance and memory management. Most of our applications started off having a lot of MXML components but over time, were replaced with targeted, lightweight, custom components.
  4. Flex and Java is a match made in heaven: If you already use Java, Flex is an ideal partner. We use Java on the backend and it was a painless exercise to replace the front-end with Flex without having to tinker with the backend. This combination also makes it easy to leverage useful open-source collateral such as BlazeDS(which we use to facilitate real-time co-editing).
  5. Lock-in with Adobe (the lack thereof): Another aspect that influenced our choice was the fact that while these technologies were developed by Adobe, they are now in the open-source realm. So there is no overt lock-in with Adobe – granted that there is still a subtle dependency in that the roadmap for these technologies is largely determined by Adobe but the fact that there is now a large eco-system and considerable community involvement in Flex dampens these concerns considerably.  The other nice thing in these tough times is that you don’t have to spend anything to use these technologies. In fact, our account with Adobe stands at $300 credit in our favor (we have not bought anything from Adobe but they graciously sponsored our code signing certificate!). Also, in general, we have developed our suite completely independently without depending on Adobe in any way.
  6. AIR makes it sweeter: AIR is, by some distance, the best desktop-web bridge technology platform out there in the market. We have spent quite a bit of time on Gears, Silverlight/WPF and JavaFX and can state with some authority that if you are developing a product that makes sense on both the browser and the desktop, Flex and AIR is the way to go.
In future posts, we will delve deeper into specific aspects of Flex and AIR and provide a more “geeky” version of some significant aspects.
Kaushal
For the Live Documents team.
Standard
RIA

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)

Standard