Okay... that redesigned error message looks like every error message I run into on Windows and the link always points to a useless page on microsoft's website. I prefer the other error.
Actually, the other day I was installing a patch to a Microsoft game, when it crapped out on me and rebooted.
I got the "would you like to report this information to Microsoft" prompt, figured "hey, it's Microsoft game after all" so I hit yeah, and it opened up Firefox and told me that the problem could be addressed by downloading an updated sound driver.
So Microsoft does do this right, when there's a solution.
That seems to be more a problem with Microsoft's website interface or coverage of possible errors than with the error dialogue itself. So theoretically the redesigned error dialogue could work.
Hmm do you really want "Whoops, we apologize a slight error has happened, but behold everything is alright..." instead of "Error C0000005 go google this"?
I am guessing that there are dozens or maybe hundreds of assertion type errors like this buried in the code. Only a small fraction of them turn out to be real errors that actually occur in the field.
So presumably the guy who coded the original error message didn't anticipate real issues and likely didn't have a handy resolution available. Only later, once the code was in the wild and the error started happening reasonably frequently in the real world did customer support investigate the problem more. Eventually a workaround was developed and made available on a website.
Sure, but the link could go to a dynamically generated page; for the truly rare (or nonexistent) errors the response will be sparse, but for the cases that arose semi-frequently after the app was released into the wild, the website could have up-to-date fix info.
Defensive Design by 37 Signals and Don't Make Me Think by Steve Krug are both great books about how to design for when things go wrong. Engineers, in addition to designers, should read these books post-haste. EDIT: If you're a hacker in SOMA/SF and want to borrow either of these books they're very quick reads.
The trouble with technical error messages is that almost invariably, engineers end up writing them. "Not my area of expertise" or "I put in a request for copy months ago" are some of the many reasons that poor error handling happens.
Additionally, having a truly helpful environment requires additional resources: In the example in this article, the "Heres how to fix your problem!" link would require an additional application to keep track of known issues and solutions.
That being said, it's exactly how every application should work: Error messages like this may not be daunting to more technically proficient users, but the vast majority of users are not technically proficient and many users simply give up (if they can) when they see an error message that they are unable to understand/fix.
I think that this error is intended to portend that you aren't allowed to use a computer without a keyboard attached. You must have a keyboard attached.
Hear, hear. Apple is only a notable example because its products are vaunted for their relative attention to detail, but the problem is industry-wide.
I don't know if end user-facing text needs to be written by marketing, but all strings in a software product should at least be reviewed by somebody in the organization with some minimum set of credentials in the target language. A tech writer, for example. It's incredible to me that this is overlooked pretty much across the board.
