The case against Flex-based application UIs
Added By Tony Byrne at 2-Feb-2009 | Twitter: @TonyByrne |
We're starting to see more vendors coming out with Flex-based user interfaces, sometimes extending them as full-blown desktop applications using the AIR runtime. For example, Documentum's D6 Web Publisher comes with a standalone Flex interface for certain tasks.
To me, turning to Flex for a content management interface is a cop-out. It creates nice demoware for the vendor, but long-term problems for you. I can see why Flex is alluring for vendors: maintaining consistent, cross-browser compatibility (especially with AJAX) is hard and expensive. But why does that mean that you the customer must give up the simplicity and supportability of a native browser-based interface?
Flex is essentially another semi-thick client akin to Java applets (or ActiveX controls). Let's review why the business world didn't like applets for application user interfaces when they were pervasive within enterprise web applications earlier this decade.
They almost always violate web accessibility guidelines. Sure, many thin-client application interfaces are not compliant either, but at least you have the opportunity to make them compliant -- and many platforms (e.g., Plone) do so.
They create support nightmares. Things like automatic updates, license-checking, and incompatibilities with the underlying virtual machine lead to many a help-desk call. As my colleague Kas notes, with AIR instead of applets you are just replacing Sun's virtual machine with Adobe's. The potential for trouble remains.
They are prone to performance problems. Flex applications are prone to the same memory leaks and CPU spikes that bedeviled applets for years. To be sure, I've seen some fat and ugly JavaScript-based interfaces too, but at least everyone can debug those openly. We've also had customers tell us that their Flex interfaces are unusually chatty on their networks.
You can't easily modify them. The vendor sets a unified interface and all their customers have to live with it. That might work for a one-dimensional tool, like a Twitter client, but what about more heterogeneous, multidimensional environments?
To my mind, this last problem is really crushing. I recently participated in a Web CMS vendor demo for a consulting client, where the vendor unveiled their Flex-based webpage-builder interface to initial nods of approval. But then we asked the vendor to continue along the scripted scenarios, and the headshaking started becoming more horizontal. The way some elements were laid out didn't make sense to the customer team, and the empty placeholder blocks had confusing iconography and signaling.
Naturally, audience members asked how the interface could be re-configured. The vendor's reply: "We'll take it up with the product manager at headquarters." The air went out of the room (so to speak).
An answer we wanted to hear was, "You can modify the UI yourself on a role-by-role basis, and our platform is properly tiered, so we can show you how to customize it in a release-safe way."
Until your vendors' Flex applications give you that freedom, I'd urge you to stay away.
Anyone care to disagree?
Categories: Tony Byrne, Collaboration & Community Software, Digital Asset Management, Enterprise Content Management, Web Content Management, Implementation, Industry Standards, Marketplace at Large, Documentum Web Content Management
