Is it bad practice to disable OS-based 'Features'?

Question

One thing that I can't get my head around is the persistent questioning here, and elsewhere on the web, about disabling OS-based 'features'. People are forever asking how to disable default OS shortcuts (like copy-paste, the Windows key, etc.), or disabling features programmatically.

Surely this is very, very bad practice? To modify a user's operating environment with your program, unless it's specifically targeted at helping the used to modify their own operating environment (which, in the majority of cases I've seen, I highly doubt it). I'd never want a program modifying my bound shortcuts, or changing the default behaviour/feature-set of my environment. Is that a general consensus, or is that just me? It violates virtually every base heuristic and usability/consistency theory I can think of - not least of which, the principle of least astonishment.

The question, then, is this: Is there ever a time (aside from when aiding the user in modifying their environment) when manipulating/changing/disabling features of the operating system, or of the user's general environment, is acceptable practice? Should a program ever attempt to disable the Windows key, copy/paste shortcuts, adjust the Start button text, or anything of a similar vein, without the user's explicit permission, and without the change being fundamentally necessary to the execution of the purpose of the program?

Answer 1

Yes, I think so, although it's rare and should be very temporary. For example, a DVD player disabling the screen saver, or a presentation, game, or "parent-ware" type app disabling the Windows key.

It's very good advice to avoid doing these things, but there are times when it's appropriate and even necessary.

Answer 2

I believe it is perfectly acceptable if you are building an "appliance" for example like the kiosks you find in bookstores. In cases like these it does make sense to disable most of the known shortcuts and features.

Answer 3

I've seen apps (including the Windows OS, I think) that disable cut and paste when in a password text box.

I would agree that there are rare reasons, but that is is bad practice in general.

Answer 4

No.

For normal applications, where the user expects to be in control and may well be running other apps, this sort of behavior serves only to subvert the user's expectations, may damage native accessibility features of the OS, and will generally lead to frustration.

Even exceptions such as those noted by ocdecio and overslacked, though well-intentioned, may fall into this trap (how many games have you played that would crash leaving important system features disabled, or kiosks that disabled task switching but forgot to disable system notifications...) Whenever possible, developers should look first to the OS itself for support in implementing full-screen, restricted, or kiosk applications.

BTW - marking CW, very subjective.

Answer 5

An example of a good divergence from normal interface behaviour is Ctrl-C on a terminal emulator on winblows.

In general, disabling "the normal" O/S interface features is obviously silly. Can you imagine having to search for the brake pedal in a hire car? How safe would feel about driving it off the lot? Having to search for the lights, wipers, indicators, and hand brake is bad enough... The brake pedal should be the one the middle, or the left;-) It Works. Don't Effin Eff With It!

Having said that: Neil Frasers blog systematically destructs many of the "universal tenants" of UI design by evaluating there application to the venerable TI80 programmable caclulator. The phrase "This results in an inferior calculator" somehow branded itself into my brain.

I believe consistency of interface is paramount. For instance, I use a product called SOATest. It's an Eclipse based java-app for test SOAP (et al) web-services. It has one very annoying quirk. Ctrl-Insert and Shift-Insert don't work in any of it's text-areas, but they do work in many (not all) of it's text-boxes. If those keys consistently didn't work I would adapt far more readily. I find this little quirk terribly annoying because (to me as a professional programmer) it represents "just plain ole sloppy work".

So... Keiths first rule of UI design: Whatever you do, FFS do it consistently! Your users are smart, they will adapt.

Cheers. Keith.

Answer 6

Meta answer: It may be a good idea if-and-only-if your real reason for doing it so is in the user's interest.

And don't try to lie to the user about doing it for "security". You can count on being publicly named and shamed.

If you are limiting the user for your advantage, and not theirs, you are in dangerous territory, indeed. Crippling my machine without my express permission will get you put forever on the filter-with-extreme-prejudice list...