> backbutton-neutered IE6. Distribute to everyone onsite.
Being Intranet doesn't mean we can assume that all the clients would be using the browser / OS of our choice, not to mention you already included a proprietary software there by mentioning VB. Basically there are several contributing factors, the clients' requirements being the most important of them all. The popup window method will work for all browsers.

> In any context, including Intranet applications, why should 'back' ever need to be disabled?
Crazy clients, crazy requirements.

Wouldn't have to VB, could be C++ et al since the control's an ActiveX, and the same principle applies to all OS that package commonly used components/objects/etc. I was using VB as an example. Could even be done in Java, although not easily.. Alternatively, modify a Firefox version, it's opensource and multiplatform ( maybe write once compile anywhere? no idea ). Intranet implies internal, and companies often control the software on their employees machines.

The popup window method will only work if the browser allows popups, and there's nothing to stop a user re-enabling the toolbar on a popup, or accessing the page without following a path that invokes the popup (i.e direct URL ) still, it's probably a better solution than writing a new browser frontend just to disable 'back'..

I still can't imagine a good reason to disable back. What's the ultimate intention? There will be other means to achieve the same aims ( unless those aims are ultimately to disable back ) without disabling back. That's not to say that those means wouldn't always require any replanning or large modifications; which is why it's a good idea to recognise 'back's' ( and equally 'refresh's' ) existance early on.

All those things would be quite a PITA and I really mean _quite_. Java, yes can be done, but feasible, never. Active-X again MS proprietary. C++, zero feasibility, at least when my ultimate aim is not making a browser. All the options are too much just for disabling a back button or increasing the display area by removing the toolbar.

Intranet applications almost always run in trusted zone so popups won't be a problem unless you specifically plan on disabling them, though it doesn't make any sense as to why someone would disable an intended feature.

Increasing the display area, restricting user navigation, giving the feel of desktop applications, naive guarding against the infamous back button syndrome when using AJAX etc.

>> Increasing the display area, restricting user navigation, giving the feel of desktop applications,

Fair enough, but one doesn't need to disable back functionality for this, you might want a popup, or just provide fullscreen browsing instructions. The backbutton's actual functionality is irrrelevant here, since the intention is, I guess, to remove the toolbar. You still can't stop the user pressing backspace, or having some registered shortcut that does 'back', or even showing the toolbar; but, I guess in these cases, that wouldn't matter since the reason that the button can't be seen is purely superficial.

>> naive guarding against the infamous back button syndrome when using AJAX etc.

It's a naive and unreliable means for restricting or controlling any part of an underlying application. Anything the user couldn't do without a backbutton, they could do by some other means; trying to hack out the backbutton because it messes with some assumption in the application is addressing the wrong part of the problem.

I guess the OP is making some kind of quiz site wherein he doesn't want the user to switch to the previous questions. In that case, implementing this using the server side language of one's choice is the best possible way, IMO.

> It's a naive and unreliable means for restricting or controlling any part of an underlying application.
Yes, I guess that's what I said in my previous post.

>> Being Intranet doesn't mean we can assume that all the clients would be using the browser / OS of our choice
>> Intranet applications almost always run in trusted zone so popups won't be a problem unless you specifically plan on disabling them, though it doesn't make any sense as to why someone would disable an intended feature.

Popup settings aren't neccessarily related the trust level of a zone; a theoretical global setting like 'open popups as tabs' could defeat any attempts to hide the backbutton without directly 'disabling' popups, regardless of the zone; if you can't assume a browser/OS of choice, you certainly can't assume a configuration of choice.

> a theoretical global setting like 'open popups as tabs' could defeat any attempts to hide
> the backbutton without directly 'disabling' popups
You are missing the most important point of this discussion. Users of intranet applications don't try to _get around_ these applications. Suppose you have an intranet application at your work place in which you can check you attendance, your salary slips and all such things related to you, would you still block the popups or try to hack things?

Also if you want to go in nitty gritty details, every action performed on an intranet is almost always logged and monitored. Of course someone who is hell bent on destroying or deliberately hacking the application, there is no stopping it.

I am not saying these things just because I think they should be the way I am saying it, I have seen these things in action, and not one but many. Like I said before, client requirements vary. Would you deny removing the toolbar even whe the client asks for it, yes?

> if you can't assume a browser/OS of choice, you certainly can't assume a configuration of choice.
How about a requirement from client like, "We need this intranet application to work on all OS'es and we don't want to incur extra cost by buying proprietary tools. Oh and please, no custom applications." Plus this what The Web is all about, making applications which run on multiple platforms.

It's not a matter of anyone wanting to get around some protective measure if it's possible for that measure to fail without conscious attempts taken to circumvent it, which in this case it is.

My only point is, there's never really a reason why the back button's function _needs_ to be disabled, and I don't think any client would demand that in a spec, since it's a non-function. If you want to hide the toolbar, you want to hide the toolbar and not only disable the back button, and equally, if you actually want a popup, that's a completely different thing to wanting to disable back. If you want to restrict the user's navigation, you're taking away something a user expects to be able to control without any good reason, and if you want to handle some bug in an application that only occurs when back is pressed; there's something wrong in the application.

I wouldn't deny removing the toolbar in a webpage for a client, infact, I might even deliberately popup and remove the toolbar if it seemed appropriate to do so; but if I was working on an application, I would not make any assumptions about the way the user is going to access it. In short, I wouldn't say 'no I wont throw a popup / remove the toolbar', but I would make sure that the application's actual functionality didn't depend on any page being launched in a popup, in the same way as I wouldn't assume that the pages served by the application will be accessed via Opera9. The fact that an application is or isn't intended to be deployed over an intranet shouldn't really affect design issues at the presentational layer.

That is all. I don't really disagree with you on any point.

If you are using BACK button disabling techniques for an intranet, then also disable bots on your server, so Google won't turn up your page on a search.

www.google.[insert tld] shouldn't be able to find a 'totally' intranet server, since intranets, by definition, are not connected to nor accessible from the Internet, nor subsequently 'the web'. If a certain intranet is accesible (publicly or otherwise) from the Internet, that's OK, and that doesn't make it 'not an intranet', but regardless, no public, or infact any, connection to the Internet is implied.

http://en.wikipedia.org/wiki/Intranet
http://en.wikipedia.org/wiki/Internet
http://en.wikipedia.org/wiki/World_Wide_Web
http://en.wikipedia.org/wiki/Google_search

Read the first paragraph on every page..