Jeff's Blog

Pros and Cons. 

When it's all said and done, no matter what you start out thinking you are in for, when it comes to the wonderful world of Ajax, things just wont work exactly how you expect them to.  Unlike much of the world of web programming, there's the gorilla of compromise that makes it presence felt without fail.

From subtle CSS-purgatory nuances, to the predictable unpredictability of end users, be prepared for a fair amount of hand tuning if you want a truly robust dynamic web experience.  This brings several new problems into play when developing a full fledged user application.  There are apparent issues like how to create/manage and test the JavaScript and CSS, choosing an appropriate solution for providing data to a client, like full fledged WebServices, or PageMethods.  There are also many less obvious issue that arise mainly around the user experience. 

With the use of a dynamic Web interface, it is possible to both enhance and confuse a potential user.  The web for the most part is a fairly predictable place.  With the exception of designer driven flash website, the pattern of the HTML Form with a Submit and Clear button at the bottom is well known and trusted.  Users know what a button click means, they know how Radio Buttons work, they know the feel of a Textbox.  With an Ajax backed UI, funny concepts like forms with no submit buttons, or type ahead textboxes start to creep into the picture, and suddenly as a developer you can be holding the very tedious responsibility of interpreting a user's intent.  This is a very uncomfortable place for just about anyone, let alone for people who are more comfortable with the safety of booleans.

One of the biggest benefits and biggest drawbacks of an UpdatePanel based Ajax website is the fact that the entire set of Form Data is pushed back to the server when an UpdatePanel is updated.  There are many legitimate cases for this behavior, such as a List/Detail pattern.  Having all the data available to you allows for a very natural event driven Asp.Net code behind.  But what if you have a form, and wish to provide interactive help statement if you use an UpdatePanel for this purpose, you'll need to decide what to do with any other data the user has entered on the page.  Should you persist it to be friendly and help them maintain state if they leave before completing the form, and then later return.  Or is it better to do nothing because no specific intent has been expressed by the user to submit the form data.

Perhaps you choose to have a submit button-less form, and whenever a user makes a change, use WebMethods to persist their input on the server.   How then does a user clear the Form, should you provide a button with such a function, with the issues around possible sequencing issues on Requests making it to the server, what strategies would you use to determine what Request wins.

The really issue is when the user decides to do something that you didn't plan on.  This always happens we've all seen it, only now there's yet another layer of indirection to make things extra fragile.   The biggest, and most painful of these issues that comes to mind is the Browsers back button.  When you're dynamically replacing page content a user has no real way to distinguish this from a real page navigation.  Sure users will learn as they use your website that the back button causes pain, but is once bitten twice shy really a good axiom for UI design?

Yes there are things that can be done to mitigate most user -free ranging- but again, this is just another layer beyond the the normal layers of what-if-ing that occur when you develop a webpage.

Anyway next time we'll be putting our WebMethods into our Modal, and then we'll use a little Fiddler/Trace.axd data to look at what we're really doing under the hood.