I just recently became aware of ILOG Elixir, which is a set of advanced data visualization components for Flex (Gauges/Dials, Maps, Treemaps Gantt, etc) that will be distributed and sold directly by Adobe for approximately $800. Last night I downloaded the beta to check them out, as we have already built several of the less complex components internally.

While I was impressed with the work that I know must have gone into building these components, I was less impressed with the end result on a couple of fronts. First, most of the components I looked at did not appear to be very extensible, at least on the surface. For instance their Gauge component came in one color, BLACK…., with no obvious property to alter the primary color. Admittedly I did not do a deep dive in the API, and I could be missing something here. The second area of disappointment was the lack of a polished UI and set of skins. The components seemed to be highly functional, but lacked the polish we are all coming to expect of commercial level UI that can be seen in most premier RIA and commercial OS like Leopard and Vista. Putting that polish on the components does not seem like it would be a lot of work normally, but when you take into account the lake of available properties in the API it could be a bit challenging.

What I found really interesting is that just this morning I discovered an open source effort that builds one of the more complex components in Elixir. It appears Josh Tynjala has released his own TreeMap component. On the surface this component looks every bit as good as the one offered by ILOG AND it is open source.

This begs the question: “Will we see more third party components developed commercially or via the community?” Coming from more of a closed source mindset (Microsoft) where there was a proliferation of commercial third party developer tools it is hard for me to evaluate. My experiences over the past couple years working with Flex, the team at Adobe, and the growing community tells me that more and more developer tools and components will be created via the community. Part of the reasoning here is that it is a cultural issue, the second part is that AS3 and Flex just make it sooo easy to do.

There are other complexities to this question, as it brings into question the viability of third party developer markets for Flex, which I think will be very strategic for Adobe to successfully penetrate the larger developer market. Microsoft has been very good at this, but they did so with a completely different set of cultural values (closed source proprietary.) I will be following this closely as the it could have a significant impact on the direction we take our business.

I fell in love with flex when I first started using it back in October of 2005 with the Flex 2.0 alpha. I loved it so much I started a business that used it is as its primary technology and based a big part of the business strategy on the assumption everyone would love it as much as I did and the developer community would grow quickly. Well I was partly right, everyone DID love it, especially the end-users in our target market (BI dashboard consumers.) What I didn’t anticipate was that the DEMAND for flex talent would be so high that trying to find a flex developer was next to impossible.

The wrinkle for me as a business owner was that I built a platform that was designed to host Flex dashboards, but it would require flex developers to build client specific content for the platform in the form of flex dashboard applications. For a client to gain any value from our platform they would need content tailored to their unique needs (think of a typical intranet portal.) For our marquee (read Fortune 500) clients we would offer professional services to build their dashboards, but our whole goal was to sell recurring revenue via a SaaS business model, not via professional services. We soon ran into roadblocks in the sales process when we would tell clients that in order to extend, or add dashboards they simply had to just “hire a flex developer..” Well that was pretty much where the sales conversation ended, because we were asking them to find a resource, we ourselves couldn’t even find (I ended up hiring good Java, and C++ developers and trained them on Flex myself.) The demand for Flex had far outstripped the supply. I was hearing rates of $250/hr + for Flex engineering work!

What I didn’t anticipate, or said more accurately “think-through”, is that there would be a lag between the demand generated for Flex and RIA, and the resources to fulfill the demand. Well things are getting slightly better. I see evidence (anecdotal) that the Flex developer community is really starting grow, with community sponsored events like Flex 360 we see a huge groundswell starting to manifest.

I also am starting to see the community filling needs in regards to the flex code base/framework faster than Adobe can with projects like Model Glue, Degrafa, and FlexMDI. Projects like this are really exciting to see, and have huge implications in regards to the efficacy of open source and the implications it has with business strategy when it comes to running a software company.
It seems now that the supply is starting to slowly catch up with the demand, and I realize one of the major accelerators that are filling the supply side of the equation is the open source community. This realization is partly responsible for me taking a serious look at how we can contribute to the effort because it appears to be a true win-win.

Flex/AS3 does so many things well, and in my opinion is one of the most productive languages to create complex MVC type UI applications. That being said, some work in Flex I can find to be very tedious. While the class structures and OO all seem very elegant at the documentation/class level, the pragmatic use of some of the structures can create some odious and repetitive coding.

Take the charting for example. I can’t tell you how many times I had to hunt around to figure out how to “adjust” the color/thickness/alpha for the horizontal and vertical axis, while not terribly complicated you either need to go down down about three levels of property chains in MXML or AS to get to the correct properties. When doing this for half a dozen charts in one application, it can get time consuming and verbose.

The other challenge we run into, is having to munge source data into a format appropriate for the charts to consume. Internally we have built some more hardwired models that allow us to point to a data structure and have it “transformed” into something the charts can read. I think more ideally we could extend the ICollectionView to include some transforms so that not only can we see sorted/filtered data as bindable properties, but also transformed (aka OLAP pivot/slice/query) data that multiple charts could consume.

Finally, the last main challenge we run into, which is not unique to dashboards, is architecting a proper event driven MVC. Dashboards tend to bring the limits of a non MVC approach to a head rather quickly (specifically highly interactive dashboards with drill up/down/across capabilities.) What first starts off as an easy “hard-coded” approach shortly winds up with piles of spaghetti strewn across several MXML components. Most MVC frameworks like Cairngorm are way to heavy though for simple dashboards. Frameworks (and I am probably using the term incorrectly here) like Model Glue seem more appropriate, but I suspect we could develop something even lighter and more tightly geared for building Flex based dashboards.

So as I see it the three primary areas to build a framework/convention/micro-architecture around would solve these three challenges.

1. Easy way to set styles/properties of objects without having to traverse deep object trees.
2. Easy way to load source data and transform it for charting.
3. A ultra-lightweight MVC framework geared for Dashboard UI challenges.

- Tom

I am not sure how many other flex developers have experienced this, but the latest rev’s of the Flash player break some existing Flex generated content. I don’t mean slightly annoying UI issues, the player downright stops the application from functioning.

The two issues I have found when running Flex content that has been generated by the latest version of Flex Builder 2 (2.0.1) inside a flash player version higher than 9.0.4xx (mostly the player targeted for AIR and Flex 3) are the following:

1. var myObj:SharedObject=new SharedObject();
2. myObject.function = function dummyFunc():void { //do something }

In the first case I suspect that statement was never valid in the first place, but we had code that was compiled in Flex 2 that had these statements and the compiler never complained. Now if we try to run these .swf’s within the latest player the application stops working after burping an error telling us we can not instantiate a SharedObject (i believe it is a static class)

The second case is less obvious, but basically the new player will not allow anonymous NAMED functions. So the statement must read like the below.

myObject.function = function ():void { //do something }

I remember reading another blog post that pointed me to this.

Anyway, I am surprised Adobe is doing auto-updates with these types of changes and not making the developer community aware of the potential pitfalls…. The more Flex becomes prevalent on the web in public web sites the more things like this will become an issue.

- Tom

After spending the last two years building Flex based dashboard technologies primarily for our VFX Dashboard Platform we are ready to start contributing something to the community. In the past couple years building flex based dashboards for our clients we have streamlined the process to go from requirements to final solution. We have iterated over design patterns and frameworks, each time surprised at our ignorance from the iteration before as we found yet another nugget in Flex we were not leveraging.

At this point I am interested in creating an open source dashboard framework for Flex that accelerates the development time to build a rich, complex dashboard bridged across many data sources and highly interconnected and interactive. My goal is to create a framework powerful and compact enough to allow a new Flex developer to build a compelling solution purely in MXML. I am not sure if that goal is attainable, but I think it is one worthy shooting for.

Flex 3 has introduced many new features which we can take advantage of, both in the charting classes and the new OLAP classes. One of the biggest struggles is the repetitive, but client specific code we have to write that takes source data and mungesit into an appropriate format that we can chart from. I am interested in spending some time with the OLAP classes to see if we have some easier ways of transforming source data into usable charting data.

Initially I will probably just release some sample code, and depnending on the audience it gets over time potentially creating an open source project. Right now I am in a pure Proof of Concept state on putting together an appropriate set of samples that would sit outside, but work tightly with some of our more proprietary VFX platform code.

- Tom