Dialogs

A dialog is a way to request input or deliver a message to your users.

Usage

Use a dialog to ask for input or to deliver an important information.  Use the pattern described in this Standard for an input or information-only dialog.  If delivering a warning or error message, see Messages and Confirmations.

Guidelines

Dialog Title Bar

  • Use title-style capitalization.
  • If the task in the dialog relates to a first-class object, present the title in the form of <object icon> <object name> - <topic>.


     
  • Use specific language.

    Original:  Perform Operation?
    Rewrite:  Remove Virtual Machine
     
  • Provide the Minimize icon  () to allow users to minimize the dialog to the Work in Progress portlet.  See Minimizing and Restoring for details. 
  • Provide a Help icon () when users need more information about the data requested in the dialog. See Contextual Help for details.
  • Don't include a Close icon ().

Content Area

  • If the data is simple enough, show all information within the dialog pane. 
  • For larger amounts of data, such as the display of object settings or an advanced configuration, use a stack view to separate the information into logical, related groups and allow users to progressively disclose the data.  If you need to further divide the data, use a multipage dialog.
  • Don't mark required or mandatory fields (fields that must have a valid value before the user can proceed). Instead, use validation to highlight missing or invalid values.
  • Optionally, if a field is not required (can be empty and the user is still allowed to proceed), label the field "Optional."
  • Keep vertical scrolling of the content area to a minimum and avoid horizontal scrolling.
  • Right-align the buttons in the footer.
  • Use these buttons:
    • OK and Cancel for a dialog that requests user input
    • OK for an information-only dialog
  • Always enable the OK button.  An enabled button is usable and clickable.
  • Optionally, assign a default button so a safe action is initiated by pressing the Enter key.
  • Never open another dialog from a button in the footer.  
  • Never allow vertical or horizontal scrolling of the footer.

Multipage Dialog

  • For larger amounts of data, or for related workflows that the user can complete in any order, consider using multiple pages. A table of contents (TOC) is the preferred method for navigating between the pages.  An alternative is to use tabs.


     
  • For the TOC:
    • Enable navigation to any item in the TOC at any time.
    • Don't require the user to visit all pages.
    • Use a noun phrase for each TOC item.
    • Don't number the items in the TOC.
    • Don't include a checkmark next to the TOC item when the user completes the page.
    • Avoid vertical scrolling and never allow horizontal scrolling.

Minimizing and Restoring 

  • Enable users to minimize a dialog if they might be interrupted with another, more important task or need to retrieve information elsewhere in the application to complete the dialog. The dialog disappears and is visible only by its title in the Work in Progress (WIP) portlet.
  • Don't minimize a dialog that opens on top of another dialog or a dialog that has a small set of controls.
  • When opening the dialog from the WIP, restore all pages to the state that they were in when the user minimized the dialog. Then, revalidate the dialog per the Validation standard.
  • Ensure that the state of a minimized dialog persists across sessions.

Visual Specification

The recommended maximum size of a dialog is 960 x 560 pixels. The content area for a single page dialog at the recommended maximum size is 960 x 486 pixels.  

The recommended content area for a multipage dialog is 740 x 486 pixels; the TOC takes up 220 pixels.


All dialogs in the vSphere Web Client are modal.

Related Topics

Average (0Votes)