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... To me, turning to Flex is a cop-out. It creates nice demoware for the vendor, but long-term problems for you...
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.
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?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... To me, turning to Flex is a cop-out. It creates nice demoware for the vendor, but long-term problems for you...
The Agile ArchiveWhen it comes to managing data, donít look at backup and archiving systems as burdens and cost centers. A well-designed archive can enhance data protection and restores, ease search and e-discovery efforts, and save money by intelligently moving data from expensive primary storage systems.
2014 Analytics, BI, and Information Management SurveyITís tried for years to simplify data analytics and business intelligence efforts. Have visual analysis tools and Hadoop and NoSQL databases helped? Respondents to our 2014 InformationWeek Analytics, Business Intelligence, and Information Management Survey have a mixed outlook.