ICCS.TA.100 - User Interface Style Definition
OMG = Oracle Method Guideline
OMS = Oracle Method Standard

Button Toolbar
OMS-58168: Dynamically enable and disable the toolbar buttons context sensitively.
Rationale In this way it is obvious which functions are available.

Window Management
Closing Non-modal Windows
OMS-58147: A user closes a non-modal window, with the native GUI close mechanism. Do not provide 'Close' or 'Dismiss' buttons in any non-modal windows.
Rationale This is in accordance with standard UI conventions.

OMS-58148: Only dialog (modal) windows are closed automatically within the form. The user invokes this action by pressing a button, such as 'OK', 'Cancel' or 'Done'.
Rationale This is in accordance with standard UI convention.

OMS-58149: Closing a window does not force a commit of the data contained in it. It merely means do not show this information right now.
Rationale User should remain in control of what is happening, and therefore explicitly commit the data.

Modal Window
OMS-58034: A modal window must at least contain an OK-button (or language equivalent). Choose one of the following button combinations:
Buttons Usage
OK & Cancel OK closes the window. In some cases, it may perform a commit as well (see 'Implicit Commits'). Cancel clears the data without asking for confirmation,, and closes the window. Note that usually only very simple modal windows can be modeled this way, and Save, Clear, etc. must be disabled.
OK Closes a window. Typically used for a window that is display only.
OK, Apply & Cancel OK closes the window and applies the changes. Apply processes the data, but does not close the window. Cancel closes the window, and clears any pending changes since the last Apply.
Rationale This is according to standard UI conventions.

About Window
OMS-60051: Create an About window with at least the following information:
  • application name and version
  • copyright message
  • module or file name
  • module version
  • user name
  • database connect information
Rationale This information is useful during testing and support. This information should not be put into the header lines of the form. This consumes too much space, and is not useful end user information.

OMS-60052: The About window must be a modal dialog window.
Rationale This is according to standard UI conventions.

Block Layout
OMS-58004: When showing only one block in a window, do not provide a block border.
Rationale A block border consumes too much space unnecessarily

Form Generator: This is governed by the BLKDEC preference.
OMS-58049: Always use a vertical scrollbar in multi-row blocks (preference BLKVSB), and never in a single-row block.
Rationale A scrollbar clearly indicates that one is dealing with a multi-row block, and indicates when there are more rows than are visible.

Exception: Only in multi-row blocks where the number of records never exceeds the number of displayed records, you may choose not to include a vertical scroll bar.
OMS-60042: Position the scrollbar to the right of the block data (preference BLKSBP).
Rationale This is according to standard UI conventions.

Block Specific Buttons
OMS-58112: Buttons within a window should be sized similarly and spaced consistently.
Rationale This provides a consistent look and feel throughout the application.

Form Generator: The sizing of buttons is governed by the preference AIBBWD (Action Item Button Width).
Navigation within a Form
OMS-60055: Validation of required items is performed upon leaving the record.
Rationale This ensures that the end user can remain in control of their activities.

Block Navigation
OMS-60054: Always provide a button to navigate to a detail block if the detail block is rendered in another window.
Rationale This is the most intuitive way to point out to the user that it is possible to navigate to another window.

Forward Navigation from Last Item
OMS-58140: When the user performs forward navigation from the last item of a block, then in a single-row block, the behavior is dependent upon where detail blocks are rendered:
  • if any detail block is rendered in the same window, then the cursor moves into the first detail block (change_block)
  • if no detail block is rendered in the same window, the cursor moves to the first field of the current record (same_record)
Rationale A window is a logical unit, so therefore the cursor should always remain within the window unless the user performs a specific navigation action to move out of the window.

OMS-58527: When the user performs forward navigation from the last item of a block, then in a multi-row block, the behavior is always change_record. That is, the cursor moves to the first item of the next record.
Rationale This makes it more intuitive for the user. It also makes it easier for the user to navigate through the records of the form.

Previous Navigation from First Item
OMS-58141: When the user performs previous navigation from the first item of a block, then the behavior is dictated by the Forward navigation requirement. No concession is made to optimize the behavior of "previous" navigation.
Rationale This is the reverse of the behavior described in standards OMS-58527 and OMS-58140. This is what a user would predict to happen.

Fonts
OMS-60045: Items that currently are display-only should be shown with a canvas-gray background. For items with insert allowed and update not allowed, the background color should dynamically change to canvas-gray as soon as the row is committed.
Rationale This provides a visual indication on what kind of actions are not allowed for the individual items. This increases the usability of the application.

Generation: If you use Headstart Oracle Designer you get this functionality by default.
Menu Design
OMS-60059: Use the DO_KEY built-in for menu entries replicating standard Forms function.
Rationale This ensures that the functionality of the menu entry and corresponding function key is the same.

Message Handling
OMS-58176: Error messages are shown in a modal dialog window (for example, native Forms alert box) with a stop sign, the message text, and the OK button.
Rationale It makes it clear to the user an error has occurred, and forces the user to perform an action before continuing.

OMS-58177: If warning messages are shown in a pop-up window, the window must include at least two buttons:
- a Cancel button that causes processing to be halted,
- and a Continue button that does not stop processing.
Rationale In this way the decision is with the user whether to continue or halt the operation.

Application Systems
OMS-61569: Do not use the Form Generator preference Text item default date format (TXTDDF) nor the Form Generator preference Text item default DATETIME format (TXTDTF). Make these preferences empty (override the default values).
Rationale This makes it possible to alter the date or datetime format without the need to generate the forms again, and to set the date(time) format dynamically, by using date related variables.
Use the following runtime registry settings for Forms:
  • forms60_output_date_format
  • forms60_user_date_format
  • forms60_output_datetime_format
  • forms60_user_datetime_format
  • nls_date_format
If a forms date item is generated without a format, at runtime it uses the format setting forms60_output_date_format or forms60_user_date_format. If these are not set, it uses nls_date_format.
Because of this dynamic setup, changing the date format is simply changing the registry variable.

Form Generator: You can find these preferences at Application level, under Layout - Text item. You can override them in two ways:
  • specifying an empty value at Application level
  • specifying an empty value in a Preference Set, and linking that Preference Set at Application level
Warning: This only works if you also comply to OMS-61627.