















        Chapter 6.  AApppplliiccaattiioonn DDeessiiggnn PPrriinncciipplleess







             This chapter is directed at application designers,
             rather than the people who write the algorithms of an
             application, although they are often one in the same.
             Application designers are the people who design the
             interface between the application algorithms and the
             user.  In designing user interfaces, an application
             designer chooses the proper controls or groups of
             controls, or components, to pass data between the base
             application and the user, lays out those components
             naturally, and ensures that user interaction with the
             components and the layout are easy to use.

             This chapter describes the three elements of
             application user interface design, as well as the
             principles for designing new user interface components.
             The four major sections of this chapter are as follows:

                +o Choosing components

                +o Layout

                +o Interaction

                +o Component design












        August 26, 1994                                          6-1







        OSF/Motif Style Guide


        6.1  CChhoooossiinngg CCoommppoonneennttss


             The user interface of an application is made up of
             components that perform two simple functions:
             presenting the application information to the user, and
             allowing the user to enter data for the application.
             Components can be divided into six types: basic
             controls, field controls, basic groups, layout groups,
             framing groups, and DialogBox groups.  The groups are
             containers for controls and groups of controls.  Groups
             can be nested.

             The component types that should be available in a user
             interface toolkit are described in the following lists.
             The details of these components are described in the
             reference section in Chapter 9 of this guide.  The
             correspondence of these components to widgets available
             in the OSF/Motif toolkit is described in Appendix A.

                +o BBaassiicc CCoonnttrroollss

                  Separator        Draws a separating line within
                                   windows, between Menu items, and
                                   between Panes of a PanedWindow.
                                   A Separator does not allow
                                   application interaction.

                  Label            Displays static text and images.
                                   A Label presents application
                                   information to the user.

                  PushButton       A button used to activate an
                                   operation.  A PushButton contains
                                   a Label that indicates the
                                   operation of the button.  The
                                   Label can contain text or an
                                   image.

                  CascadeButton    A button used to display a
                                   Pulldown Menu.  A CascadeButton
                                   contains a Label that indicates
                                   the Menu to be displayed.
                                   CascadeButtons can also contain
                                   an arrow graphic after the Label
                                   to distinguish it from
                                   PushButtons and to indicate the
                                   direction of the cascading Menu.







        6-2                                          August 26, 1994







                                       Application Design Principles


                  OptionButton     A button used to display an
                                   Option Menu.  An Option Menu
                                   allows for a one-of-many
                                   selection.  An OptionButton
                                   contains a Label that indicates
                                   the current state of the Option
                                   Menu and a bar graphic to
                                   distinguish it from a PushButton.

                  ToggleButton     A button with two states: on and
                                   off.  A ToggleButton contains a
                                   Label that indicates the active
                                   state.  Normally, preceding the
                                   Label is a graphic indicator of
                                   the state of the ToggleButton.

                  CheckButton      A ToggleButton in a group of
                                   ToggleButtons where any number of
                                   the ToggleButtons can be on at a
                                   time.  The graphic indicator for
                                   a CheckButton is usually a filled
                                   square to indicate the on state
                                   or an empty square to indicate
                                   the off state.  On color systems,
                                   the filled color can be distinct
                                   from general application colors
                                   to visually distinguish the on
                                   state.

                  RadioButton      A ToggleButton in a group of
                                   ToggleButtons where only one of
                                   the ToggleButtons can be on at a
                                   time.  The graphic indicator for
                                   a RadioButton is usually a filled
                                   diamond or circle to indicate the
                                   on state or an empty diamond or
                                   circle to indicate the off state.
                                   On color systems, the filled
                                   color can be distinct from
                                   general application colors to
                                   visually distinguish the on
                                   state.

                  TearOffButton    A button used for tearing off a
                                   Menu to create a dialog
                                   representation of the Menu
                                   contents.  A TearOffButton tears
                                   off a Menu in place when
                                   activated, or is dragged to tear
                                   off and move in one action.  A
                                   TearOffButton usually contains a




        August 26, 1994                                          6-3







        OSF/Motif Style Guide


                                   dashed line graphic representing
                                   perforations.

                +o FFiieelldd CCoonnttrroollss

                  Sash             Used to set the boundary between
                                   two components.  A Sash is
                                   usually a small square on the
                                   boundary between two components.
                                   The separated components are
                                   called Panes, and a group of
                                   Panes, Separators, and Sashes is
                                   called a PanedWindow.

                  Scale            Used to set or display a value in
                                   a range.  A Scale is usually
                                   composed of a slider, moving
                                   within an element that indicates
                                   the size of the range, and a
                                   Label that indicates the current
                                   value.  The position of the
                                   slider indicates the value
                                   relative to the range.  The
                                   slider is moved directly by using
                                   the mouse pointer or by using the
                                   arrow keys.  A Scale can also
                                   have buttons with arrow graphics
                                   for moving the slider with the
                                   mouse.

                  ScrollBar        Used to scroll the visible area
                                   of a component.  A ScrollBar is
                                   usually composed of a slider,
                                   moving within an element that
                                   indicates the full size of the
                                   component, and buttons with arrow
                                   graphics for moving the slider
                                   with the mouse.  The slider
                                   indicates the relative position
                                   and size of the visible area of
                                   the component.  The slider is
                                   moved directly by using the mouse
                                   pointer or by using the arrow
                                   keys.

                  List             Used for selecting elements from
                                   a list of elements.  A List can
                                   allow multiple items to be
                                   selected or can be constrained to
                                   only allow one item to be
                                   selected at a time.  A List is




        6-4                                          August 26, 1994







                                       Application Design Principles


                                   usually composed of a vertical
                                   list of items.  A List can also
                                   have both horizontal and vertical
                                   ScrollBars for scrolling the
                                   visible portion of the list of
                                   items.

                  Text             Used for displaying, entering,
                                   and modifying text.  There are
                                   single line and multiple line
                                   variants.  Multiline Text can
                                   have both horizontal and vertical
                                   ScrollBars for scrolling the
                                   visible portion of the text area.

                  Canvas           Used for displaying, entering,
                                   and modifying graphics.  A Canvas
                                   can have both horizontal and
                                   vertical ScrollBars for scrolling
                                   the visible portion of the
                                   drawing area.

                +o BBaassiicc GGrroouuppss

                  Panel            Organizes a collection of
                                   components in a horizontal,
                                   vertical, or 2-dimensional
                                   layout.  A Panel is usually
                                   composed of just one type of
                                   button.

                  Menu             Organizes a collection of
                                   buttons, Labels, and Separators
                                   in a horizontal, vertical, or 2-
                                   dimensional layout within a
                                   separate Menu window.  There are
                                   three types of Menus: Pulldown,
                                   Popup, and Option.  A Menu is
                                   only available while it is pulled
                                   down or popped up.

                  MenuBar          Organizes a collections of
                                   CascadeButtons in a horizontal
                                   layout at the top of a
                                   MainWindow.

                +o LLaayyoouutt GGrroouuppss

                  Composition      Organizes a collection of
                                   components in an arbitrary
                                   layout.




        August 26, 1994                                          6-5







        OSF/Motif Style Guide


                  PanedWindow      A linear grouping of components,
                                   Separators, and Sashes.  Sashes
                                   are used to set the boundary
                                   between two components.  The
                                   separated components are called
                                   Panes and can contain any
                                   components.

                +o FFrraammiinngg GGrroouuppss

                  Frame            Draws framing decorations around
                                   a component.

                  ScrolledWindow   Frames a component and adds
                                   ScrollBars for scrolling the
                                   visible area of the component.

                  MainWindow       Organizes the contents of a
                                   primary window.  A MainWindow
                                   frames the client area and can
                                   optionally include ScrollBars, a
                                   MenuBar, a command area, and a
                                   message area.

                +o DDiiaallooggBBooxx GGrroouuppss

                  A DialogBox group can either be nested within
                  another group or organizes the contents of a
                  secondary window.  Although a DialogBox can
                  contain any component, a simple DialogBox is
                  composed of a Label and a Panel of PushButtons for
                  supplying a response to the DialogBox.  The
                  OSF/Motif toolkit provides a number of ready-
                  designed DialogBoxes for common uses:
                  CommandDialog, FileSelectionDialog, MessageDialog,
                  PromptDialog, and SelectionDialog.  Several types
                  of MessageDialog are available: ErrorDialog,
                  InformationDialog, QuestionDialog, WorkingDialog,
                  and WarningDialog.



        6.1.1  GGuuiiddeelliinneess ffoorr CChhoooossiinngg aa MMaaiinn CCoommppoonneenntt GGrroouupp


             At the highest level, components are organized into
             MainWindows, Menus, and DialogBoxes.  Correctly
             deciding which component group to use for which parts
             of an application is one of the most important tasks of
             an application designer.





        6-6                                          August 26, 1994







                                       Application Design Principles


             Every application must contain at least one MainWindow.  *
             The MainWindow can contain a MenuBar, ScrollBars, a
             command area, a message area, and the client area.  The
             client area of the MainWindow contains the framework of
             an application.  The client area should contain all the
             components needed to perform the primary actions of the
             applications.  For example, in a text editor
             application, the MainWindow usually contains a text
             editing area; in a graphics editor application, the
             MainWindow usually contains a graphics editing area and
             the components for changing drawing functions.
             Components that are used constantly throughout the
             application should be contained in the MainWindow's
             client area.  Components that are used intermittently
             or infrequently should be placed in Menus or
             DialogBoxes.

             The advantages of Menus are that they are readily
             available, quickly accessed and dismissed, and easy to
             browse through.  The most commonly used Menus should be
             placed in the MenuBar in the MainWindow to increase
             these advantages.  Because Menus are readily available,
             and quickly accessed and dismissed, they should be used
             for components that are frequently used.  The time
             delays of bringing up a DialogBox for frequently used
             components can greatly reduce user productivity.
             Because Menus are easy to browse through, they should
             also be used for components that are commonly accessed
             by most users.

             The advantages of Menus also cause some disadvantages.
             A Menu is a very short-lived component group.  It is
             displayed only while the user makes a selection.  Once
             the user makes a selection, the Menu disappears.  So a
             Menu is not well-suited for making several selections
             at once.

             Adding a TearOffButton to a Menu can allow that Menu to
             remain available even after a user selection.  By
             activating a TearOffButton, the user changes the
             current Menu into a simple DialogBox with the same
             contents as the Menu.  A Menu with a TearOffButton
             allows the user to make multiple selections because the
             user can cause it to stay posted after a selection.  A
             TearOffButton is useful when it is unclear whether you
             should include a set of buttons in a Menu or DialogBox.

             Menus, other than TearOff Menus,  are also modal; that
             is, while a Menu is posted, the user cannot interact
             with other elements of the application.  Because of
             this, unless a Menu can be torn off, it should not be




        August 26, 1994                                          6-7







        OSF/Motif Style Guide


             used for components that the user may want to have
             available while interacting with other elements of the
             application.

             The other disadvantage of Menus is that they can only
             contain buttons and Labels.  Menus should be used for
             performing simple actions and setting values, but they
             are not suitable for more complicated functions like
             text entry.

             DialogBoxes are used for two general purposes: to
             present information to the user and to take user input.
             Applications should use DialogBoxes to present
             transient information to the user, like warnings,
             cautions, or conformations to actions.  DialogBoxes
             that present information to the user are called Message
             DialogBoxes.  Message DialogBoxes are often placed on
             the screen by applications without a request from the
             user.  Because Message DialogBoxes can disrupt a user's
             work, applications should present constantly updated
             information in the client area of the MainWindow.
             Also, applications can present minor cautions,
             incidental notes, and simple help in the message area
             of the MainWindow.

             The advantages of using DialogBoxes to take user input
             are that they are long-lived and can contain any
             components.  Because they are long-lived, they can be
             used to perform more than one action at a time and can
             remain available while the user interacts with other
             parts of the application.  Applications should use
             user-input DialogBoxes like small applications.
             DialogBoxes should be used to perform tasks ancillary
             to the application, where the user can take more than
             one action before dismissing the DialogBox.
             Applications should also use DialogBoxes where the task
             requires more complicated interaction than is available
             in a Menu, like file selection.

















        6-8                                          August 26, 1994







                                       Application Design Principles


             Table 6-1 summarizes the suggested uses for
             MainWindows, Menus, and DialogBoxes.

                     TTAABBLLEE 66--11..  Suggested Window Types

                                            UUssee TThhiiss MMaaiinn CCoommppoonneenntt GGrroouupp
                                           ______________________________
        FFoorr TThheessee CCaasseess                     MMaaiinnWWiinnddooww   MMeennuu   DDiiaallooggBBooxx
        _________________________________________________________________
        Primary application actions             X         -         -
        Ancillary application actions           -         -         X
        Components used intermittently          -         X         -
        Components used frequently              X         X         -
        Components used seldomly                -         -         X
        Components accessed by most users       -         X         -
        Simple actions                          X         X         -
        Complex actions                         X         -         X
        Presenting transient information        -         -         X
        Presenting updating information         X         -         -
        Presenting minor information            X         -         -



        6.1.2  GGuuiiddeelliinneess ffoorr CChhoooossiinngg IInntteerraaccttiivvee MMeetthhooddss


             Choosing the correct components for a task is usually
             simple.  In most cases, a task seems to naturally
             belong to a component; for instance, scrolling a region
             with a ScrollBar or choosing a value from a range with
             a Scale.  Each component's general purpose is described
             in Section 6.1, as well as in the reference section in
             Chapter 9.  In some cases, though, it is difficult to
             decide between two controls or groups of controls that
             could perform the same task.  The following subsections
             give some guidelines for choosing among some common
             similar components:

                +o Choosing a single-choice component

                +o Choosing a multiple-choice component

                +o Choosing among Menus and Panels

                +o Choosing between Text or Canvas, and a Label










        August 26, 1994                                          6-9







        OSF/Motif Style Guide


        6.1.2.1  CChhoooossiinngg aa SSiinnggllee--CChhooiiccee CCoommppoonneenntt


             A single-choice component allows the user to select a
             single item from a group of items.  Applications should
             use a single-choice component to limit the user to one
             choice; for example, choosing among available pen
             widths in a drawing program.  The available single-
             choice components are as follows:

                +o RadioBox

                +o OptionButton

                +o List

             You should choose a single-choice component based on
             the number of items to choose among, the space
             available for the selection area, and the permanence of
             the selection.  For a small number of items, the best
             component is a RadioBox or an OptionButton.  RadioBoxes
             should usually contain no more than 5 or 6 items.
             Option Menus, which are connected to OptionButtons,
             should usually contain no more than 10 to 12 items.  If
             there is very little space available in your
             application, you should use an OptionButton over a
             RadioBox, since the OptionButton takes up very little
             space.

             When the number of items to choose from gets larger
             than a RadioBox or OptionButton can easily handle, you
             should use a List.  You should also use a List when the
             items to choose from can change.  For application
             consistency, the choices in a RadioBox or OptionButton
             should not change, but, if they do, you should use an
             OptionButton over a RadioBox.  If a RadioBox or
             OptionButton choice becomes unavailable, it should be
             disabled rather than removed.  Section 6.3.1.6
             describes disabling components in detail.



        6.1.2.2  CChhoooossiinngg aa MMuullttiippllee--CChhooiiccee CCoommppoonneenntt


             A multiple-choice control or group of controls allows
             the user to simultaneously choose multiple items from a
             group of items.  Applications should use multiple-
             choice components, rather than a series of single-






        6-10                                         August 26, 1994







                                       Application Design Principles


             choice actions, where the user may want to select more
             than one item from a group.  The available multiple-
             choice components are as follows:

                +o CheckBox

                +o List

             As with single-choice components, the main factor when
             choosing which one to use is the number of items in the
             group.  For small groups of fewer than seven static
             elements, applications should use a CheckBox.
             Applications should otherwise use a List.  Note that a
             List component can be used as a single-choice or
             multiple-choice component.



        6.1.2.3  CChhoooossiinngg AAmmoonngg MMeennuuss aanndd PPaanneellss


             Popup Menus should only be considered as shortcuts to
             application features because they are hidden in the
             application.  Features hidden in Popup Menus are
             difficult to find for beginning users of an application
             because they provide no cue to their existence;
             however, they can provide rapid access to frequently
             used functionality once the user learns their contents.
             Applications should use Popup Menus to allow users to
             remain focused on their work areas and when there is
             not enough space in the client area for a Panel of
             buttons.

             Popup Menus contain a set of buttons that can be used
             in the same way as a Panel of buttons or a Pulldown
             Menu.  The primary difference is availability.  A Popup
             Menu is only visible when requested by the user.  At
             all other times it is hidden, providing no cue to its
             existence.  When the user requests a Popup Menu, the
             application displays it at the location of the pointer.
             Buttons and Pulldown Menus, on the other hand, are
             always visible, but users need to move the focus away
             from their main work to activate them.  Another
             difference is that buttons take up screen space while
             Popup Menus do not.  Pulldown Menus provide a good
             compromise in space and availability versus Popup Menus
             and Panels.

             Applications should use a Panel of buttons when the
             user makes frequent or multiple selections and when
             space in the client area allows.  Whenever the choice




        August 26, 1994                                         6-11







        OSF/Motif Style Guide


             between Popup Menus and Panels is difficult,
             applications should favor Panels.

             A good compromise solution to these problems is a
             TearOff Menu.  A TearOff Menu is a Pulldown Menu until
             the user wants it torn off into a DialogBox.  After the
             Menu is torn off, the user can position it and use it
             in the same way as a Panel.  TearOff Menus are
             especially useful because they contain a set of
             PushButtons that are not part of the main function of
             an application, allowing the user to activate the
             PushButtons multiple times in a row; for example, a
             font size Menu in a text editing application.  In this
             case, the user can use the Pulldown Menu to change the
             font size of a single selected word or tear off the
             Menu into a Panel to perform a number of font size
             changes in the document.  After finishing the font size
             changes, the user can dismiss the font size Panel.



        6.1.2.4  CChhoooossiinngg BBeettwweeeenn TTeexxtt oorr CCaannvvaass,, aanndd aa LLaabbeell


             A Label is a simple mechanism for displaying text or
             graphics.  A Label does not have any mechanisms for the
             user to edit its contents, or the overhead required for
             editing.  Applications should use a Label for
             displaying text or graphics that do not need user
             editing.  Applications should use a Text or Canvas when
             the text or graphics needs to be edited.  On some
             systems, the contents of a Label are not selectable.
             If the user needs to select the contents of some
             noneditable text or graphics, applications should use a
             Text or Canvas and disable editing rather than using a
             Label.



        6.2  LLaayyoouutt


             The previous section described the components that are
             available for building an application.  This section
             describes how to combine those components into a
             coherent application that encourages a user's sense of
             control.  The guidelines presented in this section will
             help you create applications that are both consistent
             within themselves and with other OSF/Motif compliant
             applications.





        6-12                                         August 26, 1994







                                       Application Design Principles


             This section discusses the following client area design
             topics:

                +o Common client areas

                +o Grouping components

                +o Menu design

                +o DialogBox design

                +o Designing drag and drop

             Design the layout of your application windows according
             to the natural use order and the natural scanning order
             of the people who will be using your application.

             First design for the natural use order.  Consider the
             tasks that the user will perform with your application.
             The components should be positioned so that moving
             among the components is simple and quick while
             performing the most common tasks-the less pointer
             movement, the better.  This is also true for keyboard
             traversal-the fewer keystrokes required to perform a
             task, the better.

             The natural scanning order is most important when
             arranging small groups of components to help the user
             find the correct component for the task.  You should
             put the most important and most used commands first.
             In most cases, this order is from left to right and
             from top to bottom.  For users in right-to-left
             language environments, the natural scanning direction
             is from right to left and from top to bottom.



        6.2.1  CCoommmmoonn CClliieenntt AArreeaass


             Your application is presented in windows.  The windows
             can be either MainWindows, DialogBoxes, or Menus.  The
             contents of these windows are the application client
             areas.  Some of these client areas have common features
             that are described in this section.  The following
             subsections describe in detail the contents of the
             MainWindow and the common MainWindow areas:

                +o Command area






        August 26, 1994                                         6-13







        OSF/Motif Style Guide


                +o Message area

                +o ScrollBars

                +o MenuBar

             Following this is a description of some common Popup
             Menus and DialogBoxes.  These common client areas
             provide a familiar base for users new to your
             application to begin working.



        6.2.1.1  MMaaiinnWWiinnddooww


             Figure 6-1 shows a MainWindow with its client areas.

          FFiigguurree 66--11..  A Typical MainWindow and Its Common Client
                       Areas

             MainWindows contain the framework for your application.
             The principal component of a MainWindow is typically a
             scrollable work area.  The application can also provide
             a group of useful controls, arranging these along the
             top, bottom, or side of the work area.

             In a text editing application, a MainWindow usually
             contains the text.  In a spreadsheet application, a
             MainWindow usually contains the spreadsheet.  In a mail
             browsing application, a MainWindow usually contains a
             list of mail messages and an area for viewing a
             message.  Every application must have at least one       *
             MainWindow.

             Some applications may want more than one MainWindow;
             for example, applications with more than one primary
             function, like the query and update features of a
             database, and applications with more than one instance
             of the same primary function, like a graphics editor
             working on multiple figures.  When an application has
             multiple MainWindows that serve the same primary
             function, each window should be treated as a separate
             application.  Each window must close and iconify         *
             separately.  When an application has multiple            *
             MainWindows that serve different primary functions,      *
             each window must be iconifiable separately, but it is    *
             up to the application to decide whether each closes      *
             separately or whether closing one window closes the      *
             entire application.  You should take special care to
             identify, using the window manager title bar or a




        6-14                                         August 26, 1994







                                       Application Design Principles


             prominent internal Label, which DialogBoxes belong to
             each MainWindow.



        6.2.1.2  CCoommmmaanndd AArreeaa


             Even though user interface applications are oriented
             toward direct manipulation of graphical elements, your
             application can provide an area for a user to enter a
             typed command.  This can be particularly useful when
             updating an existing command-based application to an
             application based on a graphical user interface.

             If your application includes a command area, it should
             run from border to border across the MainWindow.  If
             the MainWindow includes a message area at the bottom,
             the command area should be placed just above the
             message area; otherwise, it should be placed at the
             bottom of the MainWindow.

             The command area often consists of one or both of the
             following components:

                +o A command entry area, consisting of a command
                  entry field or a CommandBox

                +o A group of PushButtons for common window actions



        6.2.1.3  MMeessssaaggee AArreeaa


             Your application can provide a message area in the
             MainWindow for presenting application messages.  Your
             application should not use a message area for warnings
             or messages requiring immediate action.  These should
             be displayed in a DialogBox.

             The message area can be used to provide brief help,
             either in response to a request from the user or, as
             the focus changes, to indicate the purpose of the
             component with the focus.

             If your application includes a message area, it should
             run from border to border across the bottom of the
             MainWindow, below any ScrollBars or the command area.
             Your application can display and remove the message
             area as needed.




        August 26, 1994                                         6-15







        OSF/Motif Style Guide


        6.2.1.4  SSccrroollllBBaarrss


             An application can use ScrollBars in its MainWindow to
             provide a means for viewing an area larger than the
             MainWindow.  Your application defaults should place
             ScrollBars on the bottom and right sides of the
             application. (ScrollBar placement can be a user
             preference.)  You should place ScrollBars below the
             MenuBar and above any command or message area.
             ScrollBars should not scroll the MenuBar, command area,
             or message area.  The ScrollBars can be displayed and
             removed as needed.



        6.2.1.5  MMeennuuBBaarr


             A MenuBar is a basic group that organizes the most
             common features of an application.  The MenuBar must be  *
             a horizontal bar at the top edge of the application      *
             just below the title area of the window frame.  The
             MenuBar contains a list of Menu topics in
             CascadeButtons with Pulldown Menus connected to them.    *
             A MenuBar must contain only CascadeButtons, because      *
             other buttons inhibit Menu browsing.  Each Menu topic
             should have a single-letter mnemonic indicated by
             underlining.

             The following Pulldown Menus provide general functions
             common to most applications.  Remember that these Menu
             guidelines, like all the guidelines in this _O_S_F/_M_o_t_i_f
             _S_t_y_l_e _G_u_i_d_e, apply only in a left-to-right language
             environment in an English-language locale.  You need to
             make the appropriate changes for other locales.

             FF__iillee      The FFiillee Menu should contain components for
                       performing actions on the files, such as
                       opening, saving, closing, and printing.  It
                       should also contain components for performing
                       actions on the application as a whole, such
                       as quitting.  If the Label FFiillee is not
                       appropriate to the context of your
                       application, you can choose a different, more
                       appropriate Label.  The FFiillee Menu should have
                       a mnemonic of FF.

             SS__eelleecctteedd  The SSeelleecctteedd Menu should contain components
                       for performing actions on the objects
                       represented by the current selection of the




        6-16                                         August 26, 1994







                                       Application Design Principles


                       application, such as opening or printing a
                       selected item.  This Menu is often similar to
                       the FFiillee Menu, except that it acts on the
                       objects denoted by the current selection.
                       For example, in a directory browser, OOppeenn in
                       the FFiillee Menu could (using a DialogBox)
                       prompt the user for the name of a directory
                       to open for browsing, while OOppeenn in the
                       SSeelleecctteedd Menu opens the file whose icon is
                       currently selected in the browser.  The
                       SSeelleecctteedd Menu should not contain editing
                       functions normally found in the EEddiitt Menu.
                       The SSeelleecctteedd Menu should have a mnemonic of
                       SS.

             EE__ddiitt      The EEddiitt Menu should contain components for
                       performing actions on the current data of the
                       application, such as an undo action or making
                       global substitutions in a block of text.  It
                       should also include components for
                       interacting with the system clipboard, such
                       as cut, copy, and paste.  The EEddiitt Menu
                       should have a mnemonic of EE.

             VV__iieeww      The VViieeww Menu should contain components for
                       changing the user's view on the data.
                       Components in the VViieeww Menu should not
                       actually change the data.  The exact contents
                       of the VViieeww Menu are application specific but
                       can include components that change the
                       appearance of the data, the amount of data
                       that is displayed, or the order in which the
                       data is displayed.  The VViieeww Menu should have
                       a mnemonic of VV.

             OO__ppttiioonnss   The OOppttiioonnss Menu should contain components
                       for a user to customize the application.  The
                       exact contents of the OOppttiioonnss Menu are
                       application specific.  The OOppttiioonnss Menu
                       should have a mnemonic of OO.

             HH__eellpp      The HHeellpp Menu should contain components that
                       provide user help facilities.  The components
                       in the HHeellpp Menu usually bring up a DialogBox
                       with help information.  Every application
                       should have a HHeellpp Menu.  The HHeellpp Menu
                       should have a mnemonic of HH.

             While we recommend that you include the common Menus in
             the MenuBar of your application, your choice of Menu
             titles and items depends on the nature of your




        August 26, 1994                                         6-17







        OSF/Motif Style Guide


             application.  If your application requires it, you
             should design more relevant titles and selections, but
             do not change the meanings of items used in the common
             Menus.

             If any of the common Menus are present, they must be     *
             arranged in the following order with respect to each     *
             other, ranging from left to right across the MenuBar in  *
             a left-to-right language environment:                    *

                  FFiillee Menu                                           *
                  SSeelleecctteedd Menu                                       *
                  EEddiitt Menu                                           *
                  VViieeww Menu                                           *
                  OOppttiioonnss Menu                                        *
                  HHeellpp Menu                                           *

             You can omit any of these Menus if they are not
             relevant to the application.  You can also intersperse
             other, application-specific, Menus among these Menus.    *
             However, if a FFiillee Menu is present, it must be the       *
             first Menu and must be placed at the far left of the     *
             MenuBar.  If a HHeellpp Menu is present, it must be the      *
             last Menu and must be placed at the far right of the     *
             MenuBar.

             The recommended contents of the FFiillee, EEddiitt, and HHeellpp
             Menus follow.  The contents of the SSeelleecctteedd, VViieeww, and
             OOppttiioonnss Menus are application specific and are not
             specified here.  Each of these common Menus can contain
             a TearOffButton.



        6.2.1.5.1  FFiillee MMeennuu CCoonntteennttss

             Figure 6-2 shows a sample FFiillee Menu.  The common Menu
             contents are described following the figure.  Note that
             you should only include those functions actually
             supported by your application.  The FFiillee Menu can
             contain a TearOffButton.














        6-18                                         August 26, 1994







                                       Application Design Principles


                 FFiigguurree 66--22..  The File Menu and Its Selections

             NN__eeww         Must create a new file.  This operation      *
                         must clear existing data from the client     *
                         area.  If completion of the operation will   *
                         obliterate current changes to the file, you  *
                         must display a DialogBox, asking the user    *
                         about saving changes.  This action must      *
                         have the mnemonic NN.

             OO__ppeenn .. .. ..  Must open an existing file.  This operation  *
                         must prompt the user for the name of the     *
                         file with a DialogBox.  The title bar
                         should be updated with the name of the
                         newly opened file.  If completion of the     *
                         operation will obliterate current changes    *
                         to the file, you must display a DialogBox,   *
                         asking the user about saving changes.  This
                         DialogBox should be displayed after the
                         user selects a new file.  This action must   *
                         have the mnemonic OO.

             SS__aavvee        Must save the currently opened file without  *
                         removing the existing contents of the        *
                         client area.  If the currently opened file   *
                         has no name, SSaavvee must prompt for a          *
                         filename with a DialogBox.  This action      *
                         must have the mnemonic SS.

             SSaavvee AA__ss .. .. .. Must save the currently opened file under  *
                         a new name without removing the existing     *
                         contents of the client area.  This           *
                         operation must prompt for the name of the    *
                         file with a DialogBox.  If the user tries    *
                         to save the new file under an existing       *
                         name, SSaavvee AAss must alert the user with a     *
                         DialogBox if a possible loss of data would   *
                         occur.  This action must have the mnemonic   *
                         AA.

             PP__rriinntt       Must schedule a file for printing.  If your  *
                         application requires specific printing       *
                         information before printing, the operation   *
                         must first request that information with a   *
                         DialogBox, and the entry title must be       *
                         followed by an ellipsis.  Printing
                         information can also be specified for the
                         application in the OOppttiioonnss Menu.  This       *
                         action must have the mnemonic PP.






        August 26, 1994                                         6-19







        OSF/Motif Style Guide


             CC__lloossee       Can be supplied in applications that have
                         multiple independent primary windows.  This  *
                         action must not be supplied in applications  *
                         with a single primary window or multiple     *
                         dependent primary windows.  This action      *
                         must only close the current primary window   *
                         and its associated secondary windows; that   *
                         is, the window family.  This action must     *
                         have the mnemonic CC.  You can include this
                         action even though it is similar to the
                         CClloossee action in the window Menu.  This
                         ensures that users have a way to close the
                         primary window even if they are not running
                         a compliant window manager.  Applications    *
                         must prompt the user to save any unsaved     *
                         changes if the action would cause loss of    *
                         data.

             EExx__iitt        Must end the current application and all     *
                         windows associated with it.  This action is
                         equivalent to closing all primary windows
                         of the application.  This action must have   *
                         the mnemonic XX.  You should include this
                         action even though it is similar to the
                         CClloossee action in the window Menu.  This
                         ensures that users have a way to end the
                         application even if they are not running a
                         compliant window manager.  Applications      *
                         must prompt the user to save any unsaved     *
                         changes if the action would cause loss of    *
                         data.  If your application does not have a
                         FFiillee Menu, put EExxiitt at the end of the first
                         Pulldown Menu.

             You should include Menu items in the order described.
             If you add new Menu items, you should insert them near
             similar elements.


















        6-20                                         August 26, 1994







                                       Application Design Principles


        6.2.1.5.2  EEddiitt MMeennuu CCoonntteennttss

             Figure 6-3 shows a sample EEddiitt Menu.  The common Menu
             contents are described following the figure.  Note that
             you should only include those functions actually
             supported by your application.  The EEddiitt Menu can
             contain a TearOffButton.

                 FFiigguurree 66--33..  The Edit Menu and Its Selections

             UU__nnddoo   AAlltt++BBaacckkssppaaccee
                       Must reverse the most recently executed        *
                       action.  To provide a visual cue to the user,
                       the UUnnddoo selection title should be
                       dynamically modified to indicate what is
                       being undone.  For example, if the most
                       recently executed action was a paste, the
                       action name would be UUnnddoo ppaassttee.  Your
                       application should be able to undo all of the
                       actions in the EEddiitt Menu.  This action must    *
                       have the mnemonic UU.

             CCuutt__   SShhiifftt++DDeell
                       Must remove the selected portion of data from  *
                       the client area to the clipboard.  This        *
                       action must choose the component to act on by  *
                       following the rules in Section 4.2.2 for       *
                       operations that act on selections.  This       *
                       action must have the mnemonic TT.

             CC__ooppyy   CCttrrll++IInnss
                       Must copy the selected portion of data to the  *
                       clipboard without removing the original data   *
                       from the client area.  This action must        *
                       choose the component to act on by following    *
                       the rules in Section 4.2.2 for operations      *
                       that act on selections.  This action must      *
                       have the mnemonic CC.

             CCooppyy LLiinnkk__
                       Must copy a link of the selected portion of    *
                       data to the clipboard without removing the     *
                       original data from the client area.  This      *
                       action must choose the component to act on by  *
                       following the rules in Section 4.2.2 for       *
                       operations that act on selections.  This       *
                       action must have the mnemonic KK.

             PP__aassttee   SShhiifftt++IInnss
                       Must paste the contents of the clipboard into  *
                       a client area.  This action must choose the    *




        August 26, 1994                                         6-21







        OSF/Motif Style Guide


                       component to act on by following the rules in  *
                       Section 4.2.2 for operations that do not act   *
                       on selections.  This action must have the      *
                       mnemonic PP.

             PPaassttee LL__iinnkk
                       Must paste a link of the data represented by   *
                       the contents of the clipboard into a client    *
                       area.  This action must choose the component   *
                       to act on by following the rules in Section    *
                       4.2.2 for operations that do not act on        *
                       selections.  This action must have the         *
                       mnemonic LL.

             CCllee__aarr     Must remove a selected portion of data from    *
                       the client area without copying it to the      *
                       clipboard.  The remaining data is not
                       compressed to fill the space that was
                       occupied by the cleared data.  This action     *
                       must choose the component to act on by         *
                       following the rules in Section 4.2.2 for       *
                       operations that act on selections.  This       *
                       action must have the mnemonic EE.

             DD__eelleettee    Must remove a selected portion of data from    *
                       the client area without copying it to the      *
                       clipboard.  This action must choose the        *
                       component to act on by following the rules in  *
                       Section 4.2.2 for operations that act on       *
                       selections.  This action must have the         *
                       mnemonic DD.

             SSeelleecctt AAllll   CCttrrll++//
                       Must make the primary selection consist of     *
                       all the elements in a component of the client  *
                       area.  This action must choose the component   *
                       to act on by following the rules in Section    *
                       4.2.2 for operations that do not act on        *
                       selections.  If the action uses an
                       accelerator, it should be <<CCttrrll>> <<//>>.

             DDeesseelleecctt AAllll   CCttrrll++\\
                       Must remove from the primary selection all     *
                       the elements in a component of the client      *
                       area.  This action must choose the component   *
                       to act on by following the rules in Section    *
                       4.2.2 for operations that do not act on        *
                       selections.  If the action uses an
                       accelerator, it should be <<CCttrrll>> <<\\>>.






        6-22                                         August 26, 1994







                                       Application Design Principles


             SSeelleecctt PPaasstteedd
                       Must make the primary selection consist of     *
                       the last element or elements pasted into a     *
                       component of the client area.  This action     *
                       must choose the component to act on by         *
                       following the rules in Section 4.2.2 for       *
                       operations that do not act on selections.

             RReesseelleecctt   AAlltt++IInnsseerrtt
                       Must make the primary selection consist of     *
                       the last selected element or elements in a     *
                       component of the client area.  This action     *
                       must choose the component to act on by         *
                       following the rules in Section 4.2.2 for       *
                       operations that do not act on selections.      *
                       The action must be available only in           *
                       components that do not support persistent      *
                       selections and only when the current           *
                       selection is empty.  If the action uses an
                       accelerator, it should be <<AAlltt>> <<IInnsseerrtt>>.

             PPrroommoottee   AAlltt++IInnsseerrtt
                       Must promote to the primary selection the      *
                       current selection of a component of the        *
                       client area.  This action must choose the      *
                       component to act on by following the rules in  *
                       Section 4.2.2 for operations that act on       *
                       selections.  This action must only be          *
                       available for components that support          *
                       persistent selections.  If the action uses an
                       accelerator, it should be <<AAlltt>> <<IInnsseerrtt>>.

             You should include Menu items in the order described.
             If you add new Menu items, you should insert them near
             similar elements.

             If you use accelerators for UUnnddoo, CCuutt, CCooppyy, and PPaassttee,  *
             you must use either one or both of the models presented  *
             in the following two tables.

                TTAABBLLEE 66--22..  Edit Menu Accelerators, Model 1

                       EEddiitt MMeennuu IItteemm   AAcccceelleerraattoorr
                       __________________________________
                       UUnnddoo             <<AAlltt>> <<BBaacckkSSppaaccee>>
                       CCuutt              <<SShhiifftt>> <<DDeelleettee>>
                       CCooppyy             <<CCttrrll>> <<IInnsseerrtt>>
                       PPaassttee            <<SShhiifftt>> <<IInnsseerrtt>>







        August 26, 1994                                         6-23







        OSF/Motif Style Guide


                TTAABBLLEE 66--33..  Edit Menu Accelerators, Model 2

                          EEddiitt MMeennuu IItteemm   AAcccceelleerraattoorr
                          ____________________________
                          UUnnddoo             <<CCttrrll>> <<ZZ>>
                          CCuutt              <<CCttrrll>> <<XX>>
                          CCooppyy             <<CCttrrll>> <<CC>>
                          PPaassttee            <<CCttrrll>> <<VV>>

             In addition, if your keyboard has <<UUnnddoo>>, <<CCuutt>>,
             <<CCooppyy>>, and <<PPaassttee>> keys, these should be supported as
             accelerators for the corresponding Menu items as well.



        6.2.1.5.3  HHeellpp MMeennuu CCoonntteennttss


             There are two acceptable models for the contents of the
             HHeellpp Menu.  This guide allows either model.

             Figure 6-4 shows a sample of the first model for the
             HHeellpp Menu.  The common Menu contents for this model are
             described following the figure.  Note that you should
             only include those functions actually supported by your
             application.  The HHeellpp Menu can contain a
             TearOffButton.




























        6-24                                         August 26, 1994







                                       Application Design Principles


          FFiigguurree 66--44..  The Help Menu and Its Selections (First Model)

             OOnn CC__oonntteexxtt   SShhiifftt++HHeellpp
                            Must initiate context-sensitive help by   *
                            changing the shape of the pointer to the  *
                            question pointer described in Section     *
                            2.2.2.  When the user moves the pointer   *
                            to the component help is wanted on and    *
                            presses BBSSeelleecctt, any available context-   *
                            sensitive help for the component must be  *
                            presented, and the pointer reverts from   *
                            the question pointer.  This action must   *
                            have the mnemonic CC.  If the action uses  *
                            an accelerator, it must be <<SShhiifftt>>        *
                            <<HHeellpp>>.

             OOnn HH__eellpp        Must provide information on how to use    *
                            the application's help facility.  This    *
                            action must have the mnemonic HH.

             OOnn WW__iinnddooww      Must provide general information about    *
                            the window from which help was            *
                            requested.  This action must have the     *
                            mnemonic WW.

             OOnn KK__eeyyss        Must provide information about the        *
                            application's use of function keys,       *
                            mnemonics, and keyboard accelerators.     *
                            This action must have the mnemonic KK.

             II__nnddeexx          Must provide an index for all help        *
                            information in the application.  This     *
                            action must have the mnemonic II.  The
                            index can provide search capabilities.

             TT__uuttoorriiaall       Must provide access to the application's  *
                            tutorial.  This action must have the      *
                            mnemonic TT.

             OOnn VV__eerrssiioonn     Must provide the name and version of the  *
                            application.  This action must have the   *
                            mnemonic VV.  It can provide other
                            information as well.

             Figure 6-5 shows a sample of the second model for the
             HHeellpp Menu.  The common Menu contents in the model are
             described following the figure.  Note that you should
             only include those functions actually supported by your
             application.  The HHeellpp Menu can contain a
             TearOffButton.





        August 26, 1994                                         6-25







        OSF/Motif Style Guide


          FFiigguurree 66--55..  The Help Menu and Its Selections (Second Model)

             CC__oonntteexxtt--SSeennssiittiivvee HHeellpp   SShhiifftt++HHeellpp
                             Must initiate context-sensitive help by  *
                             changing the shape of the pointer to     *
                             the question pointer described in        *
                             Section 2.2.2.  When the user moves the  *
                             pointer to the component help is wanted  *
                             on and presses BBSSeelleecctt, any available    *
                             context-sensitive help for the           *
                             component must be presented, and the     *
                             pointer reverts from the question        *
                             pointer.  This action should be          *
                             followed by a separator.  This action    *
                             must have the mnemonic CC.  If the        *
                             action uses an accelerator, it must be   *
                             <<SShhiifftt>> <<HHeellpp>>.

             OO__vveerrvviieeww        Must provide general information about   *
                             the application window from which help   *
                             was requested.  This action must have    *
                             the mnemonic OO.

             II__nnddeexx           Must provide an index for all help       *
                             information in the application.  This    *
                             action must have the mnemonic II.  The
                             index can provide search capabilities.

             KK__eeyybbooaarrdd        Must provide information about the       *
                             application's use of function keys,      *
                             mnemonics, and keyboard accelerators.    *
                             This action must have the mnemonic KK.

             TT__uuttoorriiaall        Must provide access to the               *
                             application's tutorial.  This action     *
                             must have the mnemonic TT.

             UUssiinngg HH__eellpp      Must provide information on how to use   *
                             the application's help facility.  This   *
                             action must have the mnemonic HH.

             PP__rroodduucctt IInnffoorrmmaattiioonn
                             Must provide the name and version of     *
                             the application.  This action must have  *
                             the mnemonic PP.  It can provide other
                             information as well.

             Applications should place additional HHeellpp Menu items
             between IInnddeexx and UUssiinngg HHeellpp.






        6-26                                         August 26, 1994







                                       Application Design Principles


             Help is usually provided in DialogBoxes but can also
             appear in the message area.  You should include Menu
             items in the order described.  If you add new Menu
             items, you should insert them near similar elements.



        6.2.1.6  PPooppuupp MMeennuuss



             A Popup Menu is a Menu that is associated with another
             element.  It is usually hidden from the user and is
             posted using BBMMeennuu and <<MMeennuu>>.  It is used to organize
             actions that are specific to its associated element,
             but it should not be the only place in an application
             where those actions are available; that is, Popup Menus
             should be a redundant element of a user interface whose
             main purpose is to provide the experienced user with a
             quick way to perform common tasks on individual
             elements.

             The following common actions provide general functions
             common to Popup Menus in many applications.  While we
             recommend that you include these common actions in your
             Popup Menus consistently with the descriptions here,
             your choice of items depends on the nature of your
             application.  If your application requires it, you
             should design more relevant titles and selections, but
             do not change the meanings of items used in the common
             Popup Menus.

             Even within a single control, such as a Canvas, the
             contents of a Popup Menu can depend on the position
             within the control, or the state of the elements at
             that position, such as whether the Menu is popped up
             from within a selected range of elements.  When BBMMeennuu
             is used to pop up the Menu, the location of the pointer
             when BBMMeennuu is pressed is what matters.  When <<MMeennuu>> is
             used to pop up the Menu, what matters is the position
             of the location cursor within the control.

             Note that you should include only those functions
             actually supported by your application.  Remember that
             these Menu guidelines, like all the guidelines in this
             guide, apply only in a left-to-right language
             environment in an English-language locale.  You need to
             make the appropriate changes for other locales.

             PPrrooppeerrttiieess__
                       Must display a properties DialogBox that the   *




        August 26, 1994                                         6-27







        OSF/Motif Style Guide


                       user can use to set the properties of the      *
                       component.  If the Menu is popped up over a
                       selection, it can display the properties of
                       the selection.  If the Menu is popped up over
                       an unselected item, it can display the
                       properties of that item.  If the Menu is
                       popped up over the background, it should
                       display the properties of the collection,
                       except over a part of the background
                       considered to be in the selection.  This
                       action should have the mnemonic SS.

             UU__nnddoo   AAlltt++BBaacckkssppaaccee
                       Must reverse the most recently executed        *
                       action.  To provide a visual cue to the user,
                       the UUnnddoo selection title should be
                       dynamically modified to indicate what is
                       being undone.  For example, if the most
                       recently executed action was a paste, the
                       action name would be UUnnddoo ppaassttee.  This action
                       should have the mnemonic UU.  This action
                       should have the same  accelerator as the
                       corresponding entry in the EEddiitt Menu.

             PPrriimmaarryy MMoovvee   AAlltt++SShhiifftt++DDeelleettee
                       Must move the contents of the primary          *
                       selection to the component.  This action must  *
                       only be used in an editable component.  If
                       the action uses an accelerator, it should be
                       <<AAlltt>> <<SShhiifftt>> <<DDeelleettee>>, <<AAlltt>> <<CCttrrll>> <<XX>>, or
                       both.  In addition, if the keyboard has a
                       <<CCuutt>> key, this action should support <<AAlltt>>
                       <<CCuutt>> as an accelerator.  If more than one
                       format can be moved from the primary
                       selection, PPrriimmaarryy CCooppyy can cascade a Menu of
                       possible transfer formats, in which case it
                       should not have an accelerator.

             PPrriimmaarryy CCooppyy   AAlltt++CCttrrll++IInnsseerrtt
                       Must copy the contents of the primary          *
                       selection to the component.  This action must  *
                       only be used in an editable component.  If
                       the action uses an accelerator, it should be
                       <<AAlltt>> <<CCttrrll>> <<IInnsseerrtt>>, <<AAlltt>> <<CCttrrll>> <<CC>>, or
                       both.  In addition, if the keyboard has a
                       <<CCooppyy>> key, this action should support <<AAlltt>>
                       <<CCooppyy>> as an accelerator.  If more than one
                       format can be copied from the primary
                       selection, PPrriimmaarryy CCooppyy can cascade a Menu of
                       possible transfer formats, in which case it
                       should not have an accelerator.




        6-28                                         August 26, 1994







                                       Application Design Principles


             PPrriimmaarryy LLiinnkk
                       Must place a link to the primary selection in  *
                       the component.  This action must only be used  *
                       in an editable component.  If the link can be
                       viewed in more than one way, PPrriimmaarryy LLiinnkk can
                       cascade a Menu of possible viewing
                       representations.

             CCuutt__       Must cut elements to the clipboard and can     *
                       mark them for use in a subsequent PPaassttee LLiinnkk   *
                       operation. If the Menu is popped up in a       *
                       selection, the entire selection must be cut.
                       If the Menu is popped up over an unselected
                       element, just that element should be cut.  If
                       the Menu is popped up in the background, the
                       entire collection can be cut.  This action
                       should have the mnemonic TT.

             CC__ooppyy      Must copy elements to the clipboard and can    *
                       mark them for use in a subsequent PPaassttee LLiinnkk   *
                       operation.  If the Menu is popped up in a      *
                       selection, the entire selection must be        *
                       copied.  If the Menu is popped up over an
                       unselected element, just that element should
                       be copied.  If the Menu is popped up in the
                       background, the entire collection can be
                       copied.  This action should have the mnemonic
                       CC.

             CCooppyy LLiinnkk__
                       Must copy a link of elements to the clipboard  *
                       and can mark them for use in a subsequent      *
                       PPaassttee LLiinnkk operation.  If the Menu is popped   *
                       up in a selection, a link to the entire        *
                       selection must be copied.  If the Menu is
                       popped up over an unselected element, a link
                       to just that element should be copied.  If
                       the Menu is popped up in the background, a
                       link to the entire collection can be copied.
                       This action should have the mnemonic KK.

             PP__aassttee   SShhiifftt++IInnsseerrtt
                       Must paste the contents of the clipboard to    *
                       the component.  This action must only be used  *
                       in an editable component.  This action should
                       have the mnemonic PP.  This action should have
                       the same accelerator as the corresponding
                       entry in the EEddiitt Menu.

             PPaassttee LL__iinnkk
                       Must paste a link of the contents of the       *




        August 26, 1994                                         6-29







        OSF/Motif Style Guide


                       clipboard to the component.  This action must  *
                       only be used in an editable component.  This
                       action should have the mnemonic LL.

             CCllee__aarr     Must remove a selected portion of data from    *
                       the client area without copying it to the      *
                       clipboard.  If the Menu is popped up in a      *
                       selection, it must delete the selection.  If
                       the Menu is popped up over an unselected
                       element, it should delete that element.  If
                       the Menu is popped up over the background,
                       except over a part of the background
                       considered to be in the selection, it can
                       delete all the elements.  The remaining data
                       is not compressed to fill the space that was
                       occupied by the cleared data.  This action
                       should have the mnemonic EE.

             DD__eelleettee    Must remove a selected portion of data from    *
                       the client area without copying it to the      *
                       clipboard.  If the Menu is popped up in a      *
                       selection, it must delete the selection.  If
                       the Menu is popped up over an unselected
                       element, it should delete that element.  If
                       the Menu is popped up over the background,
                       except over a part of the background
                       considered to be in the selection, it can
                       delete all the elements.  This action should
                       have the mnemonic DD.

             SSeelleecctt AAllll   CCttrrll++//
                       Must make the primary selection consist of     *
                       all the elements in the collection with the    *
                       Popup Menu.  If the action uses an
                       accelerator, it should be <<CCttrrll>> <<//>>.

             DDeesseelleecctt AAllll   CCttrrll++\\
                       Must deselect the current selection in the     *
                       collection with the Popup Menu.  If the
                       action uses an accelerator, it should be
                       <<CCttrrll>> <<\\>>.

             SSeelleecctt PPaasstteedd
                       Must make the primary selection consist of     *
                       the last element or elements pasted into the   *
                       collection with the Popup Menu.

             RReesseelleecctt   AAlltt++IInnsseerrtt
                       Must make the primary selection consist of     *
                       the last selected element or elements in the   *
                       component with the Popup Menu.  The action     *




        6-30                                         August 26, 1994







                                       Application Design Principles


                       must be available only in components that do   *
                       not support persistent selections and only     *
                       when the current selection is empty.  If the
                       action uses an accelerator, it should be
                       <<AAlltt>> <<IInnsseerrtt>>.

             PPrroommoottee   AAlltt++IInnsseerrtt
                       Must promote the current selection to the      *
                       primary selection.  This action must only be   *
                       available in components that support           *
                       persistent selections.  If the action uses an
                       accelerator, it should be <<AAlltt>> <<IInnsseerrtt>>.

             If an action invoked from a Popup Menu, such as PPrriimmaarryy  *
             CCooppyy, inserts or pastes data in a collection, the data   *
             must be pasted at the insertion position of the          *
             component.  However, if the Popup Menu is popped up      *
             over a selection of an editable collection, the          *
             selection must first be deleted, even if pending delete  *
             is disabled, and the pasted data must replace it.

             If an action invoked from a Popup Menu acts on a group   *
             of elements, it behaves according to the following       *
             rules:

                +o If the Menu is popped up in a selection, it must    *
                  act on the entire selection.

                +o If the Menu is popped up on an unselected element
                  of a list or graphics collection, it should act on
                  just that element.

                +o If the Menu is popped up in the background, except
                  in a part of the background considered in the
                  selection, it can act on the entire collection.     *
                  However, if the operation is destructive, it must   *
                  first prompt for verification.

             Appropriate words, such as SSeelleeccttiioonn or words denoting
             the type of a single element of the collection as a
             whole, should be added to a Label to specify which
             elements are affected.  For example, if a Popup Menu
             contains the entry CCooppyy SSeelleeccttiioonn, the current
             selection is copied to the clipboard regardless of
             where in the collection the Menu is popped up.

             A Popup Menu item should have an accelerator only if
             the result of typing the accelerator would be
             equivalent to popping up the Menu by pressing <<MMeennuu>>
             and then selecting the Menu item.  If CCuutt SSeelleeccttiioonn is
             included in a Popup Menu, it should use the same




        August 26, 1994                                         6-31







        OSF/Motif Style Guide


             accelerators as CCuutt in the EEddiitt Menu.  If CCooppyy
             SSeelleeccttiioonn is included in a Popup Menu, it should use
             the same accelerators as CCooppyy in the EEddiitt Menu.



        6.2.1.7  DDiiaallooggBBooxxeess


             Applications use DialogBoxes to interact with the user
             about application details not directly related to the
             primary purpose of the application.  Applications
             display DialogBoxes only when needed to convey a
             message to the user, or when the user requests it to
             provide input to the application.  They follow the same
             general layout guidelines as a MainWindow.  Additional
             guidelines for DialogBox design are given in Section
             6.2.4, as well as in the reference section in Chapter
             9.

             The following DialogBoxes provide general functions
             common to many applications.



        6.2.1.7.1  CCoommmmaannddDDiiaalloogg

             A CommandDialog should be used to enter keyboard
             commands.  It should not interrupt the user's
             interaction with the application; that is, it should
             not be modal.  It should include a CommandBox as shown
             in Figure 6-6.

                          FFiigguurree 66--66..  A CommandDialog



        6.2.1.7.2  FFiilleeSSeelleeccttiioonnDDiiaalloogg

             A FileSelectionDialog should be used to enter the name
             of a file for processing.  It should not interrupt the
             user's interaction with the application; that is, it
             should not be modal.  It should include a
             FileSelectionBox as shown in Figure 6-7.











        6-32                                         August 26, 1994







                                       Application Design Principles


                       FFiigguurree 66--77..  A FileSelectionDialog



        6.2.1.7.3  PPrroommppttDDiiaalloogg

             A PromptDialog should be used to prompt the user for
             input.  It can interrupt the user's interaction with
             the application; that is, it can be application modal.
             It should include a message, a text input area, and one
             of the following button arrangements as shown in Figure
             6-8.

             OOKK CCaanncceell
             OOKK CCaanncceell HHeellpp
             OOKK AAppppllyy CCaanncceell
             OOKK AAppppllyy CCaanncceell HHeellpp
             OOKK AAppppllyy RReesseett CCaanncceell
             OOKK AAppppllyy RReesseett CCaanncceell HHeellpp

                          FFiigguurree 66--88..  A PromptDialog



        6.2.1.7.4  SSeelleeccttiioonnDDiiaalloogg

             A SelectionDialog should be used to allow a user to
             make a selection from a list of choices.  It can
             interrupt the user's interaction with the application;
             that is, it can be application modal.  It should
             contain a SelectionBox as shown in Figure 6-9.
























        August 26, 1994                                         6-33







        OSF/Motif Style Guide


                         FFiigguurree 66--99..  A SelectionDialog



        6.2.1.7.5  MMeessssaaggeeDDiiaalloogg

             A MessageDialog should be used to convey a message to
             the user.  It should include a message and one of the
             following button arrangements:

             OOKK
             OOKK HHeellpp
             OOKK CCaanncceell
             OOKK CCaanncceell HHeellpp
             YYeess NNoo
             YYeess NNoo HHeellpp
             YYeess NNoo CCaanncceell
             YYeess NNoo CCaanncceell HHeellpp
             CCaanncceell
             CCaanncceell HHeellpp
             RReettrryy CCaanncceell
             RReettrryy CCaanncceell HHeellpp

             There are a number of different types of
             MessageDialogs: ErrorDialog, InformationDialog,
             QuestionDialog, WorkingDialog, and WarningDialog.

             An ErrorDialog should be used to convey a message about
             a user error.  It should stop user interaction with the
             application until it is dismissed; that is, it should
             be application modal.  It should include an error
             symbol, a message, and one of the following button
             arrangements as shown in Figure 6-10:

             OOKK CCaanncceell
             OOKK CCaanncceell HHeellpp



















        6-34                                         August 26, 1994







                                       Application Design Principles


                          FFiigguurree 66--1100..  An ErrorDialog

             An InformationDialog should be used to convey
             information to the user.  It must not interrupt the      *
             user's interaction with the application; that is, it     *
             must not be modal.  It should include an information
             symbol, a message, and one of the following button
             arrangements as shown in Figure 6-11:

             OOKK
             OOKK HHeellpp

                       FFiigguurree 66--1111..  An InformationDialog

             A QuestionDialog should be used to get a user response
             to a question.  It should interrupt the user's
             interaction with the application; that is, it should be
             application modal.  It should include a question
             symbol, a message, and one of the following button
             arrangements as as shown in Figure 6-12:

             YYeess NNoo
             YYeess NNoo HHeellpp
             YYeess NNoo CCaanncceell
             YYeess NNoo CCaanncceell HHeellpp

                         FFiigguurree 66--1122..  A QuestionDialog

             A WarningDialog should be used to alert the user to a
             possible danger.  It should interrupt the user's
             interaction with the application; that is, it should be
             application modal.  It should contain a warning symbol,
             a message, and one of the following button arrangements
             as shown in Figure 6-13:

             YYeess NNoo
             YYeess NNoo HHeellpp
             OOKK CCaanncceell
             OOKK CCaanncceell HHeellpp
















        August 26, 1994                                         6-35







        OSF/Motif Style Guide


                         FFiigguurree 66--1133..  A WarningDialog

             A WorkingDialog should be used to show work in progress
             and give the user an opportunity to cancel the
             operation.  It should not interrupt the user's
             interaction with the application; that is, it should
             not be modal.  It should contain a working symbol, a
             message, and any of the following sets of buttons in
             order as shown in Figure 6-14:

             CClloossee
             CCaanncceell or SSttoopp
             PPaauussee RReessuummee
             HHeellpp

             A WorkingDialog should also include a progress
             indicator if that information is available.

                         FFiigguurree 66--1144..  A WorkingDialog



        6.2.2  GGrroouuppiinngg CCoommppoonneennttss


             The following subsections describe how you should group
             components by using the group components described in
             Section 6.1:

                +o Grouping similar components

                +o Arranging components for fixed layout

                +o Arranging components for resizing layout

                +o Arranging components for aligned layout

                +o Arranging components in PanedWindows

             Separators are a good tool for visually separating
             groups of components.  You should use Separators in
             your application any place where the border between two
             groups of components is not obvious by some other
             means, such as for a significant change in component
             types, framing, or a division by space.










        6-36                                         August 26, 1994







                                       Application Design Principles


        6.2.2.1  GGrroouuppiinngg SSiimmiillaarr CCoommppoonneennttss


             Components similar in appearance and function group
             together naturally.  You should organize similar
             components together.  Similar PushButtons, as in a
             Menu, and a Panel of CheckButtons, as in a list of
             options, are good examples of where grouping is
             important.  Without grouping, related actions are
             difficult to find.  One of the most important cases is
             a Panel of RadioButtons.  Without grouping, when you
             turned on one RadioButton, you might not see the
             previous button turn off.  You can also associate a
             title with a group of components to better associate
             the group and its purpose.



        6.2.2.2  AArrrraannggiinngg CCoommppoonneennttss ffoorr FFiixxeedd LLaayyoouutt


             Components that are grouped using a Composition group
             component can be positioned as they best fit, both
             physically and visually.  This is often the case in the
             MainWindow client area, and is also useful when the
             layout of the components is important to the
             application.

             When you lay out components in this manner, remember
             that your application can be resized by the user.  This
             can be compensated for in a number of ways.  If the
             area has a fixed size and is not appropriate to scroll,
             like a control panel, you can either clip the area or
             turn off resizing.  If the area has a fixed size and is
             appropriate to scroll, you should include ScrollBars
             for scrolling the viewable area.



        6.2.2.3  AArrrraannggiinngg CCoommppoonneennttss ffoorr RReessiizziinngg LLaayyoouutt


             Composition component groups can also be positioned so
             that the position and size of each component is
             relative to the Composition component group or other
             components in the group.  This style of layout permits
             the components to change size proportionally to any
             change in the size of the Composition component.

             Sometimes a window is resized too small to be useful.
             Your application can either simply ignore this, clip




        August 26, 1994                                         6-37







        OSF/Motif Style Guide


             the region once all the components are at their minimum
             size, remove less useful components to make room for
             more shrinking, or replace all the components with a
             message that indicates that the minimum size is
             reached, stating that the user needs to enlarge the
             window to continue working in it.



        6.2.2.4  AArrrraannggiinngg CCoommppoonneennttss ffoorr AAlliiggnneedd LLaayyoouutt


             Panels can arrange components aligned horizontally,
             vertically, or in two dimensions.  Buttons are usually
             aligned in Panels horizontally along the bottom of the
             client area, either in a MainWindow or in a DialogBox.
             ToggleButtons should be arranged in vertical Panels so
             the graphics align and look neat.  A common use of
             Panels is in building Menus or RadioBoxes; that is, a
             set of RadioButtons.  Two-dimensional Panels are
             commonly used in graphics programs to present drawing
             styles and in spreadsheets to contain cells.

             Your application should use Panels to provide the best
             organization for large groups of similar components.
             Panels should be placed in a Composition component
             group to allow for proper user resizing either by using
             ScrollBars or by resizing the elements of the Panel.



        6.2.2.5  AArrrraannggiinngg CCoommppoonneennttss iinn PPaanneeddWWiinnddoowwss


             PanedWindows provide a way for the user to simply
             adjust the size of components relative to one another.
             You should use PanedWindows to separate user tasks in
             an application with limited space.  This allows the
             user to ignore elements of the application that are
             unused.

             PanedWindows can also be used to present two
             simultaneous views of the same data.  For example, a
             text editor can use multiple Panes, with a separate
             Text component in each Pane to allow the user to write
             in one section of a document while looking at another.
             The user can then resize the Panes to show more or less
             of either block of text.

             PanedWindows can be composed of either vertical (one on
             top of the other) or horizontal (side by side) sets of




        6-38                                         August 26, 1994







                                       Application Design Principles


             Panes, Separators, and Sashes.  Users can resize Panes
             by dragging the boundary between them.  Making one Pane
             bigger makes the other Pane smaller, while the overall
             size of the window remains the same.



        6.2.3  MMeennuu DDeessiiggnn


             Menus are the primary means of organizing most of an
             application's features.  Because of screen size
             limitation and visual simplicity, Menus organize
             components used frequently by users and components used
             in most application sessions.

             There are four types of Menus:

                +o Pulldown Menus

                +o TearOff Menus

                +o Popup Menus

                +o Option Menus

             Pulldown Menus are pulled down from a CascadeButton.
             CascadeButtons should always be available in the
             context that they are needed.  Menus can also contain
             CascadeButtons so that Menus can be nested.  The
             MenuBar is a horizontal collection of CascadeButtons.

             TearOff Menus are a combination of a TearOffButton and
             another Menu, usually a Pulldown Menu.  A TearOffButton
             contains a dashed line graphic representing
             perforations.  TearOffButtons must be the first element  *
             within a Menu.  When the TearOffButton is activated,
             the Menu changes into a DialogBox.  A TearOff Menu is
             useful when you do not want the Menu to disappear after
             a Menu selection.

             Popup Menus are context sensitive, but give no cue to
             their existence.  They are popped up when the user
             presses BBMMeennuu over a component with an associated Popup
             Menu.  Popup Menus should only be used to provide
             shortcuts, since new users of an application may not
             realize or remember that they exist.  Even within a
             single control, such as a Canvas, the contents of a
             Popup Menu can depend on the position within the
             control, or the state of the elements at that position,
             such as whether the Menu is popped up from within a




        August 26, 1994                                         6-39







        OSF/Motif Style Guide


             selected range of elements.

             Option Menus provide a means of selecting from a set of
             choices while taking up very little space.  An Option
             Menu is popped up from an OptionButton, which is
             distinguished by a bar graphic on the right side of the
             button.

             Menus are composed of titles, elements, mnemonics, and
             accelerators.  A Menu's title should be unique to avoid
             confusion.  The title should clearly indicate the
             purpose of the Menu.

                +o A Pulldown Menu's title is taken from the Label in
                  the CascadeButton.

                +o A Popup Menu's title should be placed at the top
                  of the Popup Menu and separated from the Menu
                  elements by a Separator.

                +o An Option Menu's title is usually a Label to the
                  left of the OptionButton, but it can be at the top
                  of the Option Menu itself.

             Most basic controls can be Menu elements including
             Labels, Separators, PushButtons, ToggleButtons, and
             CascadeButtons.  The elements can be identified by
             either a text label or a graphic.  A Menu must be wide   *
             enough to accommodate its widest element.

             A mnemonic provides a quick way to access Menu elements
             from the keyboard.  While the location cursor is in a
             Menu or MenuBar, pressing the mnemonic letter of an
             element activates that element.  The MenuBar's and any
             Option Menu's mnemonics can be used by pressing <<AAlltt>>
             with the mnemonic letter.  An element's mnemonic should
             be the first character of the element's Label.  If that
             character conflicts with another mnemonic in the Menu,
             another character in the Label should be used.  The
             mnemonic of an element should be underlined in the
             element's Label.  When the appropriate mnemonic letter
             does not appear in the element's Label, it should
             appear in parentheses after the Label.

             An accelerator provides a way to access Menu elements
             from the keyboard without posting the Menu.
             Accelerators are useful to the experienced user for
             saving time when using frequently used components.  You
             should provide accelerators primarily as a matter of
             utility, not design conformity.





        6-40                                         August 26, 1994







                                       Application Design Principles


             If a keyboard accelerator exists for a Menu entry, it
             should appear following the Menu's Label, justified on
             the same line.  The accelerator and the selection
             should be separated by enough space to make them
             visually distinct.

             You should use the following guidelines when designing
             Menus and Menu systems:

                +o Keep Menu structures simple.

                +o Group like Menu elements together.

                +o List Menu selections by frequency of use.

                +o List Menu selections by order of use.

                +o Separate destructive actions.

                +o Provide mnemonics and accelerators.

                +o Use TearOffButtons in frequently used Menus.



        6.2.3.1  KKeeeeppiinngg MMeennuu SSttrruuccttuurreess SSiimmppllee


             Applications should keep Menu structures simple.  One
             of the primary benefits of Menus is the ease of access
             to the elements of the Menu.  While cascading submenus
             help the application and the user organize Menu
             elements, each level of a submenu reduces the ease of
             access to the Menu elements.  Multiple levels of
             cascading submenus can also quickly create visual
             clutter.  Whenever you consider using a cascading
             submenu, you should consider using a DialogBox or more
             Pulldown Menus instead.



        6.2.3.2  GGrroouuppiinngg LLiikkee MMeennuu EElleemmeennttss TTooggeetthheerr


             Applications should group Menu elements into logical
             groups.  This helps the user locate specific Menu
             elements.  You should first try to place a new Menu
             element into the common Menu groups described in
             Section 6.2.1.5.  If that is not appropriate, you
             should group new Menu elements according to function,
             with the more frequently used element appearing first.




        August 26, 1994                                         6-41







        OSF/Motif Style Guide


             You should also use Separators between logical groups
             of elements.



        6.2.3.3  LLiissttiinngg MMeennuu SSeelleeccttiioonnss bbyy FFrreeqquueennccyy ooff UUssee


             As in other client areas, applications should order
             Menu elements according to the frequency of usage,
             positioning the most frequently used elements near the
             top of the Menu.



        6.2.3.4  LLiissttiinngg MMeennuu SSeelleeccttiioonnss bbyy OOrrddeerr ooff UUssee


             More important to Menu design than the frequency of use
             is the order of use.  Applications should order Menu
             elements according to the order of usage.  For example,
             the CCooppyy element should be placed before PPaassttee.. This
             helps the user's interactions flow smoothly.



        6.2.3.5  SSeeppaarraattiinngg DDeessttrruuccttiivvee AAccttiioonnss


             Applications should separate destructive actions from
             frequently chosen selections.  This is to avoid
             accidental selection of the destructive element.
             Destructive elements, like DDeelleettee or CClleeaarr, should be
             placed at the end of a Pulldown Menu and separated from
             other elements by a Separator.



        6.2.3.6  PPrroovviiddiinngg MMnneemmoonniiccss aanndd AAcccceelleerraattoorrss


             Applications should provide mnemonics and accelerators
             to Menu elements.  Try to choose mnemonics and
             accelerators that are easy to remember by using letters
             from the element's title.  Note that mnemonics and
             accelerators only add to the utility of your
             applications.  They never detract from the basic
             ability of a new user.

             Applications should provide accelerators for frequently
             used Menu items.  In general, accelerators should not




        6-42                                         August 26, 1994







                                       Application Design Principles


             be assigned for every Menu item in an application.  It
             is preferable to assign accelerators that have some
             mnemonic value, although accelerators that use function
             keys are acceptable.

             Applications should not use accelerators that are a
             combination of the modifier <<AAlltt>> and letter keys to
             avoid conflicts with mnemonics.  For example, <<AAlltt>> <<EE>>
             as an accelerator for EExxiitt conflicts with the use of
             <<AAlltt>> <<EE>> to pull down the EEddiitt Menu since it is the
             mnemonic for the EEddiitt CascadeButton in the MenuBar.

             Similarly, applications that involve text entry should
             not use accelerators that are combinations of the
             modifier <<SShhiifftt>> and letter keys to avoid conflict with
             the text entry commands.  Applications that expect
             field controls to have bindings that include
             combinations of the modifier <<CCttrrll>> and letter keys,
             such as text editors, should also avoid these
             combinations.

             Accelerator bindings that use only one modifier are
             preferable to bindings that use two or more modifier
             keys.



        6.2.3.7  UUssiinngg TTeeaarrOOffffBBuuttttoonnss



             Applications should use TearOffButtons in Menus whose
             elements are used many times in a row.  If the
             semantics of the entries in a Popup Menu depend on
             where in a component it is popped up, the Menu should
             not include a TearOffButton, unless context-sensitive
             entries are disabled when the Menu is torn off.  Menu
             entries in a torn off Menu should be enabled or
             disabled as appropriate when the state of the
             application changes.

             After a user tears off a Menu, the Menu elements are
             placed in a DialogBox that is titled with the Menu
             title, and the Menu is unposted.  The TearOffButton
             should be removed from the DialogBox, but, if it
             remains, it can be used to close the DialogBox.









        August 26, 1994                                         6-43







        OSF/Motif Style Guide


        6.2.4  DDiiaallooggBBooxx DDeessiiggnn


             When designing a DialogBox, you should follow all the
             same layout principles as for other applications areas.
             DialogBoxes are usually transitory.  The user usually
             wants to simply respond and get back to the primary
             tasks of the application.  To help the user respond
             quickly, there are a number of common DialogBox
             actions.  By using and ordering these actions
             consistently, you provide the user with cues to quickly
             respond to each DialogBox.

             When a DialogBox is displayed, all components within
             the DialogBox should reflect the current state of the
             application.  For example, if the DialogBox is used for
             changing the current font in a text editor, the
             DialogBox should be initially displayed with the
             current font.  If the DialogBox is modeless, then any
             changes to the application should be updated in the
             DialogBox.

             DialogBoxes can limit how a user can interact with
             other windows in order to force the order of
             interaction.  These limitations, which are called
             modes, are described in the following text.

             MMooddeelleessss          Allows interaction with the secondary
                               window and all other windows.

             PPrriimmaarryy mmooddaall     Does not allow interaction with any
                               ancestor of the window.

             AApppplliiccaattiioonn mmooddaall Does not allow interaction with any
                               window created by the same
                               application even if the application
                               has multiple primary windows.

             SSyysstteemm mmooddaall      Does not allow interaction with any
                               window on the screen.  This includes
                               windows from all other applications
                               and any icon box.  To indicate a
                               system modal secondary window, the
                               pointer should change shape to a
                               caution pointer whenever it leaves
                               the system modal secondary window.

             Remember that the guidelines presented in this section,
             like all the guidelines in this guide, apply only in a
             left-to-right language environment in an English-
             language locale.  You need to make the appropriate




        6-44                                         August 26, 1994







                                       Application Design Principles


             changes for other locales.



        6.2.4.1  CCoommmmoonn DDiiaallooggBBooxx AAccttiioonnss



             While your application can sometimes require special
             DialogBox actions, most share common actions.  The
             common actions provide a consistent means for the user
             to quickly respond to DialogBoxes and get back to the
             primary application tasks.  The common actions should
             be presented in a horizontal collection of PushButtons
             at the bottom of the DialogBox, separated from the rest
             of the DialogBox by a Separator.

             No DialogBox will contain all of the common actions in
             the following list.  You should use the ones
             appropriate to your application or determine new
             actions so they do not conflict with the common actions
             listed.  If you create a new action, you should give it
             an active-voice label that indicates its purpose.  An
             active-voice label describes the action that pressing
             the button causes.  The actions are listed in the
             approximate sequence in which they should appear in
             DialogBoxes as follows:

             YYeess    Must indicate an affirmative response to a        *
                    question posed in the DialogBox and then close    *
                    the window.  While YYeess is not an active-voice
                    label, it implies a positive response to a
                    question in a QuestionDialog or a WarningDialog.
                    Only use YYeess if it is a clear answer to the
                    question.

             NNoo     Must indicate a negative response to a question   *
                    posed in the DialogBox and then close the         *
                    window.  While NNoo is not an active-voice label,
                    it implies a negative response to a question in
                    a QuestionDialog.  Only use NNoo if it is a clear
                    answer to the question.

             OOKK     Must cause the application to apply any changes   *
                    and perform related actions specified by the      *
                    components in the DialogBox and then dismiss the  *
                    DialogBox.  While OOKK is not an active-voice
                    label, its usage is too common to change.

             CClloossee  Should cause the current DialogBox to be closed
                    without performing any of the actions specified




        August 26, 1994                                         6-45







        OSF/Motif Style Guide


                    by the components in the DialogBox.  This action
                    is usually only available in a DialogBox that
                    provides status information, such as a
                    WorkingDialog.  This Label can also be used if
                    the actions in the DialogBox cannot be reversed,
                    in which case this Label replaces CCaanncceell after
                    the first irreversible action is performed.

             AAppppllyy  Must apply any changes and perform related        *
                    actions specified by the components in the        *
                    DialogBox.

             RReettrryy  Must cause the task in progress to be attempted   *
                    again.  This action is commonly found in message
                    boxes that report an error.

             SSttoopp   Must end the task in progress at the next         *
                    possible breaking point.  This action is
                    commonly found in a WorkingDialog.

             PPaauussee  Must cause the task in progress to pause.  This   *
                    action is commonly found in a WorkingDialog and
                    should be used in combination with RReessuummee.

             RReessuummee Must cause a task that has previously paused to   *
                    resume.  This action is commonly found in a
                    WorkingDialog and should be used in combination
                    with PPaauussee.

             RReesseett  Must cancel any user changes that have not been   *
                    applied to the application.  It must also reset   *
                    the status of the DialogBox to the state since    *
                    the last time the DialogBox action was applied    *
                    or to the initial state of the DialogBox.

             CCaanncceell Must close the DialogBox without performing any   *
                    DialogBox actions not yet applied to the          *
                    application.  Pressing <<CCaanncceell>> anywhere in the   *
                    DialogBox, except during a cancelable drag        *
                    operation, must perform the action of this        *
                    button.

             HHeellpp   Must provide any help for the DialogBox.          *

             If a DialogBox action causes an error, the DialogBox
             should not be dismissed before the error is displayed.
             Instead, the DialogBox should remain available after
             the error is dismissed to give the user a chance to
             correct the error and reuse the DialogBox.  If the
             actions to be performed by OOKK or AAppppllyy depend on the
             state, then these Labels should be replaced by ones




        6-46                                         August 26, 1994







                                       Application Design Principles


             that indicate the action to be performed.



        6.2.4.2  AArrrraannggiinngg CCoommmmoonn AAccttiioonnss


             You should arrange PushButton actions in DialogBoxes in
             the same way you arrange other PushButtons, according
             to order and frequency of use.  The common action
             PushButtons should be ordered as presented in the
             previous section.  Positive responses to the DialogBox
             should be presented first, followed by negative
             responses, and canceling responses.  HHeellpp should always
             be the last action on the right.

             The following rules should be used when determining
             what default buttons to place in a DialogBox:

                +o Modal DialogBoxes should use one of the following
                  button arrangements unless superseded by another
                  rule:

                  OOKK CCaanncceell
                  OOKK CCaanncceell HHeellpp

                +o Modeless DialogBoxes should use one of the
                  following button arrangements unless superseded by
                  another rule:

                  OOKK AAppppllyy CCaanncceell
                  OOKK AAppppllyy CCaanncceell HHeellpp
                  OOKK AAppppllyy RReesseett CCaanncceell
                  OOKK AAppppllyy RReesseett CCaanncceell HHeellpp

                +o Information DialogBoxes should use one of the
                  following button arrangements:

                  OOKK
                  OOKK HHeellpp

                +o Question DialogBoxes should use one of the
                  following button arrangements:

                  YYeess NNoo
                  YYeess NNoo HHeellpp

                  It is possible that both the YYeess and NNoo actions of
                  a Question DialogBox will perform an action.  If
                  this is the case, the Question DialogBox should
                  use one of the following button arrangements:




        August 26, 1994                                         6-47







        OSF/Motif Style Guide


                  YYeess NNoo CCaanncceell
                  YYeess NNoo CCaanncceell HHeellpp

                +o Warning DialogBoxes should use one of the
                  following button arrangements:

                  YYeess NNoo
                  YYeess NNoo HHeellpp
                  OOKK CCaanncceell
                  OOKK CCaanncceell HHeellpp

                +o Working DialogBoxes should contain any of the
                  following sets of buttons in order:

                  CClloossee
                  CCaanncceell or SSttoopp
                  PPaauussee RReessuummee
                  HHeellpp



        6.2.4.3  DDeetteerrmmiinniinngg DDiiaallooggBBooxx LLooccaattiioonn aanndd SSiizzee


             Your application determines the size and location of
             its DialogBoxes.  You should size and place DialogBoxes
             so that they do not obscure important information in
             other windows of your application.  The initial size of
             a DialogBox should be large enough to contain the
             dialog components without crowding or visual confusion,
             but otherwise should be as small as possible.
             DialogBoxes should follow the same rules for resizing
             as a MainWindow as described in Section 6.2.2.3.

             You should place DialogBoxes on the screen so they are
             completely visible.

             In general, you should place DialogBoxes close to
             either the component that caused it to be displayed,
             the current action, or the information needed to
             respond to it.  When a DialogBox relates to an item in
             an underlying window, you should position the DialogBox
             to the right of the item.  If there is not enough room
             to the right of the item, try to position the DialogBox
             to the left, below or above the item, in that order,
             depending on screen space available.  You should only
             obscure related information as a last resort.

             If a DialogBox does not relate to items in the
             underlying windows, the DialogBox should be placed
             centered in the application's work area.




        6-48                                         August 26, 1994







                                       Application Design Principles


             If two DialogBoxes need to overlap, you should offset
             the top DialogBox to the right and below the title of
             the lower DialogBox.  Use your best judgement, knowing
             that the screen area for DialogBoxes is limited.

             While the previous suggestions seem simple enough, they
             cannot always be followed completely.  Therefore,
             DialogBoxes, once displayed, should be movable so that
             the user can relocate them as needed to see information
             in underlying windows.



        6.2.5  DDeessiiggnniinngg DDrraagg aanndd DDrroopp



             By default, applications allow the user to drag text
             from just about everywhere and drop it into any
             writable Text component.  If you want to use the
             features of drag and drop to and from other components
             in your application, you need to design these features
             into your application.

             The most important decision you need to make in
             designing drag and drop into your applications is which
             elements you want to make draggable and which
             components you want to allow drops onto.  When making
             this decision, keep in mind that drag and drop not only
             transfers data within an application but also between
             applications.  Therefore you need to consider the
             impact of unfamiliar data being dropped into your
             application, and in which formats you want to allow
             your own application's data to be transferred out.  The
             following subsections discuss the following other
             application considerations when designing drag and drop
             into your application:

                +o Drag icon design

                +o Drag source effects

                +o Drag-under effects

                +o Providing help on drop sites

                +o Determining transfer formats

                +o Indicating drop failure






        August 26, 1994                                         6-49







        OSF/Motif Style Guide


        6.2.5.1  DDrraagg IIccoonn DDeessiiggnn



             At the start of a drag operation, the pointer is
             replaced with a drag icon.  The drag icon is defined by
             the application for each draggable element and can be
             composed of the following:

                +o A source indicator

                +o An operation indicator

                +o A state indicator

             The source indicator should give a visual
             representation of the primary data type of the
             draggable element; for example, horizontal lines in a
             rectangle for representing text or a color palette for
             representing a color tool.  All drag icons must include  *
             a source indicator.  Figure 6-15 shows move, copy, and
             link drag icons for graphics and textual information.

                            FFiigguurree 66--1155..  Drag Icons

             The operation indicator shows whether a drop will
             result in a move, copy, or link of the transferred
             data.  Most drag icons should include an operation
             indicator, but an operation indicator should only be
             included in the drag icon when the result of the drop
             operation is a data transfer.  The operation indicator
             can be shown either as a separate element of the drag
             icon or as a variation of the graphic used for the
             source indicator.

             The state indicator shows whether the current pointer
             location is over a valid drop site for the dragged
             elements.  The state indicator can show three different
             states:

                +o Valid drop site - The hotspot of the drag icon is
                  over a valid drop site for the data the user is
                  dragging.  A drop at this point usually results in
                  a successful transfer.

                +o Invalid drop site - The hotspot of the drag icon
                  is over a drop site, but the data the user is
                  dragging is not compatible with the drop site.  A
                  drop at this point results in a failed transfer.






        6-50                                         August 26, 1994







                                       Application Design Principles


                +o No drop site - The hotspot of the drag icon is not
                  over a drop site.  A drop at this point results in
                  a failed transfer.

             All drag icons can include a state indicator.  The
             state indicator should be coincident with the hotspot
             of the pointer.  The state indicator can be a separate
             element in the drag icon or a change in the visual
             representation of the drag source.

             When defining new drag icons for your application, you
             should follow the same rules as for defining any other
             new pointers described in Section 2.2.2.



        6.2.5.2  DDrraagg SSoouurrccee EEffffeeccttss



             The source of the dragged elements can also provide
             visual indications of the result of a drop.  For
             example, if the default operation for the dragged
             elements is a move, the source can be hidden or
             deemphasized; or, if the default operation of the
             dragged elements is a link, a line can be drawn from
             the source to the pointer.



        6.2.5.3  DDrraagg--UUnnddeerr EEffffeeccttss



             A drag-under effect is a change to the visual state of
             a possible valid drop site when the drag icon pointer
             is over the drop site.  All drop sites should use some
             kind of drag-under effect.  Drop sites can use a solid
             line around the site, or a raised or lowered beveled
             edge around the drop site, as a drag-under effect.
             Drop sites can also change any visual component of the
             drop site, or even animate those changes, as a drag-
             under effect.  For example, an icon representing a
             folder might show an animated image of the folder
             opening as a user drags a file onto it.










        August 26, 1994                                         6-51







        OSF/Motif Style Guide


        6.2.5.4  PPrroovviiddiinngg HHeellpp oonn DDrroopp SSiitteess



             Help on drag and drop operations should be provided by
             the drop site under the drag icon pointer at the time
             help is requested.  If a drop site gets a help request
             during a drag and drop operation, the drop site
             application should post a DialogBox with help
             information about the results of a drop at that
             location and the choices for the completion of the drag
             and drop operation.  The DialogBox should allow for
             canceling the drag and drop operation or dropping the
             elements at the current location as a move, copy, or
             link.

             The drag and drop help DialogBox should be an
             Information DialogBox with a message describing the
             possible results of a drop at that location.  The first
             button in the row of buttons at the bottom of the
             DialogBox should contain the default transfer option
             (MMoovvee, CCooppyy, or LLiinnkk) or OOKK for the single transfer
             action described in the text of the DialogBox.  If the
             user has not specified a transfer option using modifier
             keys, and more than one is possible, then:

                +o If there is a valid move transfer option, the
                  DialogBox should contain the move transfer option
                  on a button labeled MMoovvee.

                +o If there is a valid copy transfer option, the
                  DialogBox should contain the copy transfer option
                  on a button labeled CCooppyy.

                +o If there is a valid link transfer option, the
                  DialogBox should contain the link transfer option
                  on a button labeled LLiinnkk.

                +o The DialogBox should not include an OOKK button.

             Drag and drop help DialogBoxes must contain a CCaanncceell     *
             button for canceling the drag and drop operation in      *
             progress.  The DialogBox can contain a HHeellpp button for
             providing further help on the DialogBox actions.











        6-52                                         August 26, 1994







                                       Application Design Principles


        6.2.5.5  DDeetteerrmmiinniinngg TTrraannssffeerr FFoorrmmaattss



             After a drop operation, the application containing the
             drop site determines the best format to use to transfer
             the data, based on the data types that the drag source
             can send.  The drop site can use any heuristic to
             determine this format.

             If multiple transfer formats (in the case of links,
             multiple view formats) are acceptable in the drop site,
             the drop site application should let the user choose
             the correct transfer format either through a
             customization feature or through a DialogBox that lists
             the possible choices.  The DialogBox should be a
             Question DialogBox asking the user to choose the best
             transfer format.  The DialogBox must provide a choice    *
             of available transfer formats.  The choice can be
             provided as a row of buttons along the bottom of the
             DialogBox, or in a RadioBox within the QuestionDialog.   *
             Using either method, there must be a CCaanncceell button in    *
             the bottom row of buttons in the DialogBox.  The
             DialogBox can also include a HHeellpp button that provides
             help on the results of a drop at the current location.
             If the DialogBox uses a RadioBox to present the format
             choices, the most likely format should be first and
             initially selected, formats that are currently invalid
             should be set insensitive, and the DialogBox must        *
             include an OOKK button in the bottom row of buttons for    *
             accepting the RadioBox choice.  A Popup Menu can be
             used instead of a DialogBox to let the user choose the
             format.



        6.2.5.6  IInnddiiccaattiinngg DDrroopp FFaaiilluurreess



             In most cases, the system indicates drop failure
             automatically.  If your application allows partial
             success on transfers, it should post messages about
             partial failure that provide enough information for the
             user to recover from the failures.










        August 26, 1994                                         6-53







        OSF/Motif Style Guide


        6.3  IInntteerraaccttiioonn


             This section gives guidelines for creating applications
             with consistent interactions.  When an application
             behaves as expected and the user is not surprised by
             the results of the actions, the user can complete tasks
             quicker.  The following subsections present the
             following guidelines for good application interaction:

                +o Suppling indications of actions

                +o Providing feedback

                +o Allowing user flexibility



        6.3.1  SSuuppppllyyiinngg IInnddiiccaattiioonnss ooff AAccttiioonnss


             The first step to consistent interaction is to provide
             cues to the result of every action.  This means that
             actions of components should be indicated by the
             component's shape, label, and graphics.  It also means
             that the actions and interactions of components should
             remain consistent, so the user always knows what to
             expect.

             Lastly, it means that interactions should be simple.
             As interactions become complicated, it also becomes
             difficult to visually represent the interaction.
             Complicated interactions and components create the
             possibility for more errors.  Even the most complicated
             concepts can be clarified by careful organization, so,
             if your application's interactions seem complicated,
             consider reorganizing them for simplicity.



        6.3.1.1  UUssiinngg CCoommmmoonn CCoommppoonneennttss


             Users expect components to behave consistently across
             all applications.  PushButtons always perform an
             action.  OptionButtons always provide selections.
             Because of this, when users want to perform an action,
             they look for a PushButton, usually in a Menu.  They do
             not look for an OptionButton.  You should use the






        6-54                                         August 26, 1994







                                       Application Design Principles


             components that are provided when appropriate, rather
             than create new ones.  You should not alter the look of
             a component so drastically that its type is
             unrecognizable.



        6.3.1.2  UUssiinngg IInnttuuiittiivvee LLaabbeellss


             One of the best indicators of the action of a component
             is its Label.  The Label can be either text or a
             graphic.  You should choose your Labels carefully to
             indicate the action of each component.

             Components that perform actions should be labeled with
             active verbs.  Components that present options should
             be labeled with nouns.  You should also label component
             groups, including Panels, with nouns to indicate the
             contents of the group.

             Consider the use of graphics as Labels with two
             cautions.  Graphic Labels cannot be nouns or active
             verbs, so choose a graphic whose meaning is clear in
             the context of the component.  Also remember that,
             while graphic symbols are very language independent,
             they can be highly culture specific.  In some cultures,
             a mailbox graphic can indicate a mailer action; but,
             since mailboxes are not common in all cultures, an
             envelope graphic may be better, or you can provide a
             mechanism for changing the graphic based on the locale.



        6.3.1.3  UUssiinngg GGrraapphhiiccss ttoo SShhooww AAccttiioonn


             Many components also include a small graphic symbol
             following the Label to indicate the action of the
             component.  CascadeButtons should use an arrow graphic
             that points in the direction the cascading Menu will
             appear.  OptionButtons should use a rectangle graphic
             to distinguish them from PushButtons.

             Any component that needs more information to complete
             its action should include an ellipsis following the
             Label.  This additional information should be requested
             in a DialogBox.  The ellipsis should not be used to
             indicate that the component will post a DialogBox.  The
             ellipsis should be included only if the purpose of the
             DialogBox is to gather more information needed to




        August 26, 1994                                         6-55







        OSF/Motif Style Guide


             complete the requested task.  For example, the Menu
             choice PPrriinntt would use an ellipsis if a DialogBox is
             posted requesting print characteristics prior to the
             printing action, but the Menu choice HHeellpp would not use
             an ellipsis even though the help information is
             presented in a DialogBox.

             All previously mentioned graphics should follow the
             text or graphic of the Label.  In left-to-right
             language environments, the graphic should be on the
             right.  In right-to-left language environments, the
             graphic should be on the left.  Note that the graphic
             indicating the state of a ToggleButton precedes the
             Label in a left-to-right language environment.



        6.3.1.4  SShhoowwiinngg DDeeffaauulltt AAccttiioonnss


             Your application should use default values for common
             settings or obvious selections.  Default values should
             be shown in the on state.  For example, the default
             value for a Text area should be in the Text area in the
             selected state whenever text entry is requested; the
             default selection in a List should be set in the
             selected state whenever a list selection is requested;
             or the default RadioButton should be filled in a Panel
             at application start-up time.  In any case, once the
             state is changed, the new state should take the place
             of the default until the state is reset.  Your
             application can decide whether to save its state after
             being closed.

             Groups of controls, such as a DialogBox, can also have
             a default action.  The default action is usually
             activated by pressing <<EEnntteerr>> or <<RReettuurrnn>>.  The default
             action of a component group should be distinguished
             from the other selections by an extra border as shown
             in Figure 6-16.















        6-56                                         August 26, 1994







                                       Application Design Principles


                       FFiigguurree 66--1166..  A Default PushButton

             The OOKK PushButton should be the default PushButton in
             modal DialogBoxes and modeless DialogBoxes that are
             transient.  The AAppppllyy PushButton should be the default
             PushButton in a modeless DialogBox that is likely to be
             displayed for multiple actions.

             Using the keyboard to navigate through the PushButtons,
             the button with the location cursor should become the
             default PushButton.  This ensures that pressing <<EEnntteerr>>
             or <<RReettuurrnn>> over a PushButton invokes the correct
             PushButton.  When the location cursor leaves the
             PushButtons, the original default button should once
             again become the default.



        6.3.1.5  AAvvooiiddiinngg CCoommppoonneenntt MMooddeess


             A component has modes when its action changes based on
             some previous action or the state of the application.
             This is very confusing to the user, who was expecting
             the original action of the component.  Components in
             your application should not have modes.  Your
             application should use multiple components rather than
             modal components.



        6.3.1.6  SShhoowwiinngg UUnnaavvaaiillaabbllee CCoommppoonneennttss


             As the state of your application changes, certain
             components become inappropriate.  For example, the
             MMiinniimmiizzee selection in a window Menu is inappropriate
             when the window is already minimized.  In such cases,
             you should make the inappropriate components
             unavailable.  This is also called _d_i_s_a_b_l_i_n_g the
             components.  Disabled components should be visually
             deemphasized, usually by graying the Label of the
             component.

             You should not remove unavailable components from the
             application client areas.  The components should remain
             visible to remind the user of their existence and to
             ensure application consistency.  Figure 6-17 shows a
             disabled Menu element.






        August 26, 1994                                         6-57







        OSF/Motif Style Guide


                     FFiigguurree 66--1177..  A Disabled Menu Element

             You should disable Menu items and components to help
             avoid errors.  In general, you should disable the
             lowest level component that results in an irreversible
             error state.  For example, consider a graphics editor
             that has a DialogBox that is used for aligning selected
             graphics objects.  If the user might want to see the
             choices in the DialogBox even if the choices are not
             available, this DialogBox should be displayable at all
             times; its Menu item should not be disabled.  If there
             are no graphics objects to align, the DialogBox should
             still be displayed, but its OOKK and AAppppllyy buttons should
             be disabled.  Once graphics objects are selected, the
             OOKK and AAppppllyy buttons should become enabled.

             Menu items that are inappropriate and that result in
             error messages should be disabled.  Some examples are
             the EEddiitt Menu's CCuutt and CCooppyy actions when nothing is
             selected.  The EEddiitt Menu's UUnnddoo entry should be
             disabled if the last operation cannot be undone.

             Menu items that perform no action need not be disabled.
             For example, the NNeeww entry in the FFiillee Menu need not be
             disabled immediately after it is invoked.  It can be
             selectable repeatedly, even though it performs no new
             action, because it does not result in an error state.

             A Menu item that displays a modal DialogBox should be
             disabled if it would cause an error either on display
             of the box, or on clicking the OOKK or AAppppllyy buttons in
             the DialogBox.  Since the DialogBox is modal, nothing
             can be changed in the application to correct the error
             until the box is dismissed, and it should not be
             displayable until the application is in a state that
             makes the action of the DialogBox possible.

             Menu items that display modeless DialogBoxes should
             never be disabled.  If a box is modeless, the user can
             change the state of the application at any time to make
             the DialogBox useful.  If the action cannot be
             completed because some necessary information is not yet
             available, then the OOKK and AAppppllyy buttons should be
             disabled.

             After a TearOff Menu is torn off, an application can
             disable elements that are not appropriate in the torn
             off state.  Elements in a torn off Menu can be disabled
             in the same manner as elements in any other Menu or
             DialogBox.





        6-58                                         August 26, 1994







                                       Application Design Principles


             You should avoid frequently disabling and enabling
             components in situations where the state change would
             cause a distracting flashing.  For example, editing a
             Text component in a DialogBox can cause some buttons to
             be inappropriate at each invalid text value.  In this
             case, you should display an error message if the OOKK or
             AAppppllyy button is clicked for an inappropriate text
             value.  Of course, the error message should explain the
             valid text values.



        6.3.2  PPrroovviiddiinngg FFeeeeddbbaacckk


             Another important element to user interaction is
             providing feedback about the current state of the
             application.  This is done, as described in the
             previous section, by using labels and graphics and by
             keeping the interface consistent.  Your application
             should also dynamically indicate the state of the
             application's actions.  For example, the mouse pointer
             shape changes to indicate when and where special
             actions can occur.  Chapter 2 describes mouse pointer
             shapes in detail.  Other ways to provide the user
             feedback are described in the following subsections.



        6.3.2.1  SShhoowwiinngg PPrrooggrreessss


             If an action takes a long time to complete, the user
             may mistake the delay to mean that the system or the
             application stopped working.  For actions that take a
             long time to complete, your application should indicate
             that there will be a delay with a WorkingDialog.  If
             your application can track the progress of long
             actions, it should try to update the WorkingDialog with
             the progress of the action.



        6.3.2.2  PPrroovviiddiinngg WWaarrnniinnggss


             Certain actions can cause destructive results, such as
             closing an application before saving changes in the
             current file.  Applications should not disallow such
             destructive actions; instead, they should warn the user
             of the consequences with a WarningDialog.  The           *




        August 26, 1994                                         6-59







        OSF/Motif Style Guide


             WarningDialog must allow the user to cancel the          *
             destructive action.  Note that too many WarningDialogs
             can be disruptive to the user's main task.
             WarningDialogs should be reserved for truly destructive
             actions.  For destructive actions that can easily be
             recovered, applications should provide undo actions to
             reverse them; for example, the UUnnddoo element of the EEddiitt
             Pulldown Menu.



        6.3.2.3  PPrroovviiddiinngg HHeellpp


             Even in the most intuitive application, the purpose of
             a component or the way to do a task can be hard to
             figure out for a new user.  Your application should
             provide a help mechanism for all of its aspects.
             Sections 6.2.1.5 and 6.2.1.5.3 describe the most common
             base for a help mechanism, the HHeellpp Pulldown Menu on
             the MenuBar.  Context-sensitive help should also be
             available by using <<HHeellpp>>.



        6.3.3  AAlllloowwiinngg UUsseerr FFlleexxiibbiilliittyy


             Good user-application interaction should also allow
             user flexibility.  No matter how well your application
             is designed, some users will not like parts of it.
             They will want to change some elements of it; for
             example, from simple elements like the colors and fonts
             to complicated elements like the default values.  You
             should allow users to adjust elements of your
             applications because it increases their sense of
             control over the applications.  You should consider the
             following attributes of your applications for user
             customization:

                +o Application parameters

                +o Colors

                +o Fonts

                +o Default values

                +o Key bindings






        6-60                                         August 26, 1994







                                       Application Design Principles


                +o Labels

                +o Messages

                +o Help information

             The exact list of attributes you should allow the user
             to customize depends on your application.



        6.4  CCoommppoonneenntt DDeessiiggnn


             For consistency with other applications, you should
             always try to use existing components for your
             application tasks, but there are cases where new
             components are needed.  In designing new components,
             you should follow the same rules as application
             designers follow.  You should think of components as
             small applications.  They perform a task, present
             information to the user, and take information from the
             user.  New components must follow the guidelines for     *
             designing applications.

             The first step to designing a new component is to
             compare its features with those of the other
             components.  If the new component has a feature that is
             the same as another component, the mechanisms for using
             the feature, layout, key bindings, graphics, and so on,
             should be the same in the new component.  You should
             also try to match the appearance style of components on
             your system.  Most OSF/Motif compliant systems use a
             3-dimensional beveled presentation style.  Appearance
             is not specified as a matter of component style in this
             guide; however, any new components will assimilate
             better with existing components if they are designed to
             conform to the implied appearance style for the system
             on which they will be used.
















        August 26, 1994                                         6-61





 
