Being a traditional web technologist, iconoclastic opinions of my co-workers provoked me to take part in a debate to reason out if a Flash based web console is apt for building a GUI interface to manage enterprise systems and can they beat the necessity of providing alternative HTML views?
As usual, this debate too was not different. Hours spent over brouhaha with each camp fiercely contesting and defending arguments without letting go respective views. Flash addicts boasted about its RIA gears and support for animation, vector rendering, blah, blah, in all glory to humble the frugality of HTML. Some of the arguments put up by Flash camp are like:
- Flash enables rich Visual, Interactive and Dynamic web console
- Real time/synchronous update of enterprise events
- Easy to generate animated views
- Drag-n-drop, personalization of views
- Plug-ins for major browser like IE, FireFox, Netscape etc
- Unlike Java Applets, it is not bulky and doesn’t take forever to download on to client systems
While, I am not antipathetic to Flash and Vector Graphics based rich and dynamic web pages which probably do bring a ‘rich’ interactivity, yet, I am fan of frugality and ubiquity of HTML when it comes to building web consoles to manage Enterprise Systems and would gladly sacrifice the ‘show off’ for ‘simple’ delivery of content. I feel Flash is an extravagant technology for building web based enterprise consoles. A Flash enhanced 360° view of Sony’s latest high definition video camera probably looks great and grabs attention of prospective customers on their homepage but same captivating view for an SNMP event in enterprise console would not be a ‘great’ value to add.
I hold the view that Text/Html screens are required and we should (also) provide option for users to be able to switch to text only HTML screens too, to substitute Flash enhanced or Flash only pages, in enterprise management consoles. Here are my reasons and motivations for this:
1) In a security sensitive environment particularly, IE on Windows, domain administrators can (and most probably will) constrain the default browsers and disable automatic download and installation of Plug-ins (ActiveX) even, if they are signed (e.g. Macromedia Flash Viewer for IE is a signed ActiveX) causing browser to throw up annoying security challenges for 'accepting' and 'running' this alien components. In order to experience such an environment do (some of) this in IE:
- Open Security Settings ->Activex Control and Plug-ins -> Download Signed Activex Controls -> check the Prompt/Disable radio.
- Open Security Settings ->Activex Control and Plug-ins -> Run Activex Control and Plug-ins -> check the Prompt/Disable radio.
- Open Security Settings ->Activex Control and Plug-ins -> Script Activex Control Marked Safe for Scripting -> check the Prompt/Disable radio.
2) Classically (and may be politically) system administrators and similar knowledge workers (major target users of enterprise consoles) are known to favor 'functionality' over 'presentation'. For such ‘less discerning’ tribe a flash enhanced UI may look extravagant and off-putting. They will legitimately expect to have plain html/text screens as preferred substitute for flash views.
3) Tested and certified Flash plug-ins may not be available for all the browsers on all OS platforms that an Enterprise has. Most Browser plugins are loaded as shared libraries (DLL/SO) and runs in its own thread and they may not cleanup the garbage properly and thus end up hogging the precious runtime memory and other resources. Though, we may wash hands off this issue by certifying support only for few popular engines like IE, NN or Firefox, but, this would alienate sections of users who are loyal to Opera or similar lesser-known and plug-in starved browsers. They would not be willing to trade their comforts and preferences for 'eye catching' flash views. Thus doing Flash-only limits the count of supported browsers, this in a way defeats the goal of web applications i.e. 'deploy once and access anywhere'.
4) Doing Flash we are tempted to build a 'stateful' interaction between console and backend server agents (may be using either Flash MX Remoting or XML data). Such a stateful interaction interferes with the basic REST (Representational State Transfer) paradigm of web applications. In future if we need to integrate pervasive clients or 3rd party applications to enterprise consoles then moving away from REST would make the architecture brittle and different layers (UI and middleware) would tress pass into each other. However, if such stateful interactivity is desired it should be built using traditional client-server topology using thick clients like Swing/SWT/MFC Consoles rather than choosing a web based architecture.
5) Accessibility issues with Flash- this needs to be studied and addressed?
6) How to automate stress and functional testing of Flash pages?
7) Now, with Adobe taking over Macromedia, what is the future of Flash MX? History suggests that a dominant player eclipses other brands/products in such a merger e.g. WebSphere Vs Domino, DB2 Vs Informix, HP-UX Vs Tru64...who knows few years down the line you have Acro Reader retrofitted with a SWF viewer and Flash MX Player is history!
8)Flash is not the only tool for a dynamic and interactive web console. A combination of CSS, JavaScript and XML is transforming the HTML we know. Look at Gmail, Google Maps and so on…anyone with me for AJAX here?
With above reasoning, I do feel that, Graphically enhanced UIs would be particularly useful and favored by IT analysts and business consultants who do a lot of business process and workflow modeling, OLAP, BI etc or certain users who gape whole day at some monitoring consoles and raise alarm when they notice any anomalies between Green, Orange and Red spots on them :-). Flash also looks appealing for building disconnected offline lightweight graphical data analyzer and reporting tools. Other than these, web consoles for managing enterprise software should have simple text/html based views.
