Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

Dealing with Complex Client Interfaces: Html or RIA?


:P
On this page:

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>…

Posted in Web Design  

The Voices of Reason


 

Steve
October 25, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

I'd rather use something like Silverlight at this point.

For the most part, it's C#, easier to code, debug, manage than javascript. Even with a strong good library like jQuery

Steve
October 25, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Also, not sure if you have heard of it - but there is a project called 'Prism' that helps to build composite applications for WPF and also Silverlight.

Glenn Brock has an MSDN article about it here:
http://msdn.microsoft.com/en-us/magazine/cc785479.aspx

Steve
October 25, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Sorry, don't mean to make so many comments in a row, but here is the Codeplex home for Prism:

http://www.codeplex.com/CompositeWPF

The stock trader reminds me of your post - a very active application, running in Silverlight

Yordan Georgiev
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

It depends on the requirements of the project ... if you are implementing Intranet Application , which does not require drastic changes simplicity and consistency you d better choose HTML , it has been around for long - it will stay around for even longer ... all RIA's seem to fit better end consumer applications on the Internet ... they will change fast ... and be even more flashier with the time ... Anyway, has anybody heard of sites using more than 5 years old flash ...
To summarize : HTML is global standard all Silverlights and Flashes will never be ... since it is not of the interest of the companies promoting them to be ...

Andrew
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Interesting article Rick. I have been on a team implementing a very rich UI in pure HTML/JS/CSS, and I would confirm your thoughts. ASP.NET is great at cleanly separating your pages into self-contained elements, but all of that is rendered into one great blob of mark-up at run-time and then you are into the same environment as any other web page. At a certain level of UI complexity the maintenance aspect starts to increase exponentially, and if you think the problem might be helped by deploying third-party controls, each rendering their own mark-up and doing their own Ajax, then you start to find some really unfathomable issues and poor performance.

My personal conclusions are:

Pure HTML/JS/CSS solutions can do most things, but they should not be seen as a like-for-like replacement for the desktop app. Letting them behave as web pages were designed to behave, not fighting them into some kind of pseudo-GUI behaviour, helps performance a lot.

It is usually a false economy to use third-party controls and libraries after a certain level of UI complexity is reached. They are feature-rich but consequently barrel thru a lot of redundant code every time. In the long-term you save time for having written all your own JS, which does nothing more than what you wanted, and you understand every line.

Good post again.

Josh
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

You definitely want Adobe Flex.

Gavin
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Yes this was an issue I've battled with on some recent prototype projects. I was attempting to build a web based ecommerce management portal and had lots of grids, windows and data drill downs with more grids and windows and found I was writing lots of javascript and DOM code to do UI updates from Ajax webservice calls. Found the whole thing started to get very complicated for me trying to keep the state of different grids/windows valid. Tried some leading commercial libraries to try and take some of the pain away but found they suffered from memory leaks and started to hit browser performance with what I was doing and never really came to a good answer for myself. My opinion after trying it was that it was alot of work to try and achieve what I wanted and when I saw Silverlight 2 on the horizon saw that as a possible way forward as I had years of previous dotnet experience on the desktop and web. I'm just testing things out currently with SL2 modifying what I had written before for the ecommerce portal and so far am finding it alot easier but is still early days. The front end customer facing ecommerce sites are still driven through asp.net server controls so can remain the same but am trying to write the ecommerce management portal in SL2. I don't feel like I'm jumping through hoops to achieve things with SL2 so far.

Steve from Pleasant Hill
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

It's actually quite astounding how far HTML/CSS/JS have been pushed in order to emulate a quality desktop app. But it's hard at times not to feel like it is a fragile relationship.

The next big push is Silverlight, and will probably replace current ASP.NET development we we know it.

Rick Strahl
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

@Andrew - there's still a big difference between building a pure HTML based interface with different regions on a page (which ASP.NET actually handles pretty well in a reasonably componentized manner) or a richer client side desktop approach. Complexity of the client side only stuff is really where things get out of hand when the page reaches a certain number of involved components.

Agreed on not using Web apps like desktop apps. In most cases this is the wrong model. Web apps should be segmented more and in general provide simpler UI. However in some situations that just isn't possible.

I'm surprised how many people think that RIAs and especially Silverlight are going to be the answer. While I think it's interesting the technology for this has been around for a long time yet it hasn't really made a dent into pure HTML's dominance. The promise of SL is big but it'll take some time to prove that the benefits are real to the marketplace.

Incidentally though - an app like the one we're building would be an ideal candidate for a RIA front end because it's not global access. It's the difference between an application and a Web interface I suppose that makes the difference but we'll see how quickly that difference will really matter.

Marcel Meyer
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Thank you for this entry Rick and starting this discussion.

We are in a similar position where we want to expose a certain richness around the user's domain objects using some desktop-like metaphors such as dragging and dropping to change relations between entities, reordering etc.

We currently have a .Net version out using WebForms that does this using an ill-chosen AJAX'ed UI framework, but we're suffering in performance as well as maintainability since we're trying to do so much on single pages.

I keep asking myself whether we shouldn't simplify it down to a "Web 1.0"-like pages.

The bottom line is that we have to invest in some rewrites, but what to chose?
When I think about HTML, I know that we have to deal with HTML, CSS, JavaScript + our API's C#, and all of that in different HTML rendering frameworks, and I realize that it will take extra time to ensure that all of these technologies pull together well to ensure a satisfied customer.
On the other hand you have (lets pick Silverlight now) a RIA framework where the presentation is guaranteed across browsers, C# and XAML. It just sounds simpler to maintain while ensuring a great customer experience.
But then there is the fact that you have to download a plug in to deliver your service, which the Product Manager chokes on.

Or, do you offer both HTML and an RIA service? Perhaps RIA pages helping on complex business needs?

Regards,
Marcel

Mitch
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Hey Rick,

Are you sure about Flash, maybe you are thinking of Flex? To see Flex stretching the limits, have a look at: http://www.stretchmedia.ca/portfolio.htm and scroll down to Bridgewerx and click on watch video - all done in Flex. Btw, there is no (easy) way to do this in HTML – period.

Flex is pretty mature and simply runs with a Flash plug-in. Silverlight I think (having developed in both) is more powerful and the development environment far superior to anything Flash or Flex and therefore much, much easier to develop in - something from a very practical point of view you might want to consider. Yes, Silverlight is young, but look at the investment made by MS – it is simply a matter of time on the ol’ technology adoption curve…

Having done some pretty complex HTML, JavaScript and AJAX - http://www.youtube.com/watch?v=cxCZzBPOXJM if I had to do it over again, I would do it in Silverlight.

All the best!

Rick Strahl
October 26, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

@Mitch - no they are using raw flash with custom components they built prior to Flex. If starting from scratch I think there would be no discussion about Flash at this point, but due to the existing investment in components they made, plus the personnel to use it it actually makes good sense.

Tim
October 27, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Hi Rick,
I've been dealing with the same problem for our in-house corporate development for the past year. We've been doing alot with JQuery and JQuery UI, but it isn't a very clean object model. We've started using ExtJS (exstjs.com), which is simply stunning for solving these kinds of problems. Not only does it provide widgets, it gives you a whole MVC layer in the browser for structuring your code. Take a look at some of their demos.

I'm using it with ASP.NET MVC, and it works like a dream with the JsonResult. You can get true RIA features without resorting to a plugin.

-Tim

Jorgen
October 28, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

We also have used extjs library with ASP.NET MVC, Script#, extsharp.
Clean object model, script# gives us possibility to write code in C# style (very simplified version but not pure js). extsharp provide C# stubs for all methods of extjs. Unfortunately updates and fixes for script# and extsharp are released not so often.
All big JavaScript files create problems only for debugging (and are visible only on this stage).

Cassio
October 28, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Hi. I'm really interested in this discussion. I'm developing a big system in using C#, Windows Forms, NHibernate, Remoting... I'm starting to get tired to update client machines, even using Click Once. I now have to decide to rewrite everything in ASP.Net or SilverLight 2. Another thing that makes me angry is databinding with Windows Forms. Just terrible. I think ASP.Net is a little better but my expectation is that SilverLight solve this problem. Great article.

Lucas Goodwin
October 28, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

@Rick,

This is a question I bring up on every application we develop as browser incompatibility, etc, can just drive a guy up a wall.

To answer your question of componentized HTML interfaces. I've had pretty good success by deciding that No-Script scenarios will NOT be supported and thus AJAX free-for-all is ok.

Using jQuery and Taconite for jQuery, we've componentized the server code dramatically. Then on the front end, we bind different jQuery objects to various custom and existing events. This keeps the coupling down and located in the watchers, rather then the publishers. So if two grids update based on changes in a 3rd grid and one of those grids is removed, everything still works fine. (Gotta love CSS selectors)

The key though is abandoning webforms and going with a more MVC style framework like Promesh.net or ASP.NET MVC. Where you can control the HTML output better.

Hopefully that made sense...

Danijel
October 29, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Hi Rick,

Silverlight 2 is still young technology and I am already sold ;). I have struggled for many years with complex web interfaces (html, css, js...) and Silverlight 2 is clearly a winner here! Lots of potential there...
I am surprised that you are not promoting Silverlight 2 after all your experience in html/css/js :).

David
October 30, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

I thought this was the exact sort of problem domain where so-called "smart clients" were intended - be it .NET WebForms, Eclipse, or Adobe AIR. The great promise of smart clients was that they combine the ease of deployment/upgrades and access to the cloud of a web application but the UI power of a desktop app. For a consumer facing app I can see where installing a program may not be ideal, but for deployment in a corporate setting or to a controlled user base, it sounds ideal... in theory. Perhaps theory doesn't measure up in reality? I personally don't have experience implementing Smart Clients, but for a even moderately complex windowed application I have a hard time seeing how the confines of a browser wouldn't impose limitations regardless of the technology - Flex, Silverlight, or AJAX. What about drag and drop interaction with the desktop, copy and pasting of inline images, local storage, offline mode, right click context menus, keyboard shortcuts, popup windows that can be dragged over to a second monitor, etc.

Joe Brinkman
November 01, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

This was an area where I had a lot of experience at my previous company. We spent a good amount of effort around creating a solution around Bean Markup Language (BML), which lived outside the browser but was launched from inside the browser. While developing our solution, we looked at a lot of different alternatives trying to find a way to get more embedded in the browser. By the time I left that company in 2005, there was a new startup on the scene who I think really has done a nice job on this in the .Net space. VisualWebGui.com provides a nice desktop experience in the browser. Their solution isolates you from much of the windows management issues you are talking about. However, I am willing to bet that you will find lots of sharp corners, just like with ASP.Net, where their solution may be too constraining. There are always tradeoffs, and I think that to get the kind of windows management functionality you desire you would have to give up a lot of control in terms of architecture and visual design.

Phillip
November 03, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

Rick,
A couple of points not mentioned so far -
1) DDA (UK) / WCAG (Intl) on RIA platforms; whats the story here ? I'd end up having to build at least two versions of the web UI anyhow (WCAG AAA compliance wants your site to work with JavaScript turned off for instance) - one WCAG compliant and the other "flashy" (though not in flash). How do you square that circle ? Has SL or Flash got a magic "show this in HTML" setting ?
2) Silverlight; if the partial .net framework is installed onto the client, why consider the application to be browser based at all ? Its an example of a multi-tier smart client application, isn't it ?

I have limited experience with coding more exotic browser interfaces because (thankfully) I've got away with doing Smart Client .net for "internal" applications and plain-old HTML for public facing ones. IMO the ClickOnce in dotnet is Ok though a bit fragile, and possibly should only be used to download your own bootstrapper for your application where you manage d/l of components yourself; my big hope here is that the limited SL .net framework continues to be extended and for .net philes like me the question of smart client vs browsers will goe away natrurally (apart from that WCAG compliance issue)

Nice blog Rick - have read for ages but never posted.

Ryan Riley
November 10, 2008

# re: Dealing with Complex Client Interfaces: Html or RIA?

This is a great topic! One further thing to consider is semantics of your HTML markup. If you want to stay true to the semantics of HTML (+ other namespaced vocabularies), you get stuck with how far an HTML-based web application can go. For instance, HTML is great for displaying pages of information and simple forms (which can get more complex behind the scenes with Ajax), but using your example, windowing quickly moves away from the idea of a "page" or "document" or "resource", if you want to go the <a href="http://semanticweb.org/wiki/Main_Page" title="Semantic Web">Semantic Web</a> route.

I've been <a href="http://panesofglass.org/tag/semantic-web/" "My thoughts on the future of HTML">thinking on this</a> for about a year now, and my conclusions probably best come in the form of an example. Take a blog software like <a href="http://www.wordpress.org" title="WordPress">WordPress</a>. The engine that displays blog posts and pages and posts feedback from users, as well as all the ajax trickery and interaction you want in your menus, etc. is perfect for displaying to users. The post/page is still a web "page" or "resource." However, the admin interface, as terrific as it is, could easily be a Flash or Silverlight app with an offline mode. The admin interface is really a whole application, not a series of pages that work together, if you follow my thinking. Why not host the application in a page with HTML semantics around it to tell the user why the page exists (i.e., to host the admin app)?

I'm interested on any feedback on this. I didn't get much on my original post. :)

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024