Startup Lovely Charts Shares Insights into Building a Flex Application

A web startup company, Lovely Charts, announced its limited beta release and came to public last week. The site was developed using Adobe Flex. InfoQ spoke with Jerome Cordiez, the founder / lead architect, and learned the insight of how the Flex based Lovely Charts site was built.

Cordiez started with the introduction of what Lovely Charts does:

Lovely Charts is an online diagramming application, built in Flex, that allows for the creation of professional looking diagrams of all kinds, such as flowcharts, sitemaps, org. charts, network diagrams, wireframes, etc. For free.

Therefore, Lovely Chart is an online office productivity tool that is comparable to Microsoft Visio. Then, what the motivation behind this new product? Cordiez answered:

Basically, the initial motivation came from my own needs and frustrations. Like most people I believe, I don't do tons of diagrams, but I do draw occasional diagrams from time to time... So, I've been looking for tools to help me with it, and actually never really found one that really matched my needs, what decided me to work on this and investigate why I was not happy with the existing solutions and what was it that I was looking for.  From that process, I've established a list of what I would call core drivers behind the project, and simply got started with the first POC prototypes..

To learn more about the site creation process, InfoQ asked what were the major design goals. Cordiez gave three of them. This first one was:

Easy to use. I wanted a tool so easy to use that you could almost forget about drawing and just concentrate on WHAT you are trying to represent instead of HOW to draw it.

Then Cordiez went on giving his thought about the extend of easy to use:

And I am not only talking about usability and ease of use here, I'm also talking about creating good looking stuff with no effort, and no pre-required design knowledge, because the app would be there for that.

Therefor the second design goal was:

Sexy. This might sound unimportant to some people, but I believe it is essential. We don't draw diagrams for fun. We do diagrams because we need to communicate with other people. We need to impress, seduce, convince... clients, partners, colleagues, teachers... basically diagramming is only about communication. And I'm definitely convinced that communication can be made easier and more efficient if you have proper visual material to support it.

The last one:

Non-invasive. I'm simply going to quote 37 Signals on this: "Everyone loves simple tools that help get the job done and then get out of your way."

Regarding the technical aspect of building Love Charts, Cordiez summarized:

Flex all the way, with Flash for the libraries compilation. I don't see anything like LC being built in Ajax. Flex (Actionscript 3 & MXML), PHP/MySQL, and AMFPHP in the middle. A fair bit of the client-side architecture relies on the Cairngorn framework.

AMFPHP (Remoting solution for PHP) handles the communications between back- and front-ends. This allows for an elegant, easy to maintain, OO architecture that is pretty transparent, where you have real typed objects that travel seamlessly between the front and the back-end.

From architecture perspective, what could have done better or differently? Cordiez didn't mind sharing his regret:

The only thing I regret is not having implemented some kind of ActiveRecord-like framework between the PHP tier and the database. I know some people have been working on such things for PHP, but when I investigated it, it either wasn't ready for consumption or didn't match my needs, and I simply lacked the time to roll out my own solution.

In terms of a RIA system, what makes Lovely Charts different from transitional web application and how the architecture could evolve? Cordiez shared his thought:

Lovely Charts current nature makes it pretty much a "client only" application... By that I mean, that currently 90% of the app's logic is on the client, with the backend basically only performing CRUD-like operations, so this is not really an issue at the moment, but with the plans to evolve towards a more collaborative application, the importance of the backend will certainly grow, and its architecture will definitely need to be revised to accommodate new capabilities.

InfoQ asked what the technical challenges encountered during the development of Lovely Charts. Cordiez recalled there was one indeed:

Properly handling keyboard shortcuts is currently my biggest challenge. Early testers' feedback made it very obvious people expect standard shortcuts such as Ctrl-Z, Ctrl-C etc to be implemented, and rightfully so. But it's definitely a lot less trivial that it may sound like at first.

Cordiez went further to explain what the problem was:

First of all, even if the ActionScript languages provides classical DOM keyboard events handling mechanisms, there is currently no standard framework for the implementation of an application wide, easy to maintain and implement keystrokes handling system. Now that's ok, that's part of an application developer's work, and it's an interesting challenge as well.

Cordiez continued sharing the difficulty and challenging aspect of Flex RIA application development:

But once you have a basic framework set up that works well in a standalone configuration, and because Flex applications are still web, browser embedded, you start facing browser compatibility issues, and so you start fragilizing your architecture by incorporating hacks that each solve specific issues without any high-level overview, and so you get to break things that worked earlier, and so on and so on. It's an immensely frustrating process in my opinion, even if I know some people appreciate this kind of challenge :)... Cross-browser compatibility hacks are acceptable when you are building a web site, but for a complex application, it's really not something you want to have to deal with.

Facing and dealing with the challenges, Cordiez still feels optimistic about future:

Now, this is a classical RIA challenge, I know others (e.g. buzzword) have been facing this and apparently managed to solve most issues in a rather satisfying way, and I'm confident Lovely Charts's keyboard shortcuts will one day be both standard and working properly, but it's still a challenge ... I have no idea how Adobe plans to handle this issue in the future, because even if their security concerns are real and perfectly valid, it’s also true that if the Flash Platform wants to affirm itself as THE reference for RIA deployment, it’s definitely an issue that needs to be addressed.

Cordiez then talked about the experience of developing on Flash / Flex platform:

Besides that, I haven't met any specific technical challenges here, the biggest challenge for me was to figure out interaction principles and mechanisms that would help provide a satisfying new approach to diagramming... And I must say, the Flash platform is absolutely fantastic for that, as you can hack dirty little proof of concepts in no time, making the whole prototyping process very agile, while still being able to architect something super clean and robust once you decide to implement something "for real". This flexibility, combined to the power of the Flex framework and everything it provides, really makes this platform a super efficient one for the conception and implementation of richer and better user experiences in RIAs.

In the end, Cordiez showed InfoQ what Lovely Charts' future he has planed:

I expect/hope to release V1, or at least an open public beta, by the end of Q1 2008. Also, It's a bit early to discuss it in details, but Adobe's BlazeDS for example, is definitely something I'm looking into.

Regarding V2 and beyond, Cordiez revealed:

V2 will be strongly focused on adding collaboration capabilities (probably real-time) and "user-generated content" options, allowing advanced users to create custom libraries, eventually share them, etc.

Another big driver for v2 will be to improve the premium offering: real-time collaboration is very probably going to be one aspect of it, but I'm also strongly considering AIR as a deployment platform for an enhanced version, taking advantage of things like desktop integration, offline sync and storage, etc etc.... while holding the advantages of small footprint and "multiplatformism" the web-based solution offers.

Another option I'm considering is working on some specialized/advanced options packs for specialized roles or industries, but this is not very high on the list at the moment, I guess user feedback and demand will be determining here.