Motif Style

 

We have mentioned many times in this book that Motif attempts to enforce a standard style in the look and feel of its applications through the window manager and default widget actions. One of the goals of Motif is to provide the user with a consistent and easy to use set of applications. Therefore no application should deviate too far from the prescribed Motif norm. In some instances it may be necessary for the programmer to break certain Motif practices in order to achieve a desired form of user interaction. We illustrated this point when we described input to the DrawingArea widget in Chapter 17.

Motif's basic style is based on the (IBM) CUA guidelines . Motif provides many default actions for widgets that adhere to standard GUI practices as layed down by these guidelines. However, when creating widgets the programmer still has some freedom in how the GUI is constructed. For example, menus, menu bars, mouse actions and dialog can take on many different forms. In order to maintain consistency across applications Motif provides a set of guidelines that provide a framework for application development, widget designers, user interface designers and window manager designers. These guidelines are published in the Motif Style Guide . This Chapter summarises the important features in the Motif Style Guide that are relevant to the application developer.

The Motif Style Guide

 

As we have just mentioned the Motif Style Guide is a document[Ope93] that is aimed at four specific audiences: application development, widget designers, user interface designers and window manager designers. A such the guide is divided up into a number of sections. Not all sections are especially relevant for each audience. Clearly the widget designers and user interface designers will need to be familiar with a majority of the guide, however, application designers need only be familiar with three major aspects of the guide: User Interface Design Principles, Application Design Principles and Internationalisation.

Throughout this text we have already addressed many issues related to the Motif Style Guide. We now concentrate on important aspects of style related to specific widgets and general user interaction.

Menu Style

The Motif Style Guide provides many guidelines on the usage of menus in Motif. Menus are usually organised (Chapter 9) in a MenuBar   of a MainWindow widget. Motif style insists that:

• The MenuBar must be placed horizontally at the top of edge of the application just below the title area of the MainWindow window frame.
• The MenuBar must contain only CascadeButtons   with PullDownMenus connected to them  . Other classes of button inhibit menu browsing.
• Each menu in the MenuBar should have a single letter mnemonic  (Section 3.4) attached for easy keyboard selection and each mnemonic should be indicated by underlining.

Many applications have a general functionality, in which case the following general MenuBar menus should be provided with the given mnemonics (in brackets):

ile

(Meta-F) -- This menu should contain selections for performing file handling actions such as creating, opening, saving, closing and printing. It should also contain actions for handling the documents as a whole, such as quitting. The following items and mnemonics are common:

ew

(Meta-N) -- Create a new file.

pen

(Meta-O) -- Open a file. A FileSelectionDialog usually appears to allow the user to choose a file.

ave

(Meta-S) -- Save the current file to its current name.

Save s

(Meta-A) -- Save the current file to a different name

rint

(Meta-P ) -- Print the current file.

lose

(Meta-C ) -- Close the window. This option must only be supplied in applications that have multiple independent primary windows. The action must only close the current primary window and associated child windows.

Eit

(Meta-x) -- Quit the application.

elected

(Meta-S) -- This menu should contain selections for objects currently selected by the application. Many items are common with the File menu options but are specific to the selected item. Options covered by the Edit menu (below) should not be included in this menu. The Selected menu is not that commonly used.

dit

(Meta-E ) -- This menu should contain options for performing actions on the current data of the application. This menu uses Motif's keyboard accelerators  for selection of some items. Keyboard accelerators are much like mnemonics except that they are arbitrary key combinations. The control (Ctrl), Shift and Alt keys in combination with other keys are typically used and the particular key assignment model may vary depending on local computer keyboard configurations or host computer compatibility requirements. For example, Apple Macintosh computers have a different cut, paste, copy and undo accelerator model that adheres to standard Macintosh practice for these actions.

In order to set the keyboard accelerator for an appropriate menu item the resources XmNaccelerator  (String) and XmNacceleratorText  (XmString) to set the key combination and menu item label respectively. For example Ctrl<key>/ is the string used to set the XmNaccelerator resource for the Ctrl-/ key selection combination.

Common actions, with applicable keyboard accelerators or mnemonics denoted in brackets, include:

ndo

(Alt-Backspace) -- Undo the last user operation.

Cu

(Shift-Del) -- Remove the selected portion of data and store it in the clipboard . The clipboard is a Motif resource which provides a localised area of memory that allows easy transfer of data within and between applications via cut and paste actions.

opy

(Ctrl-Ins) -- Copy the selected portion of data and store it in the clipboard.

aste

(Shift-Ins) -- Copy the current contents of the clipboard to the current location.

Clar

(Meta-e) -- Remove the selected data without copying it to the clipboard. The remaining data is not compressed to the space left by this operation.

elete

(Meta-D) -- Remove the selected data without copying it to the clipboard, moving following data to fill the space left by this operation.

Select All

(Ctrl-/) -- Select all elements in current work area.

Deselect All

(Ctrl-\) -- Deselect selected items.

iew

(Meta-V) -- This menu should contain options allowing the user to change the display of data. The exact makeup of this menu will depend on the application but can include options to control the order of the displayed data, the amount of data displayed or the appearance of the data. For example, in the CDE desktop file manager you can list files by icon or by text and files may be listed in alphabetical order or by date.

ptions

(Meta-O) -- This menu should contain options allowing the user to customise the application. Once more this menu is very application dependent. One common example is providing facilities that allow the user to change the colours used by the application.

elp

(Meta-H) -- This menu should contain items that provide the user with facilities that guide and inform the user to effectively use the application. DialogBox widgets are usually used to convey the Help information. The Help menu must be placed on the far right of the MenuBar (Chapter 9).

Motif Style prescribes two acceptable models for the Help menu. One is based on providing help on various components of the application such as how to use windows, function mnemonic and accelerator keys. Tutorial information may also be specified. The other model is similar to a user manual approach providing an overview, index and tutorial information.

In addition to prescribing the organisation and formatting of menus the style guide also provides some general guidelines on menu design. Briefly these are:

• Keep menu structures simple.
• Group similar menu elements together.
• List menu items by frequency of use.
• List menu items by order use (which may be more important than frequency ordering).
• Separate destructive actions from frequently chosen items to avoid accidental selection.
• Provide keyboard mnemonics and accelerators for frequently chosen items.
• Provide tear-off menus  for  in frequently used menus (Chapter 9).

Dialog Widgets

     Applications use Dialog widgets to interact with the user. They may simply supply information to the user or may actually canvas for some input ( e.g. file selection). Applications should only display Dialog boxes when they are required. Motif provides specific Dialog widgets for specific occasions. Examples include ErrorDialog, WarningDialog, CommandDialog, PromptDialog and FileSelectionDialog widgets. The specific usage of Dialog widgets has already been addressed in Chapter 10

Drag and Drop

  

Motif provides a variety of guidelines for using its drag and drop facilities. Most of these a provided by default Motif drag and drop actions. Briefly the guidelines are:

• The middle mouse button must be used for drag and drop.
• A drag source  can support multiple operations. The user should be able to select the operation that is used. A key selection in combination with the mouse button is typically used:

  Shift

  -- selects a move operation.

  Ctrl

  -- selects a copy operation.

  Ctrl-Shift

  -- selects a link operation.

  Esc

  -- cancels a drag at any time.

  F1/Help

  -- should provide help information.

• Drag icons should be provided to indicate the three states of the drag operation:
  • A source indicator -- to indicate the primary data type for the draggable element.
  • An operation indicator -- to indicate whether a move, copy or link operation is occurring . A different icon should represent each type of operation.
  • A state indicator -- to indicate whether the a drop is valid.

Interaction

Motif also provides guidelines on creating applications with consistent interaction. If interaction is more or less uniform across applications then the user can complete basic tasks more quickly. The Motif style guidelines on user interaction are summarised as follows:

Clearly Indicate Actions

-- Interactions should be made as simple as possible. Providing intuitive visual cues is a good way to achieve this. The following principles should be adopted:

• Use common components -- Motif provides a standard appearance for every widget. Every widget also has a standard action. These should never be fundamentally altered by the program. Motif users can then associate a particular component appearance with a particular action or task.
• Use intuitive labels -- Most widget can be labelled with a piece of text or graphic. These labels should concisely convey the action of a particular task for the widget it has been assigned to.
• Use graphics to convey action -- Graphics can be used to indicate the action of a particular component. For example CascadeButtons use an arrow to point to the direction in which the menu will appear.
• Show default actions -- default values should be used for common settings or obvious selections. These values should be set by the application at start up. For example, a RadioButton selection should be set so that the default choice is highlighted when the RadioBox is initially displayed.
• Components should have single modes of operation -- the functionality of a component should not change over time in the application.
• Show unavailable components -- As the state of the application changes then certain components may become inappropriate. For example certain menu selections. In this case certain selections should be made unavailable by graying the label component (Fig. 20.1). The item should not be removed from the display however. The function XtSetSensitive(Widget, Boolean)  can be used to set a given Widget to be able to receive keyboard or mouse input and to be displayed appropriately. If the Boolean value is True then the Widget can receive input whilst if the value is False then no input can be received and the widget will appear greyed on the display.

   

  Fig. 20.1 A Disabled Menu Element

Provide Feedback

-- The user should always be informed of the current state of the application. Labels and graphics as described above provide a good means of conveying this information. Typical feedback mechanisms include:

• Showing progress -- if an actions takes some time to complete then a WorkingDialog   should be displayed. If the application can monitor the progress of the action then it should update the WorkingDialog periodically.
• Providing warnings -- Certain actions can cause destructive actions. For example closing an application before saving changes in a current file. The user should be informed of such events via a WarningDialog  .
• Providing help -- Help facilities should be provided for all aspects interaction no matter how intuitive this may appear.

Allow User Flexibility

-- The user should be allowed flexibility to adjust elements in the application. Elements that may require adjusting are widget colour, fonts, default values, application parameters, key bindings, labels, messages and even help facilities. Motif resources (Chapter ) have been especially designed to allow customisation of applications.

International Markets

As we have already mentioned in Chapter 19 the Internationalisation   of Motif has received ever increasing attention. In general many of the issues governing internationalisation are local to a particular system configuration. As we have seen the process of internationalisation can be a difficult process and any tools available to aid this process should be used. Motif provides a broad set of guidelines for the internationalisation of an application. However most of the guidelines will be dependent on the available tools and system configuration. Briefly the Motif style guidelines are as follows:

Text Input

-- Ideally international text input should be form a keyboard that can provide all the characters of the local language. In some cases a pre-edit step is needed where characters are initially typed in an then converted to another set of characters. The system and application programmers should take steps to make sure that this process is well supported and well behaved. Where some conflict or confusion arises over a specific conversion DialogBox should be used to convey the problem and list possible choices in an appropriate menu.

Country Specific Data Formats

-- Various forms of data need to supported by an application. Examples of data that varies in format across countries include numeric (thousands, millions) and decimal point separators, positive and negative values, currency, date and time formats, telephone numbers, and names and addresses.

Icons, Symbols and Pointers

-- Graphical symbols cross borders more easily than text labels. However, care may still be needed to make the graphic symbols as cross-cultural as possible.

Scanning Direction

-- Readers of western languages scan from left to right and from top to bottom. In other languages (e.g. Hebrew) readers scan from right to left. This has major implication in the location of components in menus and Dialog widgets. For example, should the help menu be placed to the far right of the MenuBar.

Modularise the Software

-- If the application software can be partitioned so that the text, input/output modules and other parts of the code are separate then the application should be easier to internationalise as individual modules can be substituted more easily.

Clear Screen Text

-- Well written screen text is far easier to understand. Screen text should be simple and brief.