I’ve been working with a client whom I’ve been working for almost 10 years now in an advisory capacity. The customer has built and I’ve helped with systems that for the most part are highly meta data driven with application ‘service’ based interfaces that have light weight front ends talk to server heavy applications over the wire. These aren’t service based application in the SOA sense but lightweight, custom service implementations that serve data over HTTP.

What’s different with this customer (for me at least is) that they’ve always taken the lightweight UI tack, starting originally way back with a FoxPro front end talking via HTTP to the server (also FoxPro at the time), then moving to a Flash driven UI talking to highly efficient ASP.NET custom handler implementations. A couple of the apps created with the Flash front end are very rich in UI behavior although not terribly ‘flashy’ – rather these UIs are creating a desktop type environment in the browser with a window centric desktop format where you can look at many pieces of information simultaneously.

Currently there’s another project on up for discussion and again we were sitting around a table discussing UI options for this application. The app already exists as a desktop app that talks over Http to the service interface and it works. But the hassle of distributing, deploying, updating and maintaining a desktop application is proving to be a royal hassle for this company and they want to get away from that and on to a pure Web environment that runs completely in the browser without any sort of installation or configuration of environment.

A lot has changed: Ajax, Silverlight, Flash, RIAs

A lot has changed since the last time this came up so I threw out the options of going with a pure Html based interface vs. using Flash (also discussed Silverlight). After some back and forth though the client ended up more or less insisting on the Flash solution and after some detailed discussions I ended up concurring that this is probably the right choice for them.

If you read this blog occasionally you probably know that I’m a big fan of HTML based client interfaces and I believe that we’ve come a long way for building nice user interfaces that rival some of the functionality of what you can do with RIAs like Flash and Silverlight. However, I also have to admit that HTML has some serious limitations when it comes to building very complex user interfaces, especially when you start talking about Single Document Applications that are effectively driven through a single desktop-like scenario. The problem with HTML in this environment is that there’s really no clean way to build components and isolate them from each other or even build them separately as independent markup and code components.

The application in question is a data visualization and management application so there’s lots of interdependent information being displayed and the way that this is handled is by having multiple windows open that show this information, with the information refreshing in all windows as the source data is updated or queries are modified. The effect is that you make a change in one window and the display is affected in one or several other windows.

One thing that I’ve found is that it becomes very difficult in pure HTML environments to build complex window based interfaces. Not a big deal for popping up a few simple pop up windows (say for entering data or a query/filter box etc.). That stuff is easy. But once you talk about building a complex windowing environment with many windows where windows need to be self-contained and where the same window can be open in multiple places, it becomes very difficult – at least in my mind - to manage in HTML.

With ‘rich’ applications there’s a lot of expectation to build interfaces that rival desktop experiences and while you can get there with the basics fairly easily even just with raw client side coding plus some JavaScript libraries, to build a more complex ‘environment’ is still something that is very painful with HTML.

The problems here are many: There’s no effective native object model for encapsulating something like a ‘window’ or ‘widget’ that has component parts in HTML. While you can create classes that create window behaviors, managing the child HTML controls and content effectively and independently is not easy and certainly there’s no standard model for it. There’s also the issue of HTML control names – if you create two ‘windows’ that have the same content and are active simultaneously how do you ensure that you have unique control names for all the child controls? How do you reference these child controls if there’s some custom naming mechanism used. HTML provides nothing for control encapsulation or management of DOM components independent of the document itself – everything is top level.

For me the result is that when I build even relatively simple window heavy applications that there’s a lot of code that deals with managing the content updates of each of the windows cluttered into the main code with little to no abstraction. While I can create classes to isolate each window and its behaviors and operations, even that doesn’t really help with encapsulation of logic, naming and operation of composite DOM elements.

RIA’s tend to be more adept at this because they effectively allow for encapsulation of components that can be coded against in isolation and that define their own behavior. Where HTML has basically a single document that defines the unit of work, these component technologies allow a much lower level of abstraction and so make componentization much easier.

It’s possible that this could be done with HTML and some high level AJAX libraries have actually addressed this with a component architecture that wrap the HTML model, but at the plain HTML level there’s really nothing that provides this functionality to your day to day application development.

HTML is not always the Answer

In the end for this application that the customer is building, which is effectively an Multiple Document Interface type app where many windows are popped up, using a Flash or Silverlight based front end that allows isolation of these components into separate logical units is much more appropriate for this type of interface. I’m not a big fan of Flash and I couldn’t build the type of interface they are asking for by a long shot – but the customer has the in house talent to build the UI along with components that provide the UI building blocks from previous applications to present this type of interface. It’s hard to suggest alternatives in light of what is basically a proven formula that has been used in two other applications and admittedly has ended up with very slick results.

It’s not often that I run into this scenario in Web based applications where HTML is a questionable choice, but it’s happened on a few occasions and each time it makes me realize there are still a few areas for which pure HTML is not necessarily a good fit or at the very least a difficult fit. I’m sure some folks will say outright that a ‘desktop metaphor’ for Web apps is a bad idea anyway, but personally I’ve seen this come up in a few different situations because the interactivity between various interactive displays is vital.

I’d be curious to hear if others have run into this and how they are approaching componentization of complex HTML interfaces. Quite frankly I’ve not been in a situation where the UI for a single page was complex enough that it got completely unmanageable with JavaScript and a single page interface, but I’m pretty sure if we were to go down this path with the aforementioned application it would happen very quickly fall into the unmanageable realm. I have worked on a few applications where the page associated JavaScript went into a few thousand lines of code and most of it had to do with the window/component management aspects.  It gets difficult to deal with this much code in JavaScript especially given the currently crappy state of JavaScript editing/management tools. This might get better with better tool support, but the HTML issues of control naming and component encapsulation remain.

So here’s a question: Have you build really complex, client driven interfaces before and if so what approaches are you using to componentized the individual page components like windows or even separate edit/viewing areas to make them truly self contained and manageable through client code? Have you fought the battle trying to convince customers of one approach over another (RIAs vs. plain HTML) and which side did you argue and why?

It’s interesting to see how with the addition of choices the answer often becomes more cloudy rather than clearer <s>…