maandag 16 februari 2009

Tegens van de Flex en Adobe Air apps in relatie tot beheerbaarheid en accessibility.

Onderstaand een verhaal over de tegens van een "fat client" oplossing als Adobe Air. Lean and mean weboplossingen lijken nog steeds de voorkeur te hebben vanwege update-problemen. Ik geloof nog steeds in het meer aansluiten op de desktop activiteiten van gebruikers....

Zie: http://www.cmswatch.com/Trends/1492-The-case-against-Flex-based-application-UIs?source=RSS

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.