UI Guidelines: Dialogs (2nd draft)

[colin z robertson <c z robertson ndirect co uk>]

Here's my 2nd attempt at the Dialogs section of the UI guidelines
document. It's still not perfect, but I'm rather busy at the moment
and you wouldn't see anything from me if I tried to be a
perfectionist.

It still doesn't have any diagrams or examples. I'll try to do them
when I get some time, but in the mean time if anyone else wants to
have a go at these things, please, go ahead.

Comments, as ever, much appreciated.

colin

---

    <sect1 id="dialogs">

      <title>Dialog boxes</title>
      
      <para>
        Dialog boxes are windows allowing the user to interact with an
        application in ways that supplement the main application window. They
        might typically be used to control the properties of an object, to
        request further information from the user or to notify the user of an
        event.
      </para>
      
      <para>
        Dialog boxes come in a number of different forms, suitable for different
        situations, and each with their own UI implications.
      </para>
      
      <sect2 id="dialogs-modal-and-modeless">
        
        <title>Modal and modeless dialog boxes</title>
        
        <para>
          All dialogs can be classified according to whether they are modal or
          modeless. Modal dialog boxes are those which prevent the user from
          interacting with any other part of the application while they are
          visible. They should be used only where it is necessary that the user
          doesn't make any changes to the state of the program before performing
          an action with the dialog or closing it.
        </para>
        
        <para>
          Modeless dialog boxes allow the user to continue to interact with the
          rest of the application while the dialog is visible. They are
          generally suitable for tasks such as changing the properties of an
          object or tool.
        </para>
        
        <para>
          In general, modeless dialogs are preferable to modal dialogs since
          they are less intrusive. Dialogs should only be made modal if there is
          a good reason to do so.
        </para>
        
      </sect2>

      <sect2 id="dialogs-informational">

        <title>Informational dialog boxes</title>

        <para>
          Informational dialog boxes are those which do not require the user
          to enter any data or make choices; they are merely for notification
          purposes.  These dialogs typically only need a label for the user to
          read and a button to close the dialog. They can be modal or modeless
          as appropriate.
        </para>

        <para>
          FIXME: add descriptions of the gnome_dialog convenience functions
          for informational dialogs (gnome-app-util).
        </para>
        
      </sect2>
      
      <sect2 id="dialogs-druids">
        
        <title>Druids</title>
        
        <para>
          Druids are dialog boxes which lead the user through a sequence of
          steps. They are frequently used for software installation and
          configuration, though they are by no means limited to this role.
        </para>
        
        <para>
          Druids are best suited to situations in which the user requires some
          sort of "hand-holding", due to the way in which they can combine
          documentation and control. Experienced users tend to find them
          inefficient and patronising.
        </para>
        
        <para>
          GNOME's druids are roughly equivalent to the "Wizards" frequently
          found in Microsoft Windows.
        </para>
        
      </sect2>
      
      <sect2 id="dialogs-layout">
        
        <title>Dialog box layout</title>
        
        <para>
          The top portion of a dialog box should contain the main area, the
          content of which is very much up to the developer. Nothing in this
          area should dismiss the dialog or perform actions which immediately
          affect objects external to the dialog.
        </para>
        
        <para>
          At the bottom of the dialog window should be a single row of buttons
          which pertain to the whole dialog. These can be divided into three
          main types: Action buttons, closing buttons and navigation buttons. In
          most cases a dialog should contain action buttons on the left of this
          row and one closing button on the right. In the case of druids the
          action buttons would be replaced with a pair of navigation buttons,
          and in the case of informational dialogs there would only be one
          dismiss button.
        </para>
        
        <para>
          Note that the left-right positioning of items described here only
          applies to Western systems. Localisation for other countries may
          reverse these positions.
        </para>
        
      </sect2>
      
      <sect2 id="dialogs-buttons">
      
        <title>Dialog box buttons</title>
        
        <para>
          Action buttons: Most dialogs will have buttons to perform some kind of
          action. These should be labelled with a verb to describe the action.
          (Labels such as "OK", "Yes" and "No" are discouraged since they are
          difficult for the user to quickly scan for the desired action.) The
          leftmost action button should be the default button, and so be
          activated by the Enter key.
        </para>
        
        <para>
          On modal dialogs in will generally be necessary for the action buttons
          to also close the dialog.
        </para>
    
        <para>
          Closing buttons: These vary depending on the type of dialog on which
          they appear. On modal dialogs the closing button should be labeled
          "Cancel" and should close the dialog and return the application the
          the state it was in before the dialog was shown.
        </para>
        
        <para>
          On modeless dialogs the closing button should be labeled "Close" and
          should close the dialog without making any further changes to the
          state of the application.
        </para>
        
        <para>
          The situation is slightly different again for informational dialogs.
          As always, the closing button should close the dialog, but the
          labelling of the button is a decision for the developer and is
          dependent upon the context in which it appears. As a rough guide,
          "Close" will generally be an appropriate label for dialogs appearing
          in response to a user's request for information, while "OK" will often
          be more appropriate for unrequested alerts.
        </para>
        
        <para>
          In all of these cases the closing button should be activated by the
          escape key. On purely informational dialogs where the dismiss button
          is the only button in the bottom row of the dialog, it should also be
          the default button and so be activated by the Enter key.
        </para>
        
        <para>
          Navigation buttons: If the dialog contains a sequence of
          steps (as in a wizard, for example), they should be navigable with
          buttons labelled "Previous" and "Next". These buttons should have the
          accelerators "p" and "n" respectively.
        </para>
        
        <para>
          FIXME: Does Gnome contain standard components for implementing these
          buttons? Apparently yes, with no accelerators, and including "Next"
          and "Prev".
        </para>

      </sect2>

    </sect1>

  _____________________________                            ____
  rtnl  http://rational.cjb.net     c z robertson ndirect co uk
  ak    http://kitching.cjb.net                    icq 13294163