Significant messages in your software

I am confusing how to write good posts for my SW. as below:

"To save the project, click the Save button. To cancel it, click the Cancel button."

But I think this is useless, do you have any comments on how to write meaningful posts?

+1


source to share


8 answers


Personally, I like the posts that don't need much explanation. The number one bug in Windows applications is having buttons with standard text instead of an on-click operation.

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]

      

+7


source


If this is a hint, I would use the Q&A style:



Save changes to this project?

[Well no]

+1


source


  • Don't state the obvious
  • But don't assume that what's obvious to you is obvious to the user.
  • Link to help topics that explain what the terms used by your post mean.
  • Mac emulation: many prompts have "Huh?" which leads to further help.
+1


source


When you are idle, add help.

So instead of:

"Enter S to save C to cancel"

using

"Enter S to save, C to cancel, or H for help.

Another important feature is that your application is compatible, especially with its operating environment. For example, for almost all Windows applications, pressing F1 brings up a Help screen. Likewise, pressing F5 will usually update the current view.

What really drives users crazy is the inconsistent interface. Think of an application that sometimes prompts help when you press F1, while in other parts of the application, pressing F1 means "delete this document"

For this reason, vendors (Apple, Microsoft) often publish style guides on how the application should interact with the user on their platform. For example, Microsoft has a Windows User Experience Guide that:

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

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

+1


source


If you are talking about errors, then it would be great if you can tell the user why this error occurred.

For example, if a user sees a 404 page, you don't need to write an entire article for them, but you should make the link "Why am I seeing this page?"

If the user made a simple mistake in the url then he will not open that link, but if your project changed its structure and a week ago it was the correct url and now it will not then then the user will definitely open the link and will read unfinished information. It's a good style.

0


source


Describe the options in terms of user actions. Be careful. "Omit unnecessary words." Ideally, buttons describe actions and you don't need text to slow down the user. Let's say the user hates reading anything on the screen; even if the user is highly literate, and using your application to write immortal prose, the user is interested in what he or she wrote, rather than a detailed text about what the system is doing.

0


source


If you're really helping them understand what the buttons do, tell them what happens after they are pressed.

So don't say “click“ save to save ”because they might not know what“ save ”means. Say“ click “save” and your information will be saved later ”or“ if you click “Cancel all information. which you put "will be lost".

0


source


Keep it short!

Users won't read the paragraph that explains all the ins and outs of a button. You will receive only 2 max sentences for the user to read. How many people actually read this second paragraph?

0


source







All Articles