views:

91

answers:

8

I'm confusing how to write a good error message for my SW. like this below: "To Save the project, click on the 'Save' button. To Cancel it, please click on the 'Cancel' button." But I think it's really useless, Do you have any comment about how to write a senseful message?

+1  A: 

If this is a prompt, then I would use a question and answer style:

Save changes to this project?

[Yes] [No]

Jon B
+1  A: 
  • Don't state the obvious
  • But don't assume that what's obvious to you is obvious to the user.
  • Link to help topics explaining what the terms used by your message mean
  • Emulate the Mac: Many prompts have a "Huh?" link that leads to further help.
RichieHindle
+4  A: 

Personally I like messages that don't have to explain much. Number one mistake on windows applications is having buttons with standard texts instead of the operation that is performed when pressing it.

Example: Instead of this:

Do you want to save the changes before closing?
- To save the changes press Yes
- To discard the changes press No
- To cancel and keep the application open press Cancel
[Yes] [No] [Cancel]

I like

Do you want to save the changes before closing?
[Save] [Discard] [Cancel]
Stefan Steinegger
User's very often don't read the question. Assume as much and make the button text *actions* not answers.
Chris Nava
+1  A: 

When in doupt, add a help option.

So instead of:

"Enter S for save of C for Cancel"

use

"Enter S for Save, C for Cancel or H for help"

Another big feature is if your application is consistent, particulary with it's operating environment. For example for virtually all Windows applications pressing the F1 key brings up a help screen. Similarly pressing F5 usually causes the current view to be refreshed.

What really drives users crazy is an inconstinent interface. Think about an application wehere sometimes pressing F1 would bring up help while in other parts of the application pressing F1 would mean "delete this document"

For this reason vendors (Apple, Microsoft) often publish style guides on how an application should interface with the user on their platform. For example Microsoft has the Windows User Experience Interaction Guidelines which:

"The goals for these official Windows User Experience Interaction Guidelines (or "UX Guide" for short) are to:

Establish a high quality and consistency baseline for all Windows-based applications. Answer your specific user experience questions. Make your job easier!"

JonnyBoats
Help options often suck. They're distractions from the main task, and often offer information that should have been up front. In your example, the user doesn't want to read a philosophical treatise on data permanence, but needs to know what he or she is cancelling and what will happen with each option.
David Thornley
A: 

If you are talking about error messages then it would be great when you let user know why this error occured.

For example if user see page 404 then you don't need to write a whole article for him BUT you should make reference "Why I see this page?"

If user made simple mistake in URL then he wouldn't open that reference but if your project changed its structure and a week ago it was correct URL and now it's not then user will certainly open reference and read nessecary information. It's a good style.

Roman
A: 

Describe the choices in terms of the user's actions. Be terse. "Omit needless words." Ideally, the buttons will describe the actions, and you don't need text to slow down the user. Assume that the user hates to read anything on the screen; even if the user is highly literate, and using your application to write deathless prose, the user is interested in what he or she has written, and not verbose text about what the system is doing.

David Thornley
A: 

If you're really helping them understand what the buttons do, tell them what will happen after they click them.

So don't say "click save to save" because they might not know what "save" means. Say "click save and your information will be stored for later" or "if you click cancel all the information you put in will be lost".

AmbroseChapel
A: 

Keep it short!

Users will not read a paragraph that explains all the ins and outs of which button to press. You only get about 2 sentences max that the user will read. How many people actually read this second paragraph?

Robert