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.
For the Live Documents team.

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!

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 –


The Live Documents team