Agreed, it's important to present errors properly. But really, the best solution is to not present an error at all, in every possible case. Auto-recovery is very important.
The example of the Windows hibernate message, while trying to illustrate a different point, is really a better example of something the user shouldn't have been asked in the first place. The solution is simple: if Windows can try again, why didn't it just do that, maybe a few times, before even thinking of bothering the user?
The case of a failed key may be less trivial, since you don't necessarily want a page that helpfully produces valid keys from invalid ones. And yet, if the key is long enough, and the mistake is small enough (e.g. 2 characters out of 16), perhaps the web page could figure out the closest valid key and just log in using that key (or have a Google-style "did you mean XYZ-123-ABC" link for the matching key).
Disclaimer: I'm not a user interface designer or anything person to this is just my opinion as a user...
I agree, its best to minimize error messages, however...
why didn't it just do that, maybe a few times, before even thinking of bothering the user?
How do you know it didn't (aside from assuming MS is dumb/lazy/etc...)? In any event, this is a case that can come up, and, as the post says, the error message is bad in almost every way.
perhaps the web page could figure out the closest valid key and just log in using that key (or have a Google-style "did you mean XYZ-123-ABC" link for the matching key).
This is actually a tougher case than just that. In fact, the problem seems to start before the error message. If there are two ways to register
1) Sign up for a username/password
2) Enter a key
You should be entering these in different fields and/or pushing different buttons and/or having these on different pages.
This shouldn't even happen to begin with! What did the screen look like? Was the user supposed to type the key into the password field? Thats silly, incorrect and confusing.
About your suggestion for finding a nearby key... I suspect that would be problematic. People use 16 character keys to make them hard to guess. Since only a small number of the 16 character combinations are valid, a random guess is unlikely to succeed. The more leeway you give, the less effective this is. For example... if you allow any two adjacent characters to be swapped, you increase the number of "valid" keys by a factor of 15 (of the 16 characters, each of the first 15 can be "swapped" with the next one).
The screen was clear enough. It had a field for username and a field for password, then the word "OR", then a field for the code. I did the right thing the first time, except for mistyping the code.
I agree that error-correcting the code is needless and probably even a bad idea. But a correct error message ("Your prepaid code is wrong") would have been easy and foolproof.
makecheck, I agree. I almost had a paragraph talking about that, but cut it for length.
There's a general UI principle here: Only present the user with choices they need and want to make. Software, like an efficient employee, can and should make some decisions on its own, only consulting the user when they can make choices better than the software.
Disclosure: I'm posting this to promote my blog and get feedback on it. I read the guidelines and that seems to be within them. Someone let me know if if not.
I'd love HN folks' feedback on this and my previous posts; I'm just getting started as a blogger.
The example of the Windows hibernate message, while trying to illustrate a different point, is really a better example of something the user shouldn't have been asked in the first place. The solution is simple: if Windows can try again, why didn't it just do that, maybe a few times, before even thinking of bothering the user?
The case of a failed key may be less trivial, since you don't necessarily want a page that helpfully produces valid keys from invalid ones. And yet, if the key is long enough, and the mistake is small enough (e.g. 2 characters out of 16), perhaps the web page could figure out the closest valid key and just log in using that key (or have a Google-style "did you mean XYZ-123-ABC" link for the matching key).