Dealing with captive portals on rich web applications

Question

I'm working on a web application that contains a number of (form) steps in which customers make a series of choices, resulting in a search result at the end. The form is implemented as a single-page web application which uses AJAX to pull in data as the user progresses through the steps. This has some interesting results when the user tries to use it on a (public) wifi with a "captive" login portal and it made me wonder: what's the best way to deal with that?

On regular websites, the captive portal would pop up the first time a user clicks any link and then redirect them back to where they came from when that's done. Annoying, but functional. With this single page application, the user won't know the internet connection has stopped working until the first AJAX request is needed (which could be a few steps into the form). At this point, we wouldn't want them to lose any progress.

Are there any good examples of dealing with captive wifi portals in rich web applications?

The best example I have found so far in the wild is in an YPlan on iOS. This is a native app though, so it does not have to worry about losing data while the user goes to their browser:

Trying to transfer this to a web app, the best I could come up with is this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Clicking "try now" would link to the page with the chosen options as parameters in the URL. This would either reload the page, or throw up the captive portal (which will hopefully redirect to the right page upon completion). Are there better ways to deal with this?

Answer 1

The best way to deal with these situations are to thoroughly handle them. Use something to signalr that will automatically deal with your connection and re-connection problems in the background.

Then implement the command pattern. All your actions will be a command that will queue up. If there is connection they will save, if there is no connection they will stay in the queue and try again.

There's no easy way to do this, its about writing the code and catering for the data in an "offline" mode, but if everything is on a single page then this wouldn't be so tedious.