2.10. Graphical User Interface Details

This section of the requirements covers details of the Rolodex Tool graphical user interface (GUI) not fully addressed in preceding sections. Some aspects of the GUI may differ in different operating environments. Such differences are addressed below.

2.10.1. Persistent Display States

When the user selects a command from the Rolodex menu, the system updates the display to the appropriate dialog for the command. When the system displays a dialog, the state of the dialog is the same as when it was most recently previously displayed. Specifically, the contents of the dialog text boxes are those most recently typed by the user. For example, suppose the user executes the following actions:

  1. choose Rolodex->Add
  2. enter some values in the card fields, with or without pressing OK
  3. choose Rolodex->Find
  4. enter a name to find and press OK
  5. choose Rolodex->Add again
At this point, the display shows the add-card dialog with the contents of the text boxes as entered in step b. If the user then proceeds to choose Rolodex->Find again, the display shows the find-card dialog with the text box containing the name entered in step d.

2.10.2. Disabling and Enabling Interface Elements

In all of the preceding scenarios, active interface elements are drawn with solid black outlines, without distinguishing between an enabled versus disabled state. In many operating environments, an interface element can be shown in a disabled state, typically by drawing it in a shade of grey. An interface element is shown as disabled when the current state of the system renders the element unusable. For example, the File->Save menu item can be shown as disabled when there is no currently open file or when the current file does not require saving.

The requirements given in this document do not explicitly define when an interface element is enabled or disabled. Rather, the requirements define when a user-invoked command has no effect. These "no effect" cases are equivalent to defining an interface element to be disabled. That is, when conditions exist such that a command has no effect, then the interface element that is used to invoke that command can be defined as disabled. Based on this definition, implementors may choose to display interface elements in a disabled state when the system state is such that activating the elements has no effect. The display of disabled interface elements must be consistent for all interface elements. That is, visual enabled/disabled cuing must be used consistently for all interface elements, or for no interface elements at all.

2.10.3. Fonts and Colors

In all of the preceding scenarios, a 12-point Courier font is used for text and all interface elements are drawn in black and white. In some operating environments, the user is able to change the font properties and coloring used in an application program. Where this is possible, such changes can be made in the Rolodex Tool. The following font and color properties are required of any implementation:

  1. the relative size of text must be retained; i.e., the font size may not differ across display windows;
  2. the distinction between bold face and normal face font must be as shown in the interface scenarios;
  3. the default pen color for text and lines must be black, or a dark-shaded color consistent with the conventions of the operating environment in which the Rolodex Tool is running;
  4. the default background color for all screens must be white, or a light-shaded color consistent with the conventions of the operating environment.

2.10.4. General Look-and-Feel Issues

In all of the preceding scenarios, interface elements are shown in a plain and simple style. In many operating environments, interface elements are drawn with graphical shading and other forms of graphical embellishment to render them more visually useful and appealing to the user. Implementors may follow the look-and-feel conventions of a particular operating environment for the Rolodex Tool interface. However, the fundamental operational character of the specified interface elements must be implemented as shown in the requirements scenarios. Specifically:

  1. the top-level commands must be presented in a menubar and menus;
  2. all command buttons must be labeled and justified as shown;
  3. all text labels must be spelled, capitalized, and justified as shown;
  4. horizontal and vertical text scrollbars must be available as shown (but scrollbars may be removed when not needed).

2.10.5. Help Interface

Some operating environments provide a standard means for users to access quick help or a form of help that is essentially the same as quick help. Viz., it is a very brief text string associated with a particular region of the screen, most typically a region of the screen with which the user interacts. Implementors may follow the conventions of a particular operating environment for the precise format and position of the GUI elements in which the quick help text is displayed.

The following are required aspects of quick help in any implementation:

  1. the quick help text defined in Appendix B.1. is delivered precisely as that text;
  2. the help is delivered in precisely those mouse contexts defined in Appendix B.1;
  3. quick help is explicitly enabled and disabled by the user.
The last of these requirements means in particular that quick help is not always on, as is the case in some popular software applications.

Detailed help delivery also differs among operating environments. Implementors may again follow environment-specific conventions for the delivery of detailed help. The following are required aspects of detailed help in any implementation:

  1. the detailed help text defined in Appendix B.2 is delivered precisely as that text;
  2. the fundamental organization of detailed help must be followed insofar as possible in any operating environment.
When the detailed help conventions of an operating environment differ substantially from those given in Section 2.7 and Appendix B, implementors must consult with the requirements team to ensure that the intent of the requirements for the help commands are met.




Prev: error-conditions | Next: [none] | Up: functional | Top: index