When you're a kickass programmer who spends more time with the compiler than with other human beings you tend to run into problems. You start to think of your code as a way for you to interact with your machine; instead of also considering it a way for you to interact with your end-users and other programmers who maintain your code. Long story short, you become slightly inconsiderate about your end users and you start thinking more-and-more like a machine.
You swing like a pendulum, sometimes expecting your users to understand stack-trace of your exceptions, which you display as error message, and sometimes considering your users to be complete idiots who understand nothing about software; so you lean towards not even telling them what went wrong and lean towards completely lame and generic error messages.
At Multiplitaxion Inc, I happened to witness an application where I saw a team lean towards the later. Someone in the team had found the ultimate way to encourage reuse in code and centralize exception handling. The result: Every crash that the application went through showed one generic error message. 'Error Encountered. Our support staff is working on fixing this'; or at-least, something to that effect.
After we played around with the application for a couple of days we knew exactly what to expect when 'anything' went wrong with the application. After a few weeks it turned into a joke; every time the our-support-team-is-working-on-fixing-this error appeared on the screen, there were remarks which were on the lines of, "awesome! now we know the support staff has some work to do and is finally working". I officially declared this as the forty-two of all error messages ever invented.
As hilarious as some of the jokes regarding the support-staff-is-working-on-fixing-this error were, there was something fundamentally wrong about the error. The ingenious idea of a 'generic error message' seemed to work under the premise that the user is an idiot who doesn't even have to be told what went wrong. To say the least, the error demeaned the ability and intelligence of the end user and whispered gently to the end user telling him - 'you're an idiot'.
The other extreme is telling the user everything that goes wrong in the application and expecting him to understand your code and stack traces. This approach turns out to be equally rude and demeaning. About Faces 2.0 by Alan Cooper and Robert Reimann illustrate the beautiful point about most applications being 'rude' by displaying irrelevant errors to the user and blaming the user for the error. They explain their point by using this error as an example:
Alan and Robert explain how this error and software applications in general are not just loud; but also rude to the end-user. Their initial reactions as they encounter this error are not just humorous but very close to how an end user's mind subconsciously thinks when it sees the above error-dialog for the first time:
|
Thanks for sharing. Why didn't the program notify the library? What did it want to notify the library about? Why is it telling us? Why do we care? And what are we Ok'ing, anyway? It is not OK that the program failed! Software is often rude to the user. It blames the user for making mistakes that are not the user's fault, or should not be. Error message boxes like the one in [the picture] pop up like weeds announcing that the user has failed yet again. These messages also demand that user acknowledge his failure by agreeing: OK. Software frequently interrogates the user, peppering him with a string of terse questions that he is neither inclined or prepared to answer: "Where did you hide that file?" Patronizing questions like "Are you sure?" and "Did you really want to delete that file or did you have some other reason for pressing the Delete key?" are equally irritating and demeaning. |
If there is one underlying theme in either providing completely irrelevant code related details to the end user or not even telling him what's wrong, it is the programmers inability to think like the end user. As programmers we go from expecting the users of our applications to be just as technically savvy as we are to being a complete idiots.
Most programmers may not admit to looking down on users who are not very technically savvy but the fact of life is that we tend to do just that when we write code. The LiveArt example, which made it's way all the way to the CNN website is a classic proof of this:
|
Of course, there are degrees of rottenness. "Some bad error messages," Ezzell says, "are just placeholders that slip through. We've all been there." Ezzell acknowledges he once wrote a message that addressed the user as "Dumbkopf" and was mortified when the dialog made its way into production. Thus, he sympathized with Orem, Utah-based Viewpoint DataLabs, which managed to include the following in its LiveArt install: Setup is unable to locate a suitable version of DirectX on your machine. You will need to install DirectX before you can use LiveArt98, dumbass! Sympathy notwithstanding, Ezzell awarded the entry third prize. Red-faced developers at Viewpoint noted that the message had simply slipped through the quality-assurance cracks and that they'd fixed the problem "about 4 seconds after we realized it was still there." |
Yes, of-course the 'dumbass' part in the installer of LiveArt was an innocent joke by the programmers; but none the less it is an indication of the fact that most of us programmers tend to find the fact that computer users aren't as technically savvy as us, somewhat funny.
As a matter of fact, the truth is actually a little darker than that. Actually, we don't want our users to be as 'smart' or 'intelligent' as we are. We expect them be just 'like us'. We expect them to be just as connected to the compiler as we are, just as absent minded as we are and sometimes even just as 'stupid' as we are. If you don't really buy my point, the same CNN article, brings to you a few hand-picked error messages from the history of computing from environments ranging from Microsoft Windows to Unix:
- Error: Keyboard not found. Press F1 to continue.
- Windows has found an unknown device and is installing a driver for it.
- Error 0000: No errors found, restarting computer.
- The procedure failed with the following error: The command completed successfully.
- Cannot delete tmp150_3.tmp: There is not enough free disk space. Delete one or more files to free disk space, and then try again.
These are classic error messages which may or may not have slipped through the cracks of QA or maybe it is a classic case the technical teams, not even realizing there was anything wrong with any of these messages. Of course, they were neither hoping nor expecting that the end users will feel a little, lost, when they encounter these messages.
Ben Ezzell has an entire site dedicated to the stupidity of the error messages; but Ben is not just critical. His criticism, like any good criticism, happens to be fairly constructive; it goes all the way to writing Developing Windows Error Messages; which provides excellent advice to developers. In his book, Ben advices that developers should work hard at trying to see that at the bare minimum, each of their error messages they write at-least help answer the following three questions that users typically have when an error occurs:
- What is the problem?
- Why is it a problem?
- What can I do to solve the problem?
The task of displaying relevant and appropriate error messages to the user is an art picked with time and experience. As much as using accurate, easy-to-understand-and-act-on Error messages might sound trivial to us as programmers; the act coding your error message has deeper impact on how people perceive your application and the love they give back to your application.
Of-course you can continue to classify making your error messages meaningful, sensible and genuinely helpful as a 'trivial' task which can be fixed 'later'; after you are done with your functionality; but there's one tiny little problem with that approach; after you're done, the 'later' never comes. Besides, not asking unnecessary questions; and eliminating un-necessary warnings is a way of life which requires considerable discipline throughout the development cycle. Don't take your error messages and the politeness of your lightly. Consider spending some time thinking about these items as you code.
Go the extra mile and every time you write an error message question yourself - do you really need to inform the user about this error or can you fix it yourself? is your error message full of errors? Is it outright rude? Assuming that the user understands your stack trace is expecting too much from him. Assuming that he is stupid and hiding sufficient details from him is stupidity on your part.
Making your error messages sound like it's the users fault or making it sound as it was some external factor which caused the error to occur and then providing no clue about how to fix things is even worse.
After all, if your application doesn't work, we all know who is responsible for it.
On a serious note, don't write rude applications, May I suggest that we as programmers, consider introducing some 'politeness' in the applications we build.
Building applications that are not rude and avoiding errors in your errors is an art. The level of politeness you introduce in your application will usually decide the love it gets from it's users. Now go search all the error messages in that codebase you're working with and start reviewing them meticulously; can you find errors and warning which can be avoided or eliminated? Are your error messages full of errors? Are your error messages outright rude or demeaning to the users? Consider putting in some effort and thought towards making them meaningful, polite and genuinely helpful.
Comments are closed.