The user is not there to figure out how your software works but rather to complete a particular task at hand. When confronted with an error message, it disrupts the completion of the task.

Had your message read “We have an error, click on this button/link to fix/find out how to fix it” and you may have different feedback.

Yes, that is a trap that I sometimes fall into.

I try to ensure that the important part is in the first sentence, so they can decide whether to read the rest or just ignore the error and continue..

But surely, even if an error message is a long one and you are not a strong reader, it is easier to read through it than to take screen shot and ask someone else to read it for you.

Inevitably, the email I sent back was longer than the error message. Inevitably, the language wasn’t as tight or as clear. I didn’t have the time or the resources to spend on one support email that I could spend on getting the error message “right” the first time.

I agree with you in principle – although I would word the practice slightly differently. It is not the the user “never makes mistakes” as much as “don’t give the user the opportunity to make mistakes”.

As you hinted, sometimes it is not possible. In this particular situation, the solution required a physical action to be taken by the user, which wasn’t something that could be solved by software.

As for the captcha placement – oh dear. I am afraid I have never seen the captcha facility on OddThinking. I am using a SpamKarma, and it only displays the captcha request on borderline cases, where it can’t decide whether it is spam or not. It knows my IP address, and never doubts my email. Mea culpa. I clearly will have to do some more testing; I have been overall impressed with the plugin, so I assumed it was doing a reasonable job here too. Sorry.

[...] user realising their mistake and quickly correcting it

Actually, the best UI design practice is thinking “the user never makes mistakes”. Error messages should be reserved for extreme cases in which the app can’t interpret what the user wanted to do. It’s hard to tell without knowing the details, but if it’s a problem that is frequently reproduced by users and the steps to correct it can be listed, then the problem most likely can be corrected silently by the app itself instead of asking the user to do it.

Example: in Windows try dragging and dropping a document over a running app on the taskbar, you will get a dialog explaining that you should not drag a document over there. The computer knows that I wan’t to do but it won’t allow me. Microsoft should a. implement the taskbar to do something (most likely open the document) or b. change the cursor to a “not allowed” cursor to hint that the action is impossible.