Design and Layout:Layout:Dialogs

From KDE-HIG_Wiki

General

Guidelines

Reduce the dialog flood

• Do not nest dialogs more than two levels deep.
  For example "Configuration dialog > Advanced dialog" is ok, "Configuration dialog > Advanced dialog > Further settings dialog" is too deep.
• Avoid dialogs that contain only one or two options. If possible, use 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 info panels instead.

Position of dialogs

• Always keep dialogs on top of their parent.
  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.
  For example a find dialog should neither be centered, nor cover a search result.

Interaction

• Set input focus on confirmation button.

Dialog Layout

Guidelines

• Design dialogs not to be bigger than 800x600 Pixels.
• 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.
  In a row, related options may be positioned next to each other, like "Access" and "Show time as" like in the example screenshot.
• Dialogs are grouped in meaningful sections. The actions are grouped along their context of use, not along technical relations.
• Each section has a title.
• Labels are right-aligned, input widgets are left aligned.
• Provide one or two major vertical axis in your dialog that guide the user's attention.
  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.

Implementation Suggestions

Always use Qt Designer to create the dialog layout. Otherwise, there are no special rules to consider - create the dialogs as in KDE3, the dialog class will convert them to the new layout.

Don't forget to create label-buddy relations so accelerator keys can be assigned!

Modality

A non-modal dialog does not restrict the user's interaction with other open windows on the desktop in any way. Using non-modal dialogs gives the user maximum flexibility to perform tasks within your application in any order and by whichever means they choose.

A parent modal dialog prevents the user from interacting the direct parent window, but not with other parts of the application.

An application modal dialog, while it is open, prevents the user from interacting with other windows in the same application.

Guidelines

When to use modal dialogs

• Use modal dialogs only if allowing interaction with other parts of the application while the window is open could cause data loss or some other serious problem.
• Provide a clear way of leaving the modal dialog, such as a Cancel button in an alert.

When not to use modal dialogs

• Make sure not to provide modal dialogs
  • when the user needs to access information behind the dialog, e.g. for copy and paste or for deciding which action to take in the dialog.
  • to display information or non-critical error messages. Use info panels instead.
• Do not tie dialogs inherently to an object to avoid the need for modal dialogs. E.g. in a word processor, you might keep the fonts dialog open to format different parts of the text.
• Don't make the following types of dialogs modal:
  • Configuration dialogs. Sub-dialogs can be modal towards the configuration, however.
  • Properties dialogs.
  • Find and Replace dialogs.

See Also

Related To

Keywords