perspectives

A bridge too far – why Google’s Docverse acquisition might not be a good idea

A bridge too farGoogle recently acquired a company called DocVerse. DocVerse  offers a Microsoft Office plugin that ostensibly brings Google Docs-type collaboration to these hitherto static desktop application.

A number of blog reactions have emerged lauding the move as a “shot by Google at Microsoft” and a mechanism to “bridge the gap” between desktop office software (specifically Microsoft Office) and browser-based online office services (Google Docs). The rationale is that users can use the Office+Docverse combination to edit and collaborate on documents on the desktop and Google Docs to do likewise in the browser while Docverse, in addition, serves as the channel to move the document across the desktop and the web. This would give users the choice and flexibility of working either on the desktop or in the browser and allow them to seamlessly switch from one platform to the other.

Lets take a look at how this would presumably work.

In its current (pre-Google) incarnation, Docverse consists of two parts: a client plugin which wraps around Microsoft Office and enables collaboration (co-editing, version management) and a browser-based version where the same document can be viewed (but not edited) within a web page. Each time a user updates a  shared document within Microsoft Office, the Docverse plugin pushes the document to the server and updates the browser-based rendition to reflect the latest changes. Users can add annotations/notes in the browser version but not modify the actual document content itself.

Now, the rationale of the Google acquisition seems to be that the browser-based version of Docverse can be replaced with Google Docs – this would allow users to edit the document within the browser and presumably these changes would be updated in the desktop version essentially implying that the sync would now be two-way (“web to desktop” as well as “desktop to web”) instead of the one way (just desktop to web) version that Docverse has currently.

While this sounds good in theory, there is one small design aspect that renders this argument non sequitur…

There is an intrinsic distinction in the way Google Docs and Microsoft Office handle documents internally – without getting into technical minutiae,  the crux of the point is that while Microsoft Office documents have a rich and complex format (both the “old” binary representations – doc, xls, ppt and the new Open XML formats – docx, xlsx, pptx), Google Docs essentially converts these documents to plain HTML. While this might seem like a simple superficial distinction, the fact of the matter is that this difference is the reason why Google Docs don’t “play well” with Microsoft Office. Try importing any Microsoft Office document into Google Docs, make a change and export it back to the original Microsoft Office format – you will find that this “round trip”, more often than not, significantly destroys document data and formatting. Once a Microsoft Office document is converted to HTML, it is almost impossible to revert it to back to the original format without fidelity loss of some kind.

Given this aspect, in the above scenario, each time a “round trip” happens between the desktop and the browser versions and back, it would be a lossy exercise that would expose the gulf between Microsoft Office and Google Docs in as stark a manner as you can imagine. In the current architecture, this chasm is quite simply too far to bridge!

Of course, this is not Docverse’s fault in any way as it has no role to play in the workflow for converting Microsoft Office documents to the Google Docs document format and vice versa (and hence cannot improve it in any way) – in fact, writing an office plug-in that leverages Google’s APIs to import and export documents to/from Google Docs is, in itself, almost trivial (many others such as the likes of Offisync have built similar offerings) and I suspect that, if it so chooses, Google could have developed something like this in a matter of days. The point is that Docverse is in no way a panacea to the Microsoft-Google gulf  and if anything, will only accentuate the stark incompatibilities between the two worlds .

What does makes this interesting though is that the Docverse team seems to think otherwise as demonstrated by this quote on their blog post – “Our first step will be to combine DocVerse with Google Apps to create a bridge between Microsoft Office and Google Apps.” If this is indeed true, we would really to like to see how they pull it off!

Post Script: We would typically not make statements on events/activities where we have no locus standi – the only reason why this specific acquisition is interesting to us is that Docverse is very similar to our original Live Documents offering that we had developed more than three years ago (this blog post summarizes how we have evolved since) – the Live Documents plugin could allow Microsoft Office users to collaborate on their documents in real-time in a similar manner but unlike Docverse, we never stored user documents on our servers (our contention was that people would be loath to store their documents on a third-party server) and despite this, our plugin was smart enough to track changes and merge them into all document instances without any conflicts.

Standard
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
perspectives

Our journey from a Microsoft Office plugin to a Microsoft Office replacement…

We first started working on Live Documents around two and a half years back. At that point in time, Google Docs was starting to make news – AJAX-driven browser-based applications that offer users with an alternative to the desktop juggernaut Microsoft apps.

The core benefit posited was that in this web-based paradigm, collaboration becomes much easier than the e-mail attachment mechanism for sharing and collaborating on Microsoft Office documents.

While this made sense, given our expertise and experience with Microsoft technologies and specifically with Microsoft Office, we set out to prove that just to acquire collaborative capabilities, there is no need to rebuild browser versions of the desktop apps – instead, it is possible to “web-enable” Microsoft Office and bake in collaboration into the desktop apps themselves.

Through some niftily-designed plug-ins, we managed to achieve our objective and built a solution that made Microsoft Office documents collaborative – multiple people could open a document both in real-time or asynchronously and all changes made by one user would be merged into all other document copies ensuring that all document instances were up-to-date – users could also chat with one another in real-time within Microsoft Office itself.

Our early users loved our application and we got several rave reviews. One such review – Live Documents is Powerful Stuff – by Michael Arrington of Techcrunch fame, made an intriguing point   – would it be possible for us to integrate our solution with browser-based applications like Google Docs or Zoho so that users could work on their documents both on the desktop and in the browser.

Now, to our knowledge, something like this was never attempted before but we felt that this made a lot of sense and started exploring these integration possibilities. The first thing that hit us when we looked at the current crop of online applications was that all of them, without exception, were anaemic versions of the desktop equivalents – not only were they poor in terms of features and performance, more importantly, round tripping documents with these services (i.e. edit documents in the browser apps and export/save back to Microsoft Office) was a “lossy” exercise – documents would significantly lose fidelity. Also, the APIs that the browser-based applications provided were rather poor and didn’t give us the level of control and granularity that we were looking for. We conducted a straw poll internally and decided that rather than build a bridge between our Office plug-in and these browser-based apps, we could almost as easily build our own suite of browser-based applications to complement the desktop software.

We put up a couple of small teams and quickly came up with prototypes of AJAX-driven, browser-based applications for word processing, spreadsheets and presentations. All of these were significantly better and feature-rich than the likes of Google Docs but as we built 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 with Javascript, we would have to literally jump through hoops to make our application work across different browsers was also frustrating. That is when we chanced upon Flex and to cut a long story short, ported our applications to this new technology platform (PS: We will document our experiences with Flex in a separate post shortly)…

Along the way, Adobe released AIR and this was a God-sent for us as we could now essentially build out software versions of our applications too without depending on Microsoft Office to serve as the desktop participant. Live Presentations, which we released for general production use, earlier this month is the first application from our stable – one significant attribute of Live Presentations is that without compromising on features, we have released feature-par software and browser versions which offer the exact same user experience.

So, as it turned out, we started off attempting to “web-enable” Microsoft Office and instead (and perhaps with a smidgeon of irony!), ended up building a complete replacement! It has been an exciting journey so far and now that we have gotten to the point where we have built out our applications enough to drop the “beta” tag, the future is going to be even more interesting!

Standard
announcements, product announcements, updates

Announcing Live Presentations

We are delighted to announce the immediate general availability of Live Presentations – the first application in our Live Documents suite.

To take a look at our take on “Presentations upgraded for the Internet age”, see our product overview page here or better still, sign up for a free account and try it for yourself here.

Live Presentations is presentation authoring software that you can use on the desktop or in the browser, whether you are online or offline – our approach merges the richness and responsiveness of desktop software applications with the collaborative capabilities of browser-based services…

You will find Live Presentations has most of the features of the apps that you use currently such as Microsoft PowerPoint but gives you unprecedented choice and flexibility in terms of creating, editing and sharing your documents. But we are not trying to just bring PowerPoint to the web – we are also trying to diligently look at the current application landscape and try to fix niggling issues that users have been complaining about.

For instance, one major deviation from PowerPoint is that we don’t have bullets in Live Presentations – like many others, we believe that the default template of PowerPoint where a ton of content is just broken out into bullet points is a terrible paradigm in terms of what viewers can assimilate and comprehend. By leaving out bullets, we think users will be forced out of their inertia/stupor of believing that listing bullets is the only way to create a presentation and hopefully help them come up with ways to communicate, rather than just present!

If you feel that having bullets points is a critical aspect that you cannot live without, do let us know about it in our User Voice forum – http://livepresentations.uservoice.com

Cheers,

The Live Documents team

Standard
design, perspectives, updates

Power without Point?

Admittedly, Microsoft PowerPoint is a powerful tool – while its essential nature of being a standalone desktop software has not changed over the last twenty years, over this long period, like a rolling stone gathering moss, PowerPoint has gone way beyond it’s original premise of providing business users an elegant and user-friendly way to communicate their thoughts, ideas and plans.

Unfortunately, most of these advancements are to wit, “Power without Point”! If you were to peel off each feature within PowerPoint and weigh its utility in terms of how this aspect enables presenters to tell a better story, more often than not, you will find that they detract from rather than enhance the presentation in terms of clarity or even from visual appeal.

For instance, Microsoft has added a lot of templates but they probably didn’t get the memo that these templates went out of style 20 years ago! It boggles the mind as to why a presenter would feel that typewriter sound accompanying an animation is something desirable!

The biggest culprit in all of this seems to pick off where their real-world counterparts left off – BULLETS! Like in the real world, bullets in presentations cause major damage! How? For one thing, it promotes sloth in presenters – take an off-the-shelf template slide with a title and 10-15 bullets and blindly pencil in dozens of items to fill up the slide giving the illusion of cogent content but in reality, bombarding poor audiences with dense slides that confound or bore them beyond redemption…

Therefore, for our upcoming Live Presentations application, we have chosen to competely take out the bullets feature! The idea is to prompt users to think about telling their stories in ways that resonate with audiences rather than fall into the old trap of using bullets as hooks to cover up other inadequecies.

Give it a spin – you might just find it to be strangely liberating!

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