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.