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 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”;
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.
Years ago, you’d have web apps that use a bit of it here and there to string things together.
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.
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.