Stop, Reload, Error Loading Page 404: Converting Web 1.0 to 2.0

Dietrich Kappe, Friday, March 7, 2008 @ 7:26 pm

OK, onwards in our effort to convert Web 1.0 apps to Web 2.0. Today we'll focus on some of the differences between Web 1.0 and 2.0 from the user experience perspective. When we think about our web interface, we usually think about the links, forms and controls we've put in place. But the reality is that often things go wrong with our app -- sometimes network problems, system problems or application errors -- and we get errors like 404 or 503, or a "page did not load." How does the user respond to these issues?

Usually they make use of the Stop, Reload, Back and Forward buttons. Most times application developers see the use of these browser buttons as a problem, to be mitigated ("Please don't submit this form twice..."; "Don't use the back button or your order will be submitted twice..."). If you think about it a little more carefully, you'll find that these buttons form a vital safety net for web applications, without which users would be crying in frustration at the "Unable to connect..." pages and spinning cursors that have brought your app to a halt.

Compare this now to a Web app that uses Ajax. I you perform an
XMLHttpRequest behind the scenes, what happens when a 404, 503,
spinning cursor, etc., occurs? Well, by default...nothing. The stop,
reload, back, forward buttons are just not hooked up to the XHR. So,
you still have to worry about the disruptive effects of these buttons
on your single-page Ajax app, but you can't rely on them to bail you
out of tough spots.

With these insights, our next analytical steps are clear:

1. With
   regard to each controller that receives a postback, make a list of the
   consequences of a hanging connection, a network error, a timeout, a
   reload, a back/forward action, a reload, an application error.
2. How will the user work around this issue using browser button navigation and resubmits? Add these details to your list.
3. Which
   of the browser button workarounds is critical, i.e. if you run into a
   network error and you are unable to reload, is your user dead in the
   water? Highlight these critical workarounds in your list.

For
all of your critical workarounds, we need to come up with a Ajax/Web
2.0 workaround as well. There's a big toolbox for these workarounds --
modal dialogs, cancel buttons, XHR timeouts, etc. -- that we'll make
use of in the next few posts.

Technorati Tags: ajax, web20

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment