I'm confusing how to write good messages 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 meaningful messages?
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]
If this is a prompt, then I would use a question and answer style:
Save changes to this project?
[Yes] [No]
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.
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!"
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.
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.
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".
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?
Related
In PowerBuilder's IDE, the code autocomplete feature uses the clipboard to communicate the completed text to the code window. By doing so, it overrides whatever was stored on the clipboard before. So, if you had the winning numbers of the next lottary stored on your clipboard, and you used the autocomplete to turn m_goodfor into m_goodfornothing, you've just lost your only chance of ever getting rich, and you're left with nothing on your clipboard.
Features like that are the reason I hate software. It looks like it was implemented by some intern that noone was looking after. However, there's also a chance I got all worked up for nothing, and making such use of the clipboard is absolutely legit. So, can an app use the clipboard for its own purposes? Who is considered the owner of the clipboard?
(Bonus votes to whoever puts himself in place of the feature's programmer, and provides some reasoning for this being done on purpose, assuming the users would actually benefite from it)
You are probably right on the intern reasoning. There is absolutely no reason why an application would use the clipboard to communicate information other than pure laziness. Even between processes, there are other, better ways of communicating information.
Other then letting the user paste information in another application, there is no reason to use the clipboard.
The programmer did it because it was easy, and put his needs above those of the end user. There are many programs that do this, particularly add-ins to outlook, VB, etc., which copy/paste their buttons onto the toolbar. Any user that runs a clipboard extender (like my own ClipMate) will absolutely hate this behavior (and you'll be "busted" right away).
Here is my favorite quote on the subject:
“Programs should not transfer data into our out of the clipboard without an explicit instruction from the user.”
— Charles Petzold, Programming Windows 3.1, Microsoft Press, 1992
An app should never change anything on the clipboard without the user initiating that action. My .02 anyway.
Bonus votes to whoever puts himself in place of the feature's programmer, and provides some reasoning for this being done on purpose
Using clipboard for application communication
They are always a better way to do it. The programmer might have done it this way because it was faster to implement OR because he really wanted to have this value in the clipboard after the action. At least, if he didn't wanted to have it in the clipboard he could have get the value from the clipboard, store its value then replace the old content of the clipboard inside the clipboard and everything would have be more "transparent" ans less frustrating for the end-user.
I have built a piece of functionality into an App that uses the clipboard. Business was requesting a way for users to seamlessly capture a screen shot and upload it.
I worked with the business to develop it and what we came up with was a user simply hit the print screen key and clicked "upload" in my app.
The Java Applet running in the background pulled the image off the clipboard and displayed a formatted preview to the user, The user then added in a file name and description and clicked save.
Using the clipboard this way saved the user the time of having to capture the screen shot save it somewhere then find it through an upload interface. Even if we did go that route by the user hitting print screen to capture the image in the first place they are already overwriting whatever was on the clipboard in the first place.
Using the clipboard isn't all bad but I certainly agree using it in an IDE is a def no no.
We're using the file picker dialog to allow users to add documents into our application. The word 'Open' doesn't make a lot of sense in this case.
Thanks.
I would browse the code found here, which shows how someone extended the OpenFileDialog. Admittedly, this is overkill for you. But I think there is code within to change the button label.
Not really no.
Given the standardization of this dialog it's extremely likely that your users will have used it many times in the past to "add" files to applications. The chances are they will be quite familiar with the implications of the word, changing it may be more confusing to them.
The standardness of the dialog is why it's called a "Common File Dialog". If you want to change it for your app, you'll have to write your own dialog.
Having said that, there are apps out there that can pull a form out of a DLL, modify it, and stick it back in. However, this is a per-machine hack and downright bad form.
I have a help file for my program and was asked to add a description of the menus in a toolbar as the user browses them. So I thought I could just use the beginning of the menu's description of the help but just cant find how to access the contents of it.
I saw WinHelp has a macro language, so I figured maybe through this, but I couldnt find any references on this around.
Anybody now some pointers or examples of hot to do this?
the winhelpcgi utility contains library code that can read .hlp files. The source is here: link
I haven't used it so I can't vouch for its usage.
First, your help system should have an Index on each topic that permits you to open help and have that topic appear (if not, then check out Help & Manual - it'll help you build more complete help files). However, this doesn't directly solve your problem since, as I understand it, you want this to pop up in a toolhelp Window.
Thus, you'll need to go under the surface and figure out how the Help system uses the key to pull the appropriate information. However, it is not a trivial undertaking (as far as I can tell) to directly access a specific, indexed chunk of text in a WinHelp file. You may find some information here that is of use. You might also want to browse the forums on the Help and Manual web site.
Here's a bigger question though: does it really make sense to pop up an entire help topic (even if short) when a user just hovers over a menu item or button? It doesn't to me and I spent years in a UI design group at Bell Labs. It is A) simply too much information and B) going to be visually distracting (and thus incredibly irritating) to experienced users. The accepted practice here is to pop up a toolhelp window with a very short (1-4 words) descriptor of the button ("Open" or "Open File").
If you want the help to be available for each menu item or button, I would suggest one of two alternatives.
First, consider having a "Help Cursor mode" where the cursor uses the help icon (an arrow with a question mark). The user accesses it via a Help button on the button bar. When in Help Cursor mode, a user click on any item will take them to the help topic for that item. I'm kind of lukewarm to this approach since it is modal but I've certainly seen it done.
Second, you might simply beef up your help system a bit. That is, create a topic in your Help system that features a screen shot of your application. On this screenshot, create hot spots for each menu item and/or button and permit the user to go to the appropriate topic by clicking on it. Done right, this gives the user a visual key to the topics they wish to learn about without interfering with the normal operation of your program.
Most importantly: before doing all of the work necessary to implement your current plan, be sure it is the right plan!
Modal dialogs are evil, but I keep reading "You should remove modal dialogs when possible"
When isn't it possible to remove modal dialogs? I mean, what are some truly modal tasks that force us to use evil modal dialogs?
The most common given example is the "Do you want to Save?" I think this is the problem of the concept of having the user hit Save instead of remembering that user input is sacred. If you just saved automatically with the ability to "undo" or have revisions, then you don't ever need ask the user if they want to save.
"Are you sure you want to delete?" Undelete
"Are you sure you want to quit?" Why would you ask that? Are you that vain?
Why do we ever need modal dialogs?
EDIT
Webs app don't count in my books, unless they write their own UI windowing system within the browser. Web apps don't have the same tools set as desktop apps.
EDIT 2
My question is slightly different than the one labeled as duplicate. I feel that there is no case that modal dialogs are the best solution. The referred question assumes there is such a case.
Duplicate of: When Is Modal UI acceptable?
Use Cases for Modal Dialogs
blocking the application flow until information required to continue is entered, as for example a password in a login process.
collecting application configuration options in a centralized dialog. In such cases, typically the changes are applied upon closing the dialog, and access to the application is disabled while the edits are being made.
warning that the effects of the current action are not reversible. This is a frequent interaction pattern for modal dialogs, but it is also criticised by usability experts as being ineffective for its intended use (protection against errors in destructive actions) and for which better alternatives exist.
(Source: Wikipedia)
When I use them
In instances where stopping them from doing something stupid is absolutely mandatory. My company has a web app where Users sometimes leave the page before finishing their work. We prompt them with a Modal (the standard onbeforeunload JavaScript function) if they haven't saved their work.
Otherwise, I don't use Modals if I can help it, I hate it when an app steals focus from what I'm doing.
Edit: We don't save their work automatically for them when they leave the page. We do at other times, but not when they leave the page, hence the Modal. I did write could that could go in and save their work when they left the page, but it wouldn't be a 'great' idea to implement it, especially if they accidentally deleted their work and didn't want it to automatically save.
The only thing more sacred than user input is any file I known about. You should never modify any file that an implementation detail unless I have told you to. Thus boxes like "do you want to save?" at exit are a must because I may want to not save.
Imagine an application which needs to open a dialog for some actions. Now imagine that these would be non-modal dialogs: while one dialog is open, you could change the selection or even worse - invoke a different command which itself opens another dialog. Now imagine the these dialogs would be modal: then you would have to close the dialog to proceed - you can't get in the state where the selection changes under a dialog or where two commands are waiting for input.
By and large, modal interfaces suck big rocks. On the other hand, I can't think of a better way to handle File Open..., or Print... and this, I think, is because
they are occasional actions, infrequent and momentous, and
they are atomic in nature; you either finish specifying all your print options and go through with it, or you cancel the whole show.
Let's put together a little style-guide. Suggest any use-cases in which a dialog is the preferred presentation and why it is preferred. Can the dialog be non-modal? If it is, how do you mark transactional boundaries, since Cancel ceases to have a clear meaning. Do you use an Apply button, for example?
IMO, modal interfaces should only be used when you HAVE to deal with whatever the dialog is doing or asking before the application can continue. Any other time, if you're using a dialog, it should be non-modal.
When doing non-modal windows, you might want to ensure they are unique: you don't really want two identical toolboxes (in a graphical program for example) or two identical preferences dialog (I saw this in a product), which can be confusing at best.
On the other hand, I appreciate when a Search/Replace dialog is non-modal: I can go back to the document and cancel last change, skip elsewhere, etc.; without losing the current settings.
Somehow, modal dialogs tell the user to "stop everything else and finish what you are doing", which has its uses, as pointed out in Stephen Wrighton's answer.
In my experience, there are very few things that should ever be modal in a UI. One of the best examples of this, and probably one very familiar to the users of the site, is Eclipse. Although it has some modal dialogs, and I'm speaking only of the core IDE here, they largely fall into three categories: File operations, preference dialogs and parameter dialogs.
Preference dialogs, while modal by tradition, need not be modal either. All you have to do is look at the Mac OS preference model, where configuration changes take place immediately, with modal behaviour introduced only in cases where the change might be disruptive to work in progress.
In short, here's what I would say is a good summary of what should be modal. Exceptions to this set should be well-justified by the usage.
Parameter entry dialogs (example: refactoring wizards. anti-example: find dialogs)
File operations
Confirmation of an action that will take immediate disruptive effect
How about a user login window, you cannot (or should not) use the rest of an application until you've logged in, assuming security is necessary.
I think the distinction is that if there is anything at all that a user might be able to do in the application while the dialog is shown, then it should not be modal. This includes copy/paste actions. Personally I would prefer it if file/open and print dialogs weren't modal either. I think modal dialogs are a sign of weak design, a necessary evil to get code out the door quickly.