Imagine you are gathered with your friends, and you begin describing a historic event that you witnessed on the television ...
This is how error messages often appear to the user. Error messages are often invasive and rude, halting the current activity, and demanding that you acknowledge them before you are allowed to continue. If your friends acted this way, they wouldn't remain your friends for long.
On the other hand, many error messages are ambiguous, failing to provide meaningful information, and at times are simply incorrect, potentially causing undue grief and expense to the innocent user.
Most often, an error message is an explicit declaration that the application developer has failed to anticipate the needs or capabilities of the user.
The examples below demonstrate how error messages should not be written. For additional information, see our page on Writing Effective Error Messages.
Last updated 4-April-2000
We are unfortunately all too familiar with the use of terms such as "Fatal Error", "Critical Error", and "Severe Error", but Ben Speakmon discovered an entirely new type of error in FreeJava:
The message resulted when Ben invoked the Build command after editing a project. Apparently, FreeJava's developers consider the fact than an error occurred as being far more important than identifying the source of the error.
Keith Uher sent in this image of a useless message he received from RoboHelp, an otherwise very useful help documentation utility.
The message appears when generating a Word document from an online help project. It's great that the program offers the option of viewing the results, but in this case, it's the only option; the user cannot elect to not view the document. One would have thought that the very act of viewing the resulting document would have been sufficient indication that the conversion had completed.
Claes Tullbrink discovered this example of circular logic in RealPlayer for Windows, (v. 126.96.36.199):
I have been involved in a number of debates over the years with command-line interface advocates who argue that graphic user interfaces are merely "dumbing down the interface". After receiving images of such informative messages as these in recent Microsoft products, my confidence in the alternative position has been considerably decreased:
Kirill Manucharov sent in this image from Microsoft's Outlook Express.
Sebastian Sorri sent in this image from Microsoft's Outlook 98.
Then again, sometimes Microsoft might be providing more information than they intended. Andrew Chappell swears that he received the following message immediately after booting Windows95:
I discovered the following message at a most unfortunate time. More than halfway through the download of a 400MB file, I accidentally hit the Windows close button in CuteFTP. Fortunately, the application displayed a confirmation message. Unfortunately, none of the developers had ever looked at the message:
The most insidious aspect of the dialog is that it does not provide a clear way out. I would have appreciated a clear confirmation message:
|You've been downloading this file for more than 2 hours. Are you really sure you want to throw all that time away?|
|[Yes]||[No, it was a mistake!]|
Instead, CuteFTP merely offers an OK button (No, it's definitely NOT OK!) and a Help button that does ... nothing. A word of warning: Do not hit the OK button. If you want to tell CuteFTP that you didn't really intend to cancel the download, you are expected to hit the little X button in the title bar.
BTW, the dialog title should raise an eyebrow: "Dialog"? This is supposed to be meaningful ... how?
I have long held the belief that poorly designed development tools and training are among the primary contributors of poorly designed user interfaces. The help file for Microsoft's Access provides such an example. In the discussion of formatted message boxes, Microsoft suggests that the developer "enter the following in the message argument: Wrong button!@That button does not work.@Try another." The direct result is as follows:
The indirect result is that would-be developers are taught that tossing such messages at the user is an appropriate design strategy. It is not.
Luke Tomasello sent in this image of an error message he received while working in the Microsoft Developer Studio:
Luke was struck with the "hopelessness" of the message. I've read the message several times, and can only conclude that the dialog box desperately needs another button:
I don't know!
James Hewett-Hicks sent us this image of a message he received from Banyan Vines' BeyondMail®. According to James, the message appeared "out of the blue" while the program was minimized. As to the practice of placing the error code in the title of the message box, well that is simply BeyondBelief®.
As stated elsewhere on the site, Paint Shop Pro is an excellent graphics application, but at least through version 4.12, it has one extremely annoying interface inefficiency. When exiting the application, the user is prompted to save each unsaved image. The fact that it prompts the user is quite nice; unfortunately, since the prompt dialog does not provide a No to All button, the user is forced to respond to the prompt for each unwanted image. As is often the case when preparing images for the Interface Hall of Shame, a Paint Shop Pro session might involve many images, only one of which will ultimately be saved for use. Unfortunately, without the No to All option, the user is forced to specifically tell Paint Shop Pro, "No", "No", "Nope", "Not that one", "Not that one either", (sigh), "No", "Uh-uh", "If I wanted that one, I would have saved it", "nope", "no", ...
It would appear that the reason for the omission is that PSP is relying on the Windows built-in message box functions, which do not support a No to All button. While reliance on the built-in functions relieved PSP's developers from the negligible burden of creating their own dialog, it often requires the user to respond to a plethora of useless messages.
Bob Rock received this message when attempting to delete the Internet Explorer cache from within Windows Explorer. Unfortunately, the message box did not provide a Delete All command button, requiring Bob to individually confirm the deletion of hundreds of cookies.
Not surprisingly, Bob tried to give up after a while, and clicked No button. Unfortunately, this provided little satisfaction, since Explorer continued to provide confirmation for each of the remaining cookies.
The wording of the message is rather interesting:
Cookie: X is a cookie!
Aside from its inherent redundancy, one has to wonder about the emphasis placed on the fact that it's a cookie. To a web-savvy individual, that would be a meaningful statement, but I would bet that a large percentage of Win95 users would have preferred an alternative command button:
I Don't Know...What's a Cookie?
When the user clicks the Cancel button while performing a spelling check in Allaire's HomeSite 4.0, the program thoughtfully displays a modal message to inform the user that ... the spell check was cancelled.
Veikko Punkka sent us this image he received from Lotus' cc:Mail:
In Veikko's own words:
My favorite error message is the delightful 'No Error' occasionally encountered with cc:Mail. While having 'No Error' sounds like a good thing, it is labeled as a fatal error, which sounds like a bad thing. When the user clicks on the OK button, cc:Mail terminates, which seems to indicate that having 'No Error' is a serious error in cc:Mail. Then again, maybe using cc:Mail was the error, in which case exiting the program just corrects the error with the result of there being no error.
Mathew King sent us this poorly composed error message he received from JDeveloper:
We're just glad that the filename wasn't any longer, which would have prevented the user from ever gleaning the intent of the message, and the meaning for the various buttons.
Visitor Thomas Emhardt described the uniquely aggravating method taken by the shareware e-mail application AK-Mail to protect users from themselves. When the user attempts to delete a mail folder, the program requires the user to type the response "YES" into the text box ('Y' will not suffice; the OK button is disabled until all three letters are typed). Thankfully, the program does not require similar actions when deleting a message nor when deleting an address book entry; in these scenarios, the standard 'Yes-No' confirmation dialog is used.
Jim Murphy sent in this troubling confirmation dialog he received from Eye Candy v. 3.01, a collection of plug-in filters for graphics programs. The message was displayed in response to Jim's having inadvertently selecting the Delete button when reviewing a list of user-defined filters. Given no other option, Jim had to resort to the infamous three-finger salute (CTRL-ALT_DELETE) to exit the application, which resulted in the loss of his work up to that point.
The problem was corrected in version 3.03 of the program.
Paul sent us this image of the first dialog displayed after installing MultiEdit, a program advertised as being the ultimate editor for all programming needs:
I was suprised as soon as the program started... Up comes a "Critical Error" message box. What's wrong? I thought. Nothing, the program just wanted me to select a keyboard mapping. Call me picky if you want, but when I see a big X in a red circle I assume that a serious error has occured.
Ed Chaney sent us this image from Microsoft's Internet Explorer 4.0. According to Ed, the message results when logging into an FTP server fails for just about any reasion (but mainly when the server is full). While the server may have returned extended information, Microsoft clearly decided to withhold it from the user (perhaps Microsoft felt that learning that the server was full might be just a bit too technical for the typical IE user).
Florian Hoornaar sent us this image of a particularly meaningful message from Microsoft's Access. Hmmm...what would you do?
Bobby Jack sent us this image he often receives when trying to load Netscape Navigator on the university network. Netscape would have had a hard time trying to fit any additional information in the message, and an equally hard time being any less clear.
(A side note to Netscape: when you suggest that the user hit the Continue button, you should probably include a Continue button on the dialog).
Visitor J. Peter Mugass pointed us to the web site that displays this error message to any user who chooses to visit it.
This is an absolutely stupid message, not just because you should never design a web site for a particular resolution, but because this message is displayed to all visitors regardless of the resolution of their screens. It is particularly bad because the page stops loading until the user responds to the message. A question to Sungate Technolgies, the web site designers and author of the message: what is the functional difference between the OK and the Cancel buttons?
Carl Fink sent us this image of a message he received from Microsoft's Word 97, which reminded us of the old MouseTrap board game from Milton-Bradley.
The message arises when you elect to spell-check a document that contains text that you had earlier indicated that you did not want to perform spell-checking on ("no proofing"). The message is certainly informative, but requires that the user either have an exceptional memory, or have pen and paper handy to write down the Rube Goldberg steps that it refers to.
We would like to thank Ludwig Alberter for informing us about an absolutely frightening warning message generated by Microsoft's Office '97:
The message is generated when the user requests that a shortcut icon on the Office shortcut toolbar be deleted (using the toolbar's Customize function). In the example above, we added a shortcut to an image file, then asked that it be deleted.
As Ludwig explained,
Never mind the typo in the sentence ("that that"), but the whole meaning is just rubbish - the only thing that gets deleted is the shortcut button, as expected.
Rather than "as expected", we would have used the phrase "as requested". Indeed, we would expect that the message would unnecessarily frighten most users into keeping unwanted shortcuts on the toolbar.
Go ahead, delete those shortcuts. Microsoft dares you.
Christian Kanja sent us this useless error message he came across in Microsoft's Data Link application. We are reminded of the following refrain from Bob Dylan's Ballad of a Thin Man:
Because something is happening here
But you don't know what it is
Do you, Mister Jones?
It would seem that Netscape's Hidden Frames function generates hidden messages as well. We've come across this ... message in Navigator, but as could be expected, we have no idea what it means or why it was generated.
Garry Glendown sent us these images he received while uninstalling Team Flow Server.
What happens if the user decides that he or she does not want to uninstall the application?
Carl Fink reminded us of this feature in Paint Shop Pro, which illustrates a completely avoidable error message. If there are no options available, then disable the Options button.
Aside from the fact that the message even exists, it should be noted that its wording is quite dubious. Paint Shop Pro is an image editing application, as such, the term "selection" has a particular meaning; it refers to that area of the image you have selected for editing. The use of the term "selection" in the error message is misleading; in this case, it refers to the selected "Fill Style". Many users will not realize the developer's error.
We normally do not include interface examples from games, but we found this particular message in Jazz Jackrabbit 2 to be particularly illustrative of a major problem with error messages. Specifically, this message is not intended for the user; it is a message from the developer to the developer. The person most likely to see it however, is the user.
Let's try to determine just what happened here. Is it an "Application Error", a "Fatal Application Error", and "internal error", or an "Amnesia Error"? Did the developer screw up by not allocating enough memory, or was there not enough memory available to be allocated? Is there something the user can do to alleviate the problem (apparently not), and what would prevent the user from concluding that the message will reappear when the application is restarted (nothing).
Geeks. Can't live with 'em; can't live without 'em.
The following message was discovered by Bret Empie while using Microsoft's Visual Fox Pro 3.0
I suppose there is something messed up in the environment to generate the error, which occurred when I tried to display my OLE Controls library in Visual FoxPro 3.0. Anyhow, one might wonder how we are expected to close the drive door on a partition.
While some programmers might readily understand this message, we would consider it beyond the understanding of most computer users, especially for the target population of the particular application that generated the message. The message is displayed by Dr. Zeuss's ABC, an alphabet game intended for 3 to 5 year-old children. Funny thing though, the message is completely unnecessary, since the program works just as well at any typical display setting.
We came across this informative error message in Microsoft's Visual Basic 5.0 recently. Since the message provides no indication as to the problem nor its cause, we decided to accept Microsoft's offer for assistance. After pressing the Help button, we were rewarded with the following insight:
Visual Basic encountered an error that was generated by the system or an external component and no other useful information was returned.
The specified error number is returned by the system or external component (usually from an Application Interface call) and is displayed in hexadecimal and decimal format.
In other words:
Something bad happened. We don't know what it was or what caused it. All we do know is that the hexadecimal number you see is a hexadecimal number, but the number itself is meaningless.
What the help file left out was the solution: reboot windows, again.
Which of Microsoft's minions is responsible for this error message in Access 95? The error message results when the user has selected a record to be deleted, then presses the ...Delete button. We can understand the desire to obtain confirmation from the user before performing a destructive action, but we find the wording of the message to be particularly presumptuous: "Solution" implies that there is a "problem". In this case, there is no problem: the user in effect said, "Delete the record".
We are also bothered by the permitted alternatives of "Yes" and "No" in response to a non-question. The developer might just as well have labeled the buttons "Potatoes" and "Ham" and said, "Click Potatoes to permanently delete these records...". In this context, "No" is no more meaningful than "Ham". Perhaps recognizing this, the developer chose not to mention the "No" button in the instructions. He or she should have; since the record is visually deleted before the message appears, selecting "No" would indeed seem to "undo" the action, thereby revealing the error of the error message.
A much more grammatically correct, less arrogant, and far more understandable method would have been to simply ask a straightforward question: "Are you sure you want to delete this record?", and provide straightforward options: "Yes" and "No".
Like Access 95, Windows95 has a tendency to create "problems" where there are none. The above message is generated when the user cancels a Print command from any of Explorer's many incarnations (Explorer, the uncommon file dialogs, and the Find Applet). Upon selecting Print, a progress dialog is displayed which offers a Cancel button to cancel the print. If you hit the Cancel button, intending to, perhaps, Cancel the print, Windows95 reports that a "problem" has occurred.
Microsoft's Notepad, even after some ... oh, about 7 years of development and re-release, still has a problem with handling files greater than 32,000 bytes. In this particular example, Notepad allowed the user to open the file for editing, but upon the first editing operation, promptly displayed the message shown above.
The message is patently false. The problem is not that the computer does not have enough available memory; you could quit (and remove for that matter) every application on your computer and Notepad would still say you don't have enough memory. The problem is that Notepad itself cannot deal with files that are above an arbitrary size, due to an elementary and insufficient programming model, and Microsoft's reluctance to update this very popular tool.
This message from Microsoft's Access 95 seems relatively benign, until one considers the context in which it arises. The message results when the user attempts to use the "Save As/Export Table" function, and selects the option to "Save the table to an external file or database". The user is then prompted to select a file type from a list of permissible file types, and Access generates an appropriate name for the file.
So far, all is as it should be.
If the user selects the "Microsoft Excel" file type from the list of permissible file types, Access will create a new Excel file if one does not already exist for the specified name and path. However, if the user selects the "Microsoft Access" file type from the list, and if a file by that name does not exist, rather than creating the file, Access displays the message shown here, telling you to go do it yourself, even when you used the file name that Access itself generated. This is not as it should be.
Interestingly, Access does not allow the user to create a new database while keeping the existing database open. For the message to be truly correct, it should instruct the user to close the current database, create a new database, close the new database, open the previous database, and only then, attempt to export the table to the new database. This is usability at its best!
Dan Sneddon sent us this image of a message generated by Microsoft Excel. We are not sure which is more shameful, the confusing options, or the fact that Microsoft's technical support claimed it was due to an "improper installation."
Here's an example of a completely unnecessary error message provided by Paint Shop Pro 5.0. The program correctly remembers the last directory from which the last image was opened, but if that directory happened to be the floppy drive, the program will search the floppy on the next open, even if the next open occurs weeks later. If there is no floppy in the drive, the error message is generated, requiring the user to respond to the message before the program can proceed. Such a message should only be generated when the user has specifically requested that the program look on the floppy.
This is one of those truly unnecessary error messages that has no right to be in an application. The message is displayed in Visual Forms when the user has selected the Preview function, without having first specified the browser to use to view the document.
Since this is likely to occur the first time the user tries to view his or her work, (as it happened with us), why not simply display the Select Browser dialog, without showing the error message?
Why did the developer feel it necessary to shout at the user? If I had the chance, I'd shout back, "Why the heck is the button labeled 'Yes'?!!!
Can't we all just get along?
The registration page at Microsoft's Developer's Network web site thoughtfully provides an option to indicate that you do not wish to receive faxes. Unfortunately, well...the image says it all.
We found it especially interesting that the fax number is required only when you select the "no faxes" option.
Is it any wonder that many people consider programmers to be geeks?
Matt McClinch sent us this image of a bizarre error message provided by Eudora Light, a popular e-mail program. Matt, a computer science student, was able to determine that the message was attempting to indicate that the mail client was not adhering to the SMTP protocol. Non-programmer types would probably wonder, "Huh? What did I do wrong?"
The problem here is two-fold: the Eudora programmer improperly chose to "parrot" the error message generated by the SMTP server, and additionally, improperly chose to frame the message in the context of a dialog between the two machines. We have no difficulty imagining the programmer sharing the resultant message to his programming friends, snickering ala Beavis and Butthead at his keen sense of humor. We'd suggest that he take a day off from the computer, and go out and interact with a few non-programming-type individuals.
(We can't help but wonder what 503 impolite people would say...)
This message is generated by OzWin II, a popular off-line reader for the Compuserve Information Service. The error occurs when the user clicks the OK button on a window containing a list of items to be selected; in this instance, the list consisted of a single item. This is a rather nefarious message, since only programmers would understand its meaning. To most users, it only conveys that they must have done something wrong.
There is only one reason for such a message: the programmer was lazy. He or she simply chose to display the error message generated by the programming environment, rather than providing a message that would be meaningful. Moreover, the message could have been obviated simply by having a default selection in the list. In most programming languages, this would have taken one extra line of code.
One of our visitors sent us this image after an unsuccessful attempt to access our former site. The message was generated by Microsoft's Internet Explorer, and not surprisingly, left the user in a rather confused state. It would appear that the developer was in a similarly confused state when he or she composed the message.
We came across this confidence-inspiring message in several areas of Microsoft's Visual Basic 5.0. The first time it appeared, we took a chance and hit the OK button, which only had the effect of displaying the same message again. Clicking the Cancel button cleared the message and the program proceeded apparently as it should.
We came across this gem in one of Compuserve's programming forums. We've reproduced it here not so much as an indictment against the programmer (who should have been more careful), but as an illustration of the awesome respect some users have for computers, and why it is so important to be careful as to how we communicate with them:
Yesterday a young secretary called our helpline saying she's following the instructions on screen, but when she types in the word "mismatch", nothing happens! A bit puzzled, I asked what it is she's actually trying to do, and she says she's hit File/Save and now a message has appeared saying "Type mismatch".
... very embarrassing for three of us: her, me and our tester (who'll be on short rations all next week!).
For those who may not be familiar with the phrase 'Type Mismatch', it is an error message generated by the programming environment, and indicates that the programmer has tried to set a variable to a value of the wrong data type, such as setting a number variable equal to a word, as in TotalSalary = "Massachusetts". Steve should have been checking to make sure that the error did not occur, and if it did, provide a meaningful message, rather than relying on the system error messages.
This completely ambiguous message appears in a sample program provided to developers using Gupta's SQL Windows development system. It appears in response to a prompt for a Check-In Date in a hotel desk sample application. The message provides no indication of the correct format of the date. The message would be unnecessary if the program defaulted the date to the current date.
This message is generated by the SQL Windows development environment. It arises when the developer has typed an incorrect statement while writing a program. The available responses are meaningless: what does 'Yes' do - retain the incorrect statement?
The really unfortunate aspect of these error messages is that programmers learn primarily through example. When the programming environment itself generates poor messages, and the sample programs contain poor messages, is it any wonder that the programmers will tend to write poor messages in their future applications?
Paul Adams wrote to us to point out a rather bizarre and potentially destructive error message provided by the Find File function in Microsoft's Office 4.2:
I was trying to search my entire hard drive for a file. Although I don't know the exact number of directories, it isn't very many. I would think the programmers should have anticipated users searching an entire drive for a file. That aside, why in the world would they suggest deleting "one or more directories" as an acceptable method of resolving this problem? This is the most dangerous error message I have ever come across. I can't believe this was in a commercial product.
It would seem that the developer should have been a little more careful in his or her advice. The intent of the message was probably to decrease the number of directories specified to be searched, since the Find File function allows the user to specify multiple discrete directories, but the message as written might lead some users to actually delete the directories from the hard drive.
This example suggests another useful guideline for developers:
You are responsible for any misinterpretation of your messages.
How should you respond to the above? This message is generated by the FileFind function in Microsoft's Word for Windows, when the user attempts to copy a file to the same location where it is currently located.
Word appears to cancel the operation in response to either the OK or Cancel buttons. Actually, different things can occur, depending on the number of files you have attempted to copy. According to Microsoft:
If one file is selected, Word cancels the function in response to either OK or Cancel. If multiple files are selected, Word cancels the function for one file at a time when you choose OK. If you choose Cancel, Word cancels the entire operation for all selected files.
Clear enough? You might have expected that the Help button would supply this information. Nope, we had to search Microsoft's web site to find it. If you press the Help button in response to this message, all it tells you is that:
You tried to create a copy of a file that uses the same filename and location as the original file. You cannot copy a file to itself.
To correct this problem
- Type a new filename or path.
Gee, thanks for the insight!
Ambiguity in action. This unclear message resulted after the user mistyped a filename, something a user should never be required to do. Most operating systems have built-in file selection dialogs that programmers can easily use in their programs. The file selection dialogs make it impossible to mistype a filename. Not using them is an indication of laziness, and an invitation to mistakes.
Messages similar to this are perhaps the most common, and the ones most easily avoided. This message is generated by the Address Book applet of IBM's Aptiva Communication Center when the user has pressed the Change button when looking at a blank record. Maybe it's a stupid mistake, but when stupid computers allow people to make stupid mistakes, we'll make them. What the user does not expect is a computer with an attitude. The message might as well say: "Change?! How stupid are you? What the heck do you want me to change?!"
There is an obvious solution, which has become a standard of graphic interface design: never provide a function that will only result in an error message; disable any functions that don't apply.
This is a truly insidious error message, provided all too often by Visioneer's Paperport, an award-winning, very useful document imaging and management application. The message is not necessarily rude or ambiguous; the problem is due to the fact that it is incorrect. It results from a bug in the software such that it does not correctly determine the amount of available computer memory for certain Windows95 users. Because of the message, users have reportedly removed software from their computers, repeated reinstalled the application and the operating system, and in some cases, spent hundreds of dollars purchasing additional memory for their computers, all to no avail.
A note to all application developers: make sure your messages are correct!