The Dreaded Back Button – Part 2

From the "give um an inch" department, it seems people aren’t happy with eliminating the back button from the browser. Eliminating all of the browser buttons wasn’t good enough either. No, the very first request was "now can we get rid of the X button in the corner that closes the application? Sigh – OK, the answer is yes.

In short the solution is to create a thick client application which contains a web browser, and then you only show what you want. Most people don’t realize that Internet Explorer is a container that’s wrapped around a browser. That container has optional buttons and a menu, and it behaves like any other Windows application. The browser part is a control that’s been droppe onto the Internet Explorer form.

So I created my own form in Visual Studio .NET. Some properties need to be set to prevent the form from showing the usual butons. For example, I set the SizeGripStyle to Hide so that the user can’t see any handles to resize the form, and I set FormBorderStyle to None so that there’s no border. No border means no buttons.

Then I dropped a WebBrowser control on the form and set the Url property to my DesignBais webmain.asp page. So now on execution I immediately get a form that has nothing on it but a web page. That’s very nice but it’s a little too restrictive. What if the user really does want to exit the application? DesignBais doesn’t have a feature (yet) to cause the current form to close – that’s not a DB fault mind you, the IE security model stops software from closing a form like that. I’ll get back to this later. The point is that I needed a button on my form to allow the user to close this application. So I did put a "Close" button on the form, but it seems to me the very problem we’re trying to avoid is now manifested as an even bigger button that’s easier to hit. So I added a message box on this Close button that warns the user quite emphatically if they’re trying to close their app. It seems we’re at an impasse here – we don’t want the user to close the form but we can’t close it from the web server, so we need to compromise and give them a button but make it really clear that we don’t want them to use it.

It was interesting that a borderless form looked like it was embedded in the desktop. I wondered just how embedded I could make it look. Would it be cool to run an application that really is embedded in the desktop? For some people yes, and others not I guess. I wanted to see the desktop in back of the browser, and let the button look like it’s just another desktop icon. To do this I set the TransparencyKey of the form to the same color as the form background color – in other words, the form would appear to be transparent and all controls would appear to float on the desktop.

As a final bit of geekiness I decided that I didn’t like the way browsers cover up my nice desktop. In line with our Nebula R&D theme I have an image of the Andromeda galaxy on my desktop. It’s a black background with stars all over and a beautiful galaxy in the middle. To see this nice image I set the Opacity for the form to 75%. That’s just enough to see the labels and all other data on a form, but also allow me to see "through" the ghostly form to my desktop. Would I do this in a production application? Probably not, but there are valid uses for transparency. For example, another interesting trick which I won’t perform at the moment is to make the form an irregular shape. Why do forms need to be rectangular? How about one shaped like a circle or a tree? Anyway, these things are done with transparencies.

The result is evident in the image below. Click the image to see a larger image of the same. I’m sure most people would do without the opacity change. Then again, if you have a nice blue background the same level of opacity might be quite attractive. The Restart button was just added to reset the browser control so that I could get back to the beginning page – just in case I did something silly and jumped elsewhere.

Regarding closing the application, it would be possible to close this automatically if we used some channel other than the browser itself to determine if the app needed to be closed. In other words, one approach I might take to this is to have another hidden browser periodically polling the server to see if this user was still active. If not (based on the HTML received by a simple query) I’d just close the whole app. That involves a polling mechanism and a few seconds delay between when the user wants to close the app and when it’s actually closed. This delay could be smoothed over by sending the user to a "Thank you for coming" type page when they exit, and while that page is showing some sort of "please wait as we log you off" progress bar, the other browser is waiting to do its status check. It might be possible for the container to periodically look at the text being rendered in the browser, and if it includes some unique text, then close the app. At this point I don’t know and don’t care – this was a proof of concept and no one has asked for a real solution.

I think you have some new insight into what’s possible, and some information for how to implement it if you wish. If you’d like something like this created for your users, please let me know and I’ll be happy to work with you.