Tony Byrne, analyst with CMSWatch, put out an interesting blog post about Adobe FLEX.
To summarize his perspective he says that FLEX allows vendors like EMC Documentum to create nice demoware, but cause long-term problems for the user. I absolutely agree, except that I feel similar about Ajax in terms of complexity and maintenance. We looked at FLEX and decided against it because it is pure (and not so simple) programming, therefore creating support and maintenance issues. But one should not mix up FLEX with the Flash engine that is in many ways one of the most powerful graphic environments available.
Tony pushes his finger deeply into the user-requirement for GUIs wound. Ouch! We know that one. Business users buy GUIs and not systems or architectures. We have been fighting for user-GUI acceptance for a decade. We never managed to make it flexible and appealing and user-configurable enough. We recently tried FLEX and found it way to rigid to solve those issues in any practical way.
Others disagree with Tony, saying that it is not a problem of FLEX but what vendors implement with it. That may be partially true. I still would not want to base my customers user interface on a library of Flash plus FLEX and having to debug both. Duane from Adobe says that proper coding avoids those problems and claims that Adobe LiveCycle solves many of those support and versioning issues. Having been exposed to LiveCycle I seriously doubt that.
The only way to avoid the problems of FLEX and AJAX is to use managed life-cycle deployment for the EYE GUI components as we do with the Papyrus WebRepository. There is no Java coding required to assemble a GUI layout but just parameterizing the GUI objects in our EYE designer.
Our GUI definitions deploy transparently to QT in our PC desktop and to Flash in the browser. There are no deployment issues except that you will need a minimum level of Flash version installed. I guess that is doable. Because the communication with our Flash engine is not XML and uses an encrypted data format, the security concerns are addressed. The performance issues disappeared when we dumped XML as a transport format and created our own GUI server protocol on top of HTTP. As it happens we also have an AJAX implementation in the works but it will be less appealing, with less features.
The answer to our users is: “You can modify the UI yourself on a role-by-role basis WITHOUT CODING in a GUI design tool, and our platform safely controls the versioned deployment, so we can teach you how to adapt your GUI to your needs in just a few days.”
Papyrus EYE is several times more powerful and flexible than FLEX!