| Guidelines | |||||||
|
Basics Menus Toolbar Statusbar Content Area Dialogs
Mouse Drag and Drop printable version (ps)/(pdf) |
| Links |
|
Icon Style Guide |
 |
Dialogs
Simple Dialogs
Simple Dialogs always ask the user a single simple question. Simple Dialogs can be categorized as follows:
The first two categories ask their questions implicitly: "Have you read this message?" and "Do you want me to stop?".
A notification is a message from the application to the user. The user is not offered any choices. When the user has read the message, he/she can click a button labeled "OK" which will make the the dialog disappear. Pressing Return or Escape has the same effect.
A notification dialog is modal to the application. The user should take note of the message before continuing.
Applications usually report error conditions with a notification dialog.
|
KMessageBox::information() should be used for notifications of
an informational kind. |
It is extremely irritating to users to have notification dialogs popping up for expected events. Messages like "Printing completed" or "Mail sent" should be avoided. Instead, the application might show these messages in the statusbar. A notification dialog should be used only when users need to be notified of an event which they did not specifically ask for, or were not necessarily expecting.
Applications should not bother the user with unnecessary notifications. If you are not sure whether a possibly often-recurring notification is useful or simply an unnecessary burden, you can offer the user an option by means of a checkbox not to show the message again.
|
When the user hides the menubar, it is useful to inform him/her how to get it back. Experienced users may get annoyed by this notification, so there should be a checkbox to allow them to disable the notification in the future. For the sake of completeness, you should provide users the option in Preferences to "Show all messages again". 
|
Progress dialogs are used to show the progress of an ongoing activity. The user should be offered an option to abort the activity.
If the application can do anything useful during the activity the progress dialog should be modeless.
The button on the progress dialog that aborts the activity should be labeled "Cancel" when aborting the activity is the same as never having started the activity at all. The button should be labeled "Stop" when aborting the activity leads to a partial result of some sort.
|
The following progress dialog might be shown when opening a file across the Internet. It has a "Cancel" button because when it is pressed, the file is not opened at all.
The following progress dialog might be shown when a document is printed. It has a "Stop" button: when it is pressed, no further pages will be sent to the printer, but some of the pages might already have been printed.
|
The Yes-No question is just that, a question which asks for a Yes or No answer. As such it has a "Yes" button and a "No" button.
|
An example of a Yes-No question.
|
Although Yes-No questions have an appealing simplicity, they do have a downside. While the implications of the Yes answer are usually very clear, the implications of the No answer are often not clear at all. The question "Do you want to save your changes?" serves as a good example. Pressing "Yes" will get the changes saved, but what happens when the user presses the "No" button? Rephrasing the question as an Either-Or question will help make this more clear: "Do you want to save or discard your changes?". Now there can be buttons labeled "Save" and "Discard", and the consequences of both are equally clear.
Yes-No and Either-Or dialogs have another disadvantage: sometimes a user might not know the correct answer to the question, or might find both options equally unattractive. In this case, it is helpful to add a third button labeled "Cancel", which will abort the whole sequence of events.
The Cancel option should always be labeled "Cancel". Even if the user does not know what the dialog is about, he or she knows that pressing "Cancel" is always a safe choice.
|
When an application is being terminated and it has a document open which has been changed, the application asks whether it should save the changes or not. Since the user might find both saving or discarding the changes unacceptable, he/she can choose Cancel to abort the termination of the application.
|
Confirmation request dialogs ask the user to approve the action that is about to take place. The user has two choices: approve the operation by pressing the "OK" button or abort the operation by selecting the "Cancel" button.
Instead of labeling the OK option "OK", it is better to provide options that are named in a way that describes what will happen when they are pressed. This is known as voice-active prompt. Only if no clear verb can be found that describes the action should the option be labeled "OK".
Again, the Cancel option should always be labeled "Cancel". Even if the user does not know what the dialog is about, he/she knows that pressing "Cancel" is always a safe choice.
|
A dialog that asks for confirmation to delete a file offers a "Delete" button and a "Cancel button. If an "OK" option had been offered, there would be a bigger chance of the user's selecting this option without actually understanding the consequences.
|
Previous