
Vacillating clouds leaving behind streaks of soaked rays. As seen from my terrace!
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:
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:
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.

Recently my employer's decision to move to MS Exchange for providing a collaborative platform in the enterprise sparked off exchange of opinions between my peers who had been using UNIX and similar systems, and Windows aficionados . One such topic that was hotly debated was how to circumvent the MS Outlook and still be able to use the MS Exchange Server (MSE).
Many a times, whatever be the reasons classical, traditional or political, UNIX 'bigots' resist to 'condescend' and use Outlook or similar integrated GUI clients (e.g. Web Client on IE) for MSE and instead devise ingenious ways to acheive connectivitity by using traditional UNIX scripts like Pine, Mutt, Elm, Fetchmail and so on. While, most of these work to provide simple SMTP, POP/IMAP access + Filter capabilities, they miss out to exploit MSE's rich collaborative features.
Though, personally I am not a big fan of M$, yet, I don't snub at anything and everything good in life, simply because it is from M$ or they are also used by dorks :-). MSE is not an email server only that most of us think (and believe) it is. Win2k, Kerberos, Active Directory, Exchange and Outlook forms a potent collaborative platform for an enterprise. Just look at its suite of offerings: Calendar, Tasks, Follow-up reminders, Delegation, Public Folders, Rich Text support, Enterprise Directory and so on (some of them may have ideated from products like Novell GroupWise or Lotus Domino). One good reason to stay close to Outlook/WebMail via IE is that, we get to use all these feature which, I think, any combination of Pine/Fetchmail/Elm et al can't do? However, MSE has earned a bad reputation for proliferation of viruses and worms that choke networks. But, most of the times, it is proliferated due to gullible outlook users and ignorant System Administrators, a fact, cleverly exploited by mischief mongers- also called hackers. With proper security planning, user awareness and hardening of Windows Systems, I feel, such a menace can be reduced to a great extent.
We the Developers, have our own preferences towards tools, platforms, configurations and almost everything, held and cultivated over the years, either by choice or by compulsion (lack of alternatives, too good to detach etc.). We make our own 'indirections' for every problem we face in our daily setup and cling on to them religiously...all these ideas work for individual and I am sure some of these would be hard to promote or override lest it leads to acrimonious exchange and thrusting of ideas. Nevertheless, for a large setup like enterprise, deciding and using a collaborative tool is a part of wider corporate 'strategy' and most often taken with a democratic or populistic view and as far as I know, usability of a Outlook + Exchange combination will defeat any *IX based collaborative tools available in the market today. At least, think from the perspective that such tools are used by people right from marketing directors to front office executives and they need to fix an appointment sometimes, with developers too! Also, think from the perspective how easily and cheaply you will find trained staffs to sustain such a platform- it all affect a TCO.
Further refs:
What Is Exchange Server? http://www.microsoft.com/exchange/evaluation/whatis.mspx
Microsoft Exchange Server resource site http://www.msexchange.org/
MS Exchange Blog http://hellomate.typepad.com/exchange/