Joe Levi:
a cross-discipline, multi-dimensional problem solver who thinks outside the box – but within reality™

Day 1, AJAX Patterns with ASP.NET (XD003)

Define: Patterns

According to Wikipedia, a pattern is a generally repeatable solution to commonly occurring problem in software design.

Further, patterns are subdivided into two groups, foundational patterns and user experience patterns.

Welcome “Back” Again (or “Logical Navigation”)

AJAX is great, but sometimes people implement AJAX in such a way that is disables the ambiguity of the UI that web users have gotten used to, in particular the Forward and Back paging functionality of the web browser.

But what about when a user makes a click on your webpage that does something akin to either resubmitting the page (ie, a traditional postback), or a virtual new page (even though they’re physically on the same page)? Shouldn’t the back button still work? Shouldn’t they be able to click the back button and effectively undo the last navigation that they performed?

Of course the answer is yes. Functionality should not be removed with the addition of features. That’s something to remember with any project: user experience is paramount.

Introducing the “History Control”

A late-comer to the ASP.NET AJAX offerings, the History Control adds history functionality back into AJAXified web apps — finally!

This also allows for links to be saved or bookmarked, and return the user back to the state of the AJAXified web page.

Graceful degradation

What if someone visits your site and they have javascript disabled? Will your pages still “work”? They should. True, the experience won’t be the same as with full scripting enabled, but they should still have access to all your content, just in a “basic” way (rather than a “rich” way).


Yes, this does require an update to your installed ASP.NET AJAX. This update, released today, is available from here.

Should All Postbacks invoke history?

In a word: no.

This addition to ASP.NET AJAX allows you, the developer, to determine how history should be handled.

Should an accordion panel change (viewing, let’s say, item 4 of 7 in its expanded view and all the other items collapsed) register as a historical event in the browser? Probably so, this allows your users to click the back button and go back to the prior accordion item that they viewed; it also allows them to bookmark their current viewstate on the current page. (It should be noted that this is NOT their session state, but simply a representation to the way the current page is being displayed.)

Should the back button be enabled when your user submits a comment from a comment form? In other words, do you want your users to be able to submit a comment via a web form, then postback asynchronously and view their comment, and be able to hit the back button and view the submit form again? Probably not. This would not only be counter-intuitive, but it also invites comment spam.

Bottom line: it’s up to you, the developer. The slate has been washed clean and now you can determine the behavior of your AJAX page’s history. Just, please, do it intelligently.

Animation Patterns

If you use animations as update cues (fading a background color from yellow to white to draw attention to the user’s newly submitted post, for example), whatever timing you use in development, when you publish your solution, half it… or more. There’s nothing more annoying that waiting for something to happen, that you just spent a lot of time speeding up with AJAX (yeah, it sounds kind of silly when you put it that way, doesn’t it?).

Silverlight and Degradablity

Silverlight uses javacript to render its content. But what if the user doesn’t have javascript turned on? Well, to be truly degradable, the content needs to be viewable even if scripting can’t “pretty up” your content (not only that, but search engines can’t crawl inside “prettied up” content, right Flash?). So how do we handle that? Luckily Silverlight should handle this for us.

After the Silverlight OBJECT tag is a dynamically written div tag with display: none. Then the “non-pretty” version of the page is presented in the code (but hidden by the div style), then the closing /div is dynamically written. If you’re not using Silverlight, make sure you do that with your AJAXified pages. Don’t send an empty page to the user, requiring another server call (even if it is asynchronous). Present the data to your users on the initial load (even if they can’t see it because it’s hidden from view).

Therefore, if your user doesn’t have javascript turned on, they still will see your content, not a blank page (a la Flash).


You may also like...

Leave a Reply