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.
Advertisements
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