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.