SoylentNews is people
SoylentNews
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: 2) by frojack on Friday August 18 2017, @06:26PM
There are a million ways to fail, and (usually) only one way to succeed.
Software (if written professionally) takes into account as many of those as possible.
Every check for proper data/outcome/format/yadda-yadda has a separate error message.
Often there is no value to the end-user of knowing the exact reason the print failed. Because there's nothing they can do about it anyway.
So you give clear messages where the user CAN act, and tech support unique ID messages where the user can't fix it.
Tech support need a unique-ish value to track it to an exact line of code.
No, you are mistaken. I've always had this sig.