views:

49

answers:

1

I have an application that spans several pages of engagement for the applicant and I don't want the user to abandon prematurely.

Without hijacking the back and forward buttons (I think most of this forum would agree is a bad practice) I have a set of eventhandlers leveraging onbeforeunload that handle some of the typical use cases where the system might consider the unloading of a document is equal to the user abandoning the application, i.e., page refresh (F5, Ctrl/Meta+R).

However, what is eluding me is how to allow movement within the context of the application, e.g. pg 1 > submit > pg. 2 > opps, back button > pg. 1. Or where physically munging the URL may happen but the application is still "in scope."

What happens using the back button to return to pg. 1 (or forward to return to pg 2) onbeforeunload fires (which is expected), thus it looks like the applicant might be abandoning the application.

What I'm looking for, and is eluding me, is the power to inspect the destination document/domain. I would prefer, thus making user experience not too ugly, to fire the "Please don't leave" dialog only when the next page is not going to be in my application domain.

Suggestions?

A: 

Rather than using separate pages, would you be able to use several divs all on the same page? If you're using ASP.NET, you could also use user controls for better code isolation on the codebehind side. I'd still keep the div as the top-most tag in the user control.

Each div would correspond to what you currently have encapsulated in a web page. Depending on the user pressing back or forward button, you can enable the visibility on the appropriate div.

HTH...

code4life
This would work, unfortunately it's a legacy application that is married to its MVC. I've employed exactly this model in a number of "brochure websites" where the navigation is in a TabView (YUI) and the back and forward buttons act higher on the navigation stack.I've started looking at our competitive and I'm building a case that this kind of app abandonment is to difficult to trap--our competitive seems to have attempted this in the past, but the code that attempts to determine it is all commented out.
javafueled