<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title></title><style type="text/css">.felamimail-body-blockquote {margin: 5px 10px 0 3px;padding-left: 10px;border-left: 2px solid #000088;} </style></head><body>User Assistance: Disruptive messages<br>* Show a modal message dialog if the processing has been reached an unexpected condition that needs interaction. <br><br>http://techbase.kde.org/Projects/Usability/HIG/Messages<br><br>== Purpose ==<br>If the processing has been reached an unexpected condition that needs interaction, a disruptive message alerts the user of a problem. Not any disruptive message concerns a serious problem. Sometimes, the user is just notified that proceeding is dangerous. A typical example is the “Save changes before closing?” alert box that appears when a user tries to close a module with modified content. The adequate presentation method for disruptive information is a ''modal message dialog''.<br><br>A modal dialog is a secondary window that interrupts user's current activity and blocks interaction until user either simply acknowledge the information by clicking Ok or decides how to proceed (e.g. Yes/No). Effective error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. Users should either perform an action or change their behavior as the result of an error message. <br>Modal dialogs are error-prone. An alert dialog that appears unexpectedly or which is dismissed automatically (because the user has developed a habit) will not protect from the dangerous action.<br><br>== Examples ==<br><br>== Guidelines ==<br>* Avoid disruptive messages; workflow maintenance and, therefore, the prevention of errors should be the primary objective. <br>* Use modal dialogs only for critical or infrequent, one-off tasks that require completion before continuing. Don’t use modal error message dialogs at the normal work flow to inform or warn the user.<br>* Use [[Projects/Usability/HIG/MessageWidget|mesage panel]] for non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).<br>* Create specific, actionable, user-centered error messages (Figure 60). Users should either perform an action or change their behavior as the result of the message.<br>* Provide only a short error message and complement it by a Details button that provides more a detailed explanation in the same error dialog.<br>* If it makes sense for this kind of error, link from the error dialog to the corresponding page in the help system. Provide a Help button then.<br><br>=== Dialogs in general ===<br>* Don’t apply dialog boxes that require the use of a scroll bar.<br>* Don’t include a menu bar or status bar in dialogs.<br>* Don’t display more than one owned choice dialog at a time from an owner choice dialog. <br><br>=== Language ===<br>* Messages should be:<br>** Understandable: Phrase your messages clearly, in non-technical terms and avoid obscure error codes. <br>** Readable: User has to be able to read the message in his/her own pace, think about it, understand it. Adding countdown timers (visible or not) and forcing user to read and understand the message within a few seconds is not acceptable,<br>** Specific instead of general: If the message is reporting a problem concerning a specific object or application, use the object or application name when referring to it.<br>** Informative and constructive: Tell the user the reason for a problem and help on how to solve the problem.<br>** Polite, non-terrifying and non-blaming: Avoid wording that terrifies the user ("fatal", "illegal"), blames him for his behavior, and be polite.<br><br>=== Confirmation Button Labels ===<br>* When no further input is required:<br>** To close a warning or error message that does not require further user interaction, provide a Close button. Do not use an OK button. Users may get confused if they are asked to confirm an error.<br>* When further interaction is required:<br>** Use buttons which match the type of statement or question made in the warning or error message. For example, do no ask a Yes/No question but then provide OK/Cancel buttons.<br>* When the user must choose between two actions to continue:<br>** Use descriptive button labels instead of standard Yes/No or OK/Cancel buttons. For example, if the user must choose to continue or stop an action, provide the buttons "Continue" and "Cancel".<br><br>== Implementation ==<br>* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKMessageBox.html KMessageBox]<br><br><br></body></html>