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)