This button in this situation produces an error report … therefor the button should be disabled.
I question this line of reasoning. I have observed this reasoning used at all levels, from programmers, to UI designers, to Product managers, and even to customers (users) themselves. The goal seems to be “protect the user from error messages”. Some people naively think that a perfect user interface is one in which the user never sees an error message.
“Good usability” means that a user can use a product without requiring significant training. It should be expert friendly as well as novice friendly. This means that the product itself helps to train the novice user. An error message is an opportunity to learn.
Intelligent people learn from mistakes. My dad used to say that “if you are not making mistakes you are not learning anything.” Imagine, if you can, a school designed around the idea of preventing students from making mistakes. Imagine a math teacher who instead of grading a test, would correct all the mistakes or otherwise prevent students from having incorrect answers. Clearly, the student would learn very little. Students who already knew all the concepts would do fine, but those attending to pick up concepts would be out of luck. It would be “expert friendly” but not “novice friendly”. Allowing students to make mistakes (safely) and learn from them is a widely accepted pedagogical principle.
How odd it is that many software designers attempt to eliminate the occurrence of error reports. Error messages are assumed to be “bad”. Usually it is explained: “the user should not have to see an error message.” So they disable controls. I have covered this in the past with posts Please Don’t Disable My Menu Options! and More on Disabling UI Controls. Because of this misguided design principle, the user interface is not as good at training new users. It seems that such software is designed to be “expert friendly” but not “novice friendly”.
In defense of these people, many software packages have extremely poor error reporting interfaces. Often the software “accuses” the person of making a mistake, blaming them for doing something wrong. This makes error reports unnecessarily distasteful.
An error message should instead be presented as an opportunity to learn something about the program. Like any good tutor, the information is presented at the time that you need it, at the time that you try a particular approach. The error message should contain useful information about why that particular action was not applicable at the moment. From this, the user would learn about the software, learn what was possible, and what is not possible.
Instead of trying to “protect” the user from error messages, we should be aiming for the exact opposite extreme: copious error messages. Instead of disabling actions, the actions should be enabled, and should explain why that action might not be used at that moment, and when it can be used. It is harder to make this kind of user interface, but worth it. It is far more novice friendly because it helps them learn the product as they use it.
Thinking Matters 
Keith
People don’t want to learn. I mean, most of them. There are individuals addicted to learning but they are minority.
Others don’t want to THINK not mentioning learning – consider the popular “Don’t Make Me Think!” principle from usability guru Steve Krug. Some people believe that perfect UI should have just one red button in the middle of a screen.
I guess both approaches – to teach or not to teach – are valid, the question is where to use one or another.
Making UI both novice- and expert-friendly is another big issue. Developers tend to fall into extremes but the compromise can be even worse: a UI uneasy for both categories. Roles and personalization can help but they raise the price consirably.
Anatoly
That is a really good point. Of course, a novice needs to learn, and they know it at some level, but are wishing it was not true.
As an intelligent person yourself, you’ll probably want to fix this typo: “Intelligent people learns from mistakes.” 🙂
But to the point, I agree with Anatoly — not disabling things that will produce an error forces the user to think when the application could do the thinking for them. The exception, for me anyway, is when the disabled thing can be enabled. But if it can’t be enabled (user lacks rights, the feature hasn’t been finished yet), I don’t see a good argument here for allowing the user to make a mistake.
That mistake is terribly funny. Wish I had done it on purpose.
To answer your point, the distinction I make is between “disabling” the control, and “indicating” that it is not useful. The indication of something not being useful is good, because it reduces the number of apparently useful options, and makes your task of finding the one you want easier.
That indication is great, but the meaning of “disabling” has gone to making the control completely dead. I don’t see any defense for making the control dead. If I see it is gray, and I don’t know why, I should be able to click it, and get a detailed “error” message explaining why. This explanation will also be useful to novice users to gain an understanding of what the menu option (which is usually just a single word or two) will do. A user does not always have the same vocabulary as a product, so this mechanism helps user to learn the vocabulary while learning the functionality.
You statement “allowing the user to make a mistake” has a built in presumption that you know it is actually a mistake.
For example, one common pattern is disabling the “save” button after a save, and before anything within the file has been changed. This is the right behavior more than 99% of the time, but there are some occasions when I am working with a source management system, and it has changed the file underneath the editor, and really do want to save the exact same file a second time. This is not a “mistake”. The programmer who designed this has some “theory” about what people want to do, what they do not want to do, and that theory is too simplistic. It turns out I understand this behavior, and work around it by making a non significant change, which re-enables the save button, and then I get it to save. Not all such situations are that easy to work around.
My biggest problem is an editor that I work with that requires specific things in the context to be selected for certain functions to work. For example, if I want to export to a particular file format, the export button is disabled UNLESS I have the root node selected. What happens is that I will have something else selected, try to export, and I am prevented. This is not obvious. What I am doing is NOT a mistake at all. It might be a misunderstanding that I have about how to use the product, but is it not a mistake. I am very clear on what I want to do. The original programmer has a theory that anyone wanting to export to that format will certainly have the root node selected. That programmer may even think it is a mistake. From a usability point of view, I don’t understand why it can’t just locate the root node itself and go ahead and export (in this case there is no ambiguity). Failing that: at LEAST it can tell me that I can’t export because the root node is not selected. You have to read the manual in incredible detail in order to learn this from the manual. But if it would just tell me at the time that I try, then I would learn.
One final example: It clearly WAS a mistake to publish that post with the grammar error in it. Should “Publish” button have been disabled. I agree that it would be NICE to have an indication of the grammar mistake, if possible. It might be nice to receive an error message telling me that I have to fix the grammar error before publishing. But simply being DISABLED is the worst of all possible worlds: I can’t publish and I have no idea why.
Interesting case: the author’s comment turned out to be more clear and more valuable than the original post. Thanks to Stacia.
Ha – I was thinking the same thing, Anatoly. 🙂
I think primary action buttons could be a different beast than check boxes and other form elements…when it comes to forgiveness. I’m not sure why, exactly…I’ll have to noodle on that one.