The case against Flex-based application UIs

  • 2-Feb-2009

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?

Our customers say...

"RSG's The Collaboration & ESN Software Research is the most comprehensive and detailed analysis of this rapidly developing marketplace available. Of particular value are the vendor profiles and the authors' depth of knowledge and understanding."

Dr. Martin De Saulles, Principal Lecturer, University of Brighton, UK

Other posts

New Stack Advisory Offering

  • April 19, 2019

The service is designed to support the harried MarTech or OmniCX stack owner. Let's call her Stacy...

[Webinar] Relief for the Harried Stack Owner

  • April 12, 2019

How can stack owners respond to growing demands and an abundance choices? Learn what will make you most successful as you move your enterprise into the omnichannel era....

MD