I was having a discussion with a coworker today about the user interface for his application. There is an Admin menu that the site IT folks will need to setup the application for the first time on a computer.
He was mentioning he was going to make the Admin menu disabled for non IT folks, and instead I suggested he make it invisible. Why? He asked. Good question.
Human nature is the best answer. Your average user is going to be content with what they have, but there will always be those who want more. They are curious about what they are missing out on, or are not satisfied unless they think they are getting the “full” software, even if it’s functions they don’t need.
In large corporations, these folks tend to be, er well rather insistant, and if they have a supervisor who likes to take the easy way out, he may wind up telling IT to grant the user access he shouldn’t have.
Instead, I have a firm design principle: Ignorance is bliss. In this case, if the Admin menu were hidden, the problematic users would never know it even exists, and live in happy igornace, causing problems elsewhere.
So here’s the rule: If there is functionality a user will never have access to, such as an Admin menu, then it should be hidden via the Visible property.
On the other hand, if there is functionality that is enabled or disabled based on the state of the app, use the Enabled property. A good example might be the Copy function on the Edit menu. If no text is selected, then Copy should be disabled as there’s nothing to copy. It servers as a visual cue the user has the application in a state that the Copy function makes no sense. Once text is selected, Copy should be Enabled.
Another example might be a Save function, if the required fields are not completed, disable the Save as a cue to the user he still has work to do.
And there you go, Arcane’s GUI Rule for Enabled versus Visible Properties.
Arcane Code 
I tend to agree with you as a general rule of thumb. For units of functionality that shouldn’t be accessible, it is typically better to completely hide it. Depending upon the application/environment, there could also be security concerns by exposing unnecessary functionality…even if it is disabled. A persistent, clever user can sometimes discover a path to what was thought to be inaccessible.
There may be some special situations where it is more appropriate to disable rather than hide, but I have a difficult time thinking of one off the top of my head. Even if I could, I don’t see any harm in going the invisible route regardless.
My approach would have been a different executable… specially if it is only used for initial set up. I believe in making admin tools for IT folks rather than visible or enabled features inside an app.
This particular item may not be the best example, especially with it being for administrative purposes.
But the principal in general is sound. A better example, we have an app that does very specialized reporting. The app allows users to either define their own filter criteria, or select from a predefined list of filters.
The business unit was adamant we control who can and can’t create a filter. (In a similar app users were allowed to create filters at will, and they wound up with literally thousands of filters with names like “Joe’s filter” and “Joe’s other filter”.) So for our filter administrators we turn on the visibility of the Filter Admin menu, non filter admins never see it.
Arcane