Once in a while this question comes up about what to do when the user hits the Back button in a browser app. Well, the italian in me says "break their fingers", but most of my colleagues aren’t italian, so here’s a solution for the rest of you.

This one is pretty easy. One solution, and it’s not perfect, is to simply get rid of the Back button. If they can’t see it, they can’t click it, right? Every web app I know has some static pages that the user will go through before they get to the dynamic pages. This solution is independent of the technology you’re using for your dynamic pages (PHP, Perl, DesignBais, FlashCONNECT, ASP.NET, etc) because you’re going to modify a plain HTML page, not your dynamic code.

On that last page where you jump to go to the dynamic forms, don’t just link to your pages, launch a new browser window without the standard container. More specifically, you probably have HTML like this:
   <a href="http://mydomain/apps/firstpage.asp">Go to the app</a>

Here’s an entire page that shows how to replace that – with nothing left to the imagination. I’m doing this in a more verbose manner so that it can be explained, and then I’ll show you a short way to accomplish the task.

<html>
<head>
<script language="JavaScript">
function Launch()
{
  options = ‘width=1000,height=700′;
  options += ‘,scrollbars’;
  url = ‘http://localhost/dev1/’
  myWindow = window.open(url, ‘WebApplication’, options)
}
</script>
</head>
<body>
Thank you for logging in to use our software.
<FORM>
<INPUT type="button"
 value="Go to the app"
 onClick="javascript:Launch();">
</FORM>
</body>
</html>

Let’s briefly walk through what that does:

  • A simple form presents a button that says "Go to the app".
  • When the user clicks the button, a script called Launch is executed.
  • The Launch script sets a couple variables to describe what the new browser window will look like. It sets another variable for the URL, which is most probably the very same link that you’re using right now to send someone directly to the page. And then the script opens a window.

The options that describe the window allow us to define the size and placement of the window, and most importantly for our purposes here, it allows us to specify whether buttons will appear. Since we didn’t mention anything about navigation in the options, none is provided. So the new window opens with no address bar, no menu, and no buttons.

The screen shot below shows a window opened using that script, and the exact same page opened using a normal link.:

Top of web form without buttons and then with

 

There are many ways to do that function. In fact, the entire window.open function and all of the options could easily be put into the link where right now you only have the URL. (The code is split up for display purposes only – put it all on one line in your HTML):

<a href="javascript:window.open(
‘http://localhost/dev1/’, ‘WebApplication’,
‘width=1000,height=700,scrollbars’);">
Go to the app
</a>

Internet Explorer has a security feature that warns users when unknown scripts are trying to execute. You might have some feature enabled that stops popups from launching. So an error like this might display the first time someone uses the above code:
"To help protect your security, Internet Explorer has restricted this file from showing active content that could access your computer. Click here for options…" Clicking the top of the browser gives options "Allow Blocked Content" and "What’s the Risk?" There is no risk here, but your browser doesn’t know that. In case you didn’t understand the first message, you get one final confirmation when you Allow the content: "Security Warning: Allowing active content such as script and ActiveX control can be useful, but active content might also harm your computer. Are you sure you want to let this file run active content?" Yes.

The page that gets launched by the above script can scroll content when there is more content than will fit in the defined space. I’m assuming in the above that the average monitor is 1024×768, so I’m making the window just a little smaller, 1000×700, just to give the user a little room to move the window around and see what’s under it. If some of your users are still at 800×600 *gasp* you’ll need some code that will determine the display size and assign appropriate numbers.

No maximize buttonYou’ll notice that the window can minimize, but it can’t maximize. That’s because we defined an explicit size. There is a resizable option, and some browsers might allow maximization as well.

Another question that might arise now is: what happens if the user clicks the X in the corner? Again, I fall back on breaking fingers. As a developer you’ve done all you can do to stop them from getting into trouble. That X in the corner is there to give the user a final "if all else fails" way out. If they choose that option first then they deserve what they get (lost data, incomplete transactions, etc). If clicking that X leaves your server(s) in a weird state then you need to encourage the user to select different options whenever possible. Which brings us to touch on the design of User-Friendly interfaces…

  • Always guide your users to the proper way out.
  • Give them an Exit button and/or a menu option and/or some other object that they can click on to exit. As I said above, if they can’t see a Back button, they can’t click it. If all they can see are your navigation buttons, chances are they’ll be clicking your buttons instead of looking for something that you don’t want them to click
  • Such a controls must be obvious and well documented – never leave your user guessing whether they should click a button, or wondering how to get out.
  • Make it easier for them to hit your button than it is to reach up to click X.
  • Where possible, train the users to use the proper way out so that they don’t break your app for you.
  • If necessary, short of threatening to break their fingers, emphasize that there could be consequences for existing your app the wrong way. Give them the opportunity to use the app properly. I don’t know what tools you’re using but some tools don’t handle this situation as well as others, where a user is connected one second and is simply gone the next. Until you are sure that your environment goes through some kind of wrapup to release licenses and other resources, you need to do what you can to minimize the chances for problems. The practice of Social Engineering (telling users what’s expected, and expecting them to follow the rules) can sometimes be as effective as writing a bunch of code to accomodate disconnections.

 I hope I covered this one. Please let me know if I missed any key points.