Submitted via IRC for TheMightyBuzzard
Try this simple technique to write messages that help users understand the reason for errors.
The first time a user encounters an application's documentation, it's not always with the user manual or online help. Often, that first encounter with documentation is an error message.
Technical writers should be involved in writing error messages. It's an important, although often overlooked, part of the job. After all, error messages are documentation, albeit documentation that's embedded in the code.
[...] An error message should be meaningful. By that, I mean full of meaning not only for a developer, but also for the user of the software. To prevent any panic or confusion, the message should be clear.
A meaningful error message should:
- be short (you can write in sentence fragments);
- contain a description, in plain language, of what went wrong; and
- use wording or a tone that doesn't (whether explicitly or not) blame the user.
Source: https://opensource.com/article/17/8/write-effective-error-messages
(Score: 1) by mobydisk on Friday August 18 2017, @06:43PM
YES! I wish I had mod points! The article is completely wrong: it recommends error messages that provide no useful information. The author says that "Printing failed" is bad but "Printing failed. Please check your printer" is good. No! How about "Printer OFFICE14 is offline" or "Paper jam on printer OFFICE14"
Really, this is about programmers simply not following best practices. If you call a function, and it returns an exception object with a message "Paper jam" why would you write code that says this:
causeOfError = printer1.Print(document1);
if (causeOfError != null) Display("Something went wrong.")
JEEEZ!!! Instead, write:
if (causeOfError != null) Display("{printer1.name} had error {causeOfError}");