Difference between revisions of "Projects/Usability/HIG/Dialogs"

< Projects‎ | Usability‎ | HIG
Jump to: navigation, search
(Positioning: Added screenshots.)
(Appearance)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
__NOTOC__
 +
 +
== Purpose ==
 +
A ''dialog'' is a secondary window that allows users to perform a command, asks users a question, or provides users with information or progress feedback.
 +
 +
Dialogs can be modal and require users to complete and close before continuing with the owner window, or modeless, i.e. users can switch between dialogs and parent window.
 
== Guidelines ==
 
== Guidelines ==
=== Positioning ===
+
 
 +
=== Is this the right control? ===
 +
* Use a dialog to structure the work flow. For instance, the functions Open, Save, Advanced Search need user input or confirmation. In particular, dialogs are expected by users for configuration.
 +
* Do not use dialogs if the flow must not get interrupted. In this case prefer inline controls.
 +
* Consider to use alternative ways for communication with users like [[Projects/Usability/HIG/Tooltip| tool-tip]] or [[Projects/Usability/HIG/MessageWidget| message panel]].
 +
* Always use standard dialogs, if available.
 +
 
 +
=== Behavior ===
 +
* Do not apply dialog boxes that require the use of a scroll bar.
 +
* Do not include a menu bar or status bar in dialogs.
 +
* Do not display more than one owned choice dialog at a time from an owner choice dialog.
 
* Always keep dialogs on top of their parent.
 
* Always keep dialogs on top of their parent.
 
::{|
 
::{|
 
| [[Image:DialogPositionParentBad.png]]
 
| [[Image:DialogPositionParentBad.png]]
| <font color="red">'''Bad'''</font>
+
| {{BadUsability}}
 
|-
 
|-
 
| [[Image:DialogsPositioningParentGood.png]]
 
| [[Image:DialogsPositioningParentGood.png]]
| <font color="green">'''Good'''</font>
+
| {{GoodUsability}}
 
|}
 
|}
::This is usually taken care of by the window manager. But in composed applications, focus problems may occur. Check carefully in this case.
+
::
* If reference in the parent window is required, make sure your dialog does not cover relevant parts. <br><small>For example a find dialog should neither be centered, nor cover a search result.</small>
+
* Set input focus on confirmation button by default. But set focus on disruptive button (Cancel, Don't apply or the like) if the dialog comprises of critical confirmation.
 
+
* Avoid to nest dialogs, especially in case of modal dialogs.
=== Interaction ===
+
* Avoid dialogs that contain only one or two options. If possible, use direct selection or inline-editing instead.  
* Set input focus on confirmation button.
+
* Do not use dialogs to display non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button). Consider to use [[Projects/Usability/HIG/Tooltip| tool-tips]] or a [[Projects/Usability/HIG/MessageWidget|message panel]].
 
+
=== Reduce the dialog flood ===
+
* Do not nest dialogs more than two levels deep. <br><small>For example "Configuration dialog > Advanced dialog" is ok, "Configuration dialog > Advanced dialog > Further settings dialog" is too deep.</small>
+
* Avoid dialogs that contain only one or two options. If possible, use [[Design_and_Layout:Interaction:Input#Inline Editing|inline-editing]] instead.  
+
* Do not use dialogs to display non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button). Use [[Guidelines:Info Panel|info panels]] instead.
+
 
+
=== Modal dialogs ===
+
 
* Use modal dialogs only if allowing interaction with other parts of the application while the window is opened could cause data loss or some other serious problem.  
 
* Use modal dialogs only if allowing interaction with other parts of the application while the window is opened could cause data loss or some other serious problem.  
 
* Provide a clear way of leaving the modal dialog, such as a Cancel button.
 
* Provide a clear way of leaving the modal dialog, such as a Cancel button.
 +
* When the dialog is used to inform about an unexpected condition that needs interaction, follow the guidelines for [[Projects/Usability/HIG/Messages|message dialogs]].
  
=== Dialog Layout ===
+
=== Appearance ===
 
+
* Use tabbed dialogs when you have a limited number of tabs (max. 6). If you cannot see all the tabs without scrolling or splitting them into multiple rows, you are probably using too many and should use a paged dialog instead.
* Dialogs should not be bigger than 800x600 pixels and should always be resizable
+
::{|
 +
| [[Image:Tabs_bad.png]]
 +
| {{BadUsability}}
 +
|-
 +
| [[Image:Tabs_good.png]]
 +
| {{GoodUsability}}
 +
|}
 +
::
 +
* Always use paged dialogs for configuration dialogs - assuming that there is more than one section of options to be configured. For other dialogs, use paged dialogs if there are too many tabs to put them into a tabbed dialog.
 +
::{|
 +
| [[Image:Paged_dialog.png]]
 +
| {{GoodUsability}}
 +
|}
 +
::
 +
* Dialogs should not be bigger than two thirds of the screen size and should always be resizable. Take care about high resolution displays (i.e. QXGA and more).
 +
* Save and restore user adjustments of dialog size.
 
* Make sure there is at least one third white space, do not overload the panel.
 
* Make sure there is at least one third white space, do not overload the panel.
* The reading direction in dialogs is left to right, top to bottom.  
+
* Consider the common reading direction from left to right and top to bottom.
* Dialogs are grouped in meaningful sections. The actions are grouped along their context of use, not along technical relations.
+
* Dialogs are grouped in meaningful sections, for instance by [[Projects/Usability/HIG/GroupBox|group boxes]]. The actions are grouped along their context of use, not along technical relations.
* Each section has a title.
+
* Provide a title to each section.
* Labels are right-aligned, input widgets are left aligned.
+
* Follow the guidelines for [[Projects/Usability/HIG/Alignment| alignment]].
* Provide one or two major vertical axis in your dialog that guide the user's attention.<br>The vertical line where the right aligned labels and the left aligned input widgets meet is one such example.
+
* Widgets which are subordinate to another widget are indented. If their enabled state depends on the parent widget, create an appropriate slot.
+
 
+
Otherwise, follow the guidelines described in [[Projects/Usability/HIG/Form_Label_Alignment|Form: Label Alignment]]  
+
  
 
== Implementation ==
 
== Implementation ==
 +
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKPageDialog.html KPageDialog].
 +
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKConfigDialog.html KConfigDialog]
 
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKDialog.html KDialog]
 
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKDialog.html KDialog]
 
== See Also ==
 
* [[Projects/Usability/HIG/Tabs_Pages|Tabs and Pages in Dialogs]]
 
* [[Projects/Usability/HIG/Form_Label_Alignment|Form: Label Alignment]]
 

Latest revision as of 15:18, 4 October 2013


[edit] Purpose

A dialog is a secondary window that allows users to perform a command, asks users a question, or provides users with information or progress feedback.

Dialogs can be modal and require users to complete and close before continuing with the owner window, or modeless, i.e. users can switch between dialogs and parent window.

[edit] Guidelines

[edit] Is this the right control?

  • Use a dialog to structure the work flow. For instance, the functions Open, Save, Advanced Search need user input or confirmation. In particular, dialogs are expected by users for configuration.
  • Do not use dialogs if the flow must not get interrupted. In this case prefer inline controls.
  • Consider to use alternative ways for communication with users like tool-tip or message panel.
  • Always use standard dialogs, if available.

[edit] Behavior

  • Do not apply dialog boxes that require the use of a scroll bar.
  • Do not include a menu bar or status bar in dialogs.
  • Do not display more than one owned choice dialog at a time from an owner choice dialog.
  • Always keep dialogs on top of their parent.
DialogPositionParentBad.png Bad
DialogsPositioningParentGood.png Good
  • Set input focus on confirmation button by default. But set focus on disruptive button (Cancel, Don't apply or the like) if the dialog comprises of critical confirmation.
  • Avoid to nest dialogs, especially in case of modal dialogs.
  • Avoid dialogs that contain only one or two options. If possible, use direct selection or inline-editing instead.
  • Do not use dialogs to display non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button). Consider to use tool-tips or a message panel.
  • Use modal dialogs only if allowing interaction with other parts of the application while the window is opened could cause data loss or some other serious problem.
  • Provide a clear way of leaving the modal dialog, such as a Cancel button.
  • When the dialog is used to inform about an unexpected condition that needs interaction, follow the guidelines for message dialogs.

[edit] Appearance

  • Use tabbed dialogs when you have a limited number of tabs (max. 6). If you cannot see all the tabs without scrolling or splitting them into multiple rows, you are probably using too many and should use a paged dialog instead.
Tabs bad.png Bad
Tabs good.png Good
  • Always use paged dialogs for configuration dialogs - assuming that there is more than one section of options to be configured. For other dialogs, use paged dialogs if there are too many tabs to put them into a tabbed dialog.
Paged dialog.png Good
  • Dialogs should not be bigger than two thirds of the screen size and should always be resizable. Take care about high resolution displays (i.e. QXGA and more).
  • Save and restore user adjustments of dialog size.
  • Make sure there is at least one third white space, do not overload the panel.
  • Consider the common reading direction from left to right and top to bottom.
  • Dialogs are grouped in meaningful sections, for instance by group boxes. The actions are grouped along their context of use, not along technical relations.
  • Provide a title to each section.
  • Follow the guidelines for alignment.

[edit] Implementation


This page was last modified on 4 October 2013, at 15:18. This page has been accessed 5,866 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal