Will’s Blog

I was browsing around the web last night looking for resources on building rich javascript User Interfaces and found the following links:

• Building Rich DHTML User Interfaces Revisited
• Building High Performance HTML Pages
• Faster DHTML in 12 Steps

Almost forgot, the CSS tip that Scott Isaac posted on his blog looks quite interesting.

I think the greatest thing about this whole Ajax/DHTML UI building is that the developer gets greater control and flexibility in how they build their new Web UI for Web Applications.

There’s a much greater need for this type of UI when building Web Applications when you’re replacing a traditional Windows App. Users expect things to be instant. They hate waiting, and can get rather impatient if they are forced to wait too long.

I’ve already experimented with Ajax.NET in my day to day app that i’m building at work and for the small part that I use it, it’s been great, and reliable. More importantly, it took not very long to build once I was familiar with how the Ajax.NET library worked. Personally i’ve found it to be quite impressive.

I haven’t really gone and abandoned the traditional postback model of ASP.NET but i’m trying to cut down on postbacks where I can and utilising a bit more JavaScript to handle displaying and hiding of form elements based upon user interaction. Postbacks are slow on large pages.

I’ve combined my JavaScript with CSS to perform the hiding/showing and enabling/disabling of form elements for more and more things and only doing a postback and rebinding of page elements after a user clicks on the submit button. I’m not really a fan of the idea that a lot of demos out there are showing where a user just types in some data in a text field and when the field loses focus, there’s a little bit of async callback to the server to “submit” that input.

I mean it’s nice and all, but I don’t think it’s neccessary. Users still like their “Save” buttons.

As an example of one of the things I’m doing right now is rather than using the Visible property for my HTML/Web control I use the “display” CSS style property.

Eg: Rather than myControl.Visible = false;

I use…: myControl.Style["display"] = “none”;
Or if I want to manipulate it with JavaScript I can do something like…

var theControl =document.getElementById('myControl');
theControl.style.display = "none";

This approach I feel is more flexible if there is a fair bit of showing/hiding of UI elements based on user interaction. With the Visible property your control gets totally hidden (eg: it is ommited from the Page output) and is inaccessible by client side scripts.

I like the idea of showing the user a “please wait…” notice immediately after the user clicks a button and something needs to come down the pipe from the server as that at least allows the user to know “hey I clicked something, and something is happening” rather than “should I click that button again, did I click it yet? nothing seems to be happening” etc… And this will cause two or more of the same things being submitted to the server.

The more you can do without needing to postback to the server an entire page for it to process the better I think.

JavaScript and the whole DHTML concept has been around for quite awhile and it’s only now that we’re seeing really great web applications that fully utilise this.

Years ago, you’d have web apps that use a bit of it here and there to string things together.

Nowadays with the greater attention given to JavaScript/DHTML through the whole Ajax concept is great.

I look forward to being amazed by these apps.

Although I haven’t yet abandoned the Page postbacks in ASP.NET, I think it’s a real possibility that if I had my time around, I’d design the app UI differently to better utilise DHTML.

You could probably get away with only downloading the HTML once from the server, and then having a whole set of different JavaScripts managing the updating etc… of the actual page elements and then the postback becomes something which is much more rare.

Think about it. If you’re page consists of a html data table with about 200+ rows of data, you’d not want to cause a postback when the user changes the status of one of those elements.

Here’s an example…

A user is browsing a catalogue of products at an ecommerce website with about 20 elements in the html table and he/she clicks on the “Add to cart” button.

Now if you’re still using the Postback model, you’re page will have a refresh just so you can update the little item count on the page to show that the item has been added already.

In the world of DHTML you’re more likely to have that little items count update without a postback. As soon as the user clicks on it, it’ll update straight away.

That’s the e-commerce world.

In the web app world users want more items displayed on their page and still get the same responsiveness as having less items displayed on it.

This entry was posted on Thursday, August 25th, 2005 at 09:46 am and is filed under .NET, General, JavaScript, Technology. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.