295134444.

doc

Checklist for GUI Standards of Forms

S.No
1.
2.
3.
4.
5.
6.
7.

8.

9.

10.
11.

12.

13.

Name
The Module Name should match the file name.
Set First Navigation Block property of the Module to the name of the
first block that users visit when a form is run. Do not set to a WORLD
or CONTROL block.
Apply the WINDOW property class to all nonmodal windows.
The maximum allowed window size is 7.8 inches wide and 5 inches
high. Any size smaller than this is allowed, down to a minimum of
approximately two inches by two inches.
Apply the WINDOW_DIALOG_WITH_MENU property class to all modal
Windows that need access to the menu (for List of Values).
Use the WINDOW_DIALOG property class to create a modal window
with no access to the toolbar or menu.
Modal windows:
Should always open centered on the screen. They are recentered
each time they are opened.
They cannot be closed with the native GUI window close
mechanism. You must explicitly close the window in your code,
typically with the OK and Cancel buttons.
Canvasses:
You should apply the CANVAS property class to all content
canvasses.
You should size the content canvas the same as the window it is
shown in.
Stacked canvasses should use the CANVAS_STACKED property class
to enforce the correct behavior.
Canvasses Should have the following properties:
No bevels are used around the edge of the canvas.
They use the Canvas color (gray).
Use the BLOCK property class for all nonmodal blocks;
Use BLOCK_DIALOG for blocks displayed within modal windows.
Block Title:
The title should be same as the name of the object it represents.
Titles are singular if the block only displays one record and plural
when more than one record is shown.
A singlerecord block may have a plural title if the user normally
accesses more than one record during a single transaction, and
the block is not shown in a multirecord format elsewhere in the
form.
A horizontal line should be drawn across the entire width of the
content canvas to identify the block. Draw this line on the row
immediately above the block, as follows:
Thickness: 2 points
Bevel: Inset
Line Color: Black
In front of this horizontal line, the block title should display as
follows:
Background color: Canvas (gray)
Horizontal Origin: Left
Vertical Origin: Center
Horizontal Position of Origin: snapped to a grid line, 2
character cells to the right of the left edge of the canvas.
Vertical Position of Origin: snapped midway between grid lines
Alignment: Start

USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

Yes

No

Page 1 of 8

295134444.doc
14.

S.No
15.

16.

17.

18.

19.

20.

SingleRecord Block Layout:

Items on adjacent rows should be left aligned where possible.
Items should be sequenced by order of precedence from leftto
right, then toptobottom.
If the block contains multiple regions, the tab sequence should
move between the items of a region before moving to another
region within the block.
Prompts should be placed to the left of the field
Name
MultiRecord Block Layout:
Columns should be stacked horizontally and aligned along their
top.
Multirow blocks should display a minimum of three records,
unless only a maximum of two records can ever exist.
Space may be left between columns where prompt sizes or region
cosmetics require it.
If, for some reason, the window is wider than the multirecord
block then the multirecord block should be positioned on the left
side of the window, rather than centered.
Multirecord blocks display a record scroll bar, as follows:
position: 0.1
Scroll Bar Orientation: Vertical
Scroll Bar Width: 0.2
Height: Same as items in the block
Reverse Direction: False
Canvas: The same canvas as the block content canvas.
Vertical position: Aligned with the top of the first row of
items
Current Record Indicator: All multirecord blocks have an indicator
to point out the current Record. The indicator should be looking in
the following ways:
Apply CURRENT_RECORD_INDICATOR property class to indicator
text item
If the block supports a drilldown capability, then apply
DRILLDOWN_RECORD_INDICATOR property class to the indicator
text item
Stacked between the scroll bar and the first column of the block
with no blank space on either side of the indicator
MasterDetail Block Titles:
To indicate masterdetail relations, and for general clarity, try to
repeat the master block name in the detail block title.

Yes

No

Coordination check box for Master-Detail Blocks:

Apply CHECKBOX_COORDINATION property class to the item and
should be positioned as follows:
If coordination applies to the whole window, place the checkbox
on the top line of the window.
If there is a block boundary line separating the detail block, and
the coordination check box applies only to that block, then the
coordination check box should be placed on the block boundary
line in the rightmost three character cells
Groups of fields or Regions:
The title of the region should be the name of the group of items it
contains (usually a noun).
The title should be positioned along the top of the region as
follows:

USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

Page 2 of 8

295134444.doc
Horizontal Origin: Left
Vertical Origin: Center
Horizontal Position of Origin: snapped to a grid line, 1.5
character cells to the right of the left edge of the region
Vertical Position of Origin: snapped midway between grid
lines
The title should be positioned in front of the rectangle or line.
The title text should include one leading and one trailing space.
The title text should be in boldface type always.

S.No
21.

22.

23.

The widget that displays the title can be any of the following:
Boilerplate (for static region titles)
Display Item, designed to look like boilerplate (for
dynamic region titles)
Poplists (for Alternative Regions)
Check Boxes or Option Groups (for when an entire region
may be applicable or inapplicable)
The region should be bounded by either a rectangle (for a single
record format region) or a line (for a multirecord format region),
and should be displayed with the following characteristics:
Thickness: 2 points
Bevel: Inset
Line Color: Black
Name
Text Item Property Class:
In general, most text items should use the TEXT_ITEM property
class.
Use the TEXT_ITEM_DISPLAY_ONLY property class on fields that do
not allow a user to type, but must support scrolling and or
querying.
Use the TEXT_ITEM_MULTILINE property class on all multiline text
items.
Use TEXT_ITEM_DATE for date fields unless the item is display
only.
Apply the CREATION_OR_LAST_UPDATE property class to the items
containing the WHO date information, CREATION_DATE and
LAST_UPDATE_DATE.
Alignment Rules for Text Items:
Numbers that do not display consistent precision should be Start
Aligned. For example: identification or phone numbers.
Numbers with consistent precision such as quantities and prices
should be Right Aligned.
Textual Values for all conditions should be Start or Center
Aligned
Date Values for all conditions should be Start Aligned
Display Items Property Class:
Use DYNAMIC_TITLE, if an item is used to hold a dynamic title.
Use DYNAMIC_PROMPT, if an item holds a prompt.
Both of these property classes provide a canvas colored background
(gray).
Otherwise, you should apply the DISPLAY_ITEM property class to
your display items (Provides a white background with no bevel).

USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

Yes

No

Page 3 of 8

295134444.doc
24.

25.

26.

27.

S.No
28.

29.

30.

31.

32.

Display Items Y Position:

A display item on a canvas using the DISPLAY_ITEM property class
must be positioned .02 inches below the gridline (to account for
the lack of the bevel used for enterable text items).
Items using either DYNAMIC_TITLE or DYNAMIC_PROMPT must be .
05 inches below the gridline. These offsets allow the text within
them to align properly with other widgets or boilerplate.
PopLists Property Class:
Poplists holding data should use the LIST property class.
Poplists that serve as control elements for alternative regions
should use the LIST_REGION_CONTROL property class.
PopList Limits:
The maximum width of a list element is 30 characters. Your longest
value in English for a 30characterwide poplist should be no longer
than 23 characters to account for expansion of values for some
languages.
TLists Rules:
Does it contain atleast five rows of data.
Tlists should only be used in lowvolume forms with extensive
screen real estate available.
Name
Option Group:
Should apply the RADIO_BUTTON property class to each button of
an option group.
There is no property class to assign to the group itself.
Check Boxes Property Class:
Should apply the CHECKBOX property class to each normal check
box (used for data entry).
Should apply the CHECKBOX_COORDINATION property class to
each coordination check box.
Buttons Property Class:
For Textual buttons, BUTTON property class should be used.
For Iconic buttons, BUTTON_ICONIC property class should be used
and it should typically appear only in the toolbar or in folder
forms.

Yes

No

Buttons Navigable and Mouse Navigate Properties:

Single record block buttons should be Navigable TRUE.
Multirecord block buttons should be Navigable FALSE. The
exception is CLEAR buttons, which should always use Navigable
FALSE. This is to prevent users from accidentally clearing records
when they expect to fire the default button.
All buttons are Mouse Navigate FALSE.
Buttons Layout Rules:
The right edge of the rightmost button must be 0.1 from the
right edge of the window.
In general, leave 0.1 between buttons. If there are logical
groupings of buttons, leave 0.5 between the groups (and still
place 0.1 between the buttons in each group).
If horizontal space does not allow 0.5 between groups of
buttons, then leave as much separation as is possible.
A button should have a minimum width of 0.2 just to support the
cosmetics of the widget. To adhere to translation requirements,
the actual minimum width of a button is therefore 1.2.
All buttons should have an Access key except OK and Cancel

USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

Page 4 of 8

295134444.doc
33.

S.No
34.

35.

36.

37.

38.

within dialog windows.

List of Values (LOV):
Should apply the LOV property class to all LOVs.
Position all LOVs with the upper left corner at (1, 1).
Width: Maximum: 7.8 Minimum: 3 Any width between these is
allowed.
The title of an LOV should be the name of the object in the LOV,
and is plural.
The prompt of the first column should be related to, or matches
identically, the prompt of the item that invoked it.
Name
Editors:
Do not write special code for the editor. Rely on native Oracle
Forms behavior.
On a DATE field, the Edit action should open the Calendar.
On a Flexfield, Edit should open the Flex window
Descriptive Flexfields:
Should apply the TEXT_ITEM_DESC_FLEX property class to all
DFFs.
The descriptive flexfield should be located as the last item in
each block, on the content canvas.
When an alternative region exists, the descriptive flexfield should
be located after the region (not as an item within an alternative
region).
The descriptive flexfield Forms field should be navigable, but
should not allow input. It adheres to all text item standards.
Key Flexfields:
Do not code any special visual indicator or activation button for
key flexfields. The field should look like any other text item.
Key flexfields should use the ENABLE_LIST_LAMP LOV and the
property Use LOV for Validation should set to False.

Yes

No

Widgets to Avoid:
The following widgets available in Oracle Forms should be avoided
due to either usability problems or crossplatform issues.
Combo Boxes
OLE and VBX controls
Text
a) All text (except text that has a known translated length) must be
able to expand by at least 30%.
b) The 30% rule applies to different types of text as follows:
If prompt on left of field, should leave 30% expansion room to
left of prompt
If prompt above leftjustified fields or lists, should leave 30%
expansion room to right of prompt
If prompt above rightjustified field, should leave 30%
expansion room to left of prompt
If prompt above centerjustified field or check box, should
leave 30% expansion room, divided equally to the left and
right of the prompt (i.e. 15% on each side)
For Buttons, size should be allowed for 30% expansion of the
label + 0.2
For Check boxes in singlerecord blocks, size should be allowed
for 30% expansion of the label + 0.3
Poplists size should be allowed for 30% expansion + 0.5

USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

Page 5 of 8

295134444.doc

Option Groups size every button the same, such that the
widest label can expand 30%
Region Titles size underlying rectangle or line such that title
can expand to the right by 30%
Displayonly fields size should be 30% wider than needed in
English, except for fixedwidth fields (date, time, etc.)
c) All prompts and labels should be in mixed case, except for the
following, which are in lower case:
Articles (such as the)
Coordinate conjunctions (such as and)
Prepositions (such as with)
The to infinitives
These words should, of course, be capitalized when they are at
the beginning of the prompt or label.

39.

S.No
40.

d) Avoid abbreviations if possible. However, some abbreviations have

been approved for use in Oracle Applications and are listed in
Appendix B of UISTAND.PDF.
Properties of Prompts and Titles:
A. Each prompt and title should have a minimum of 1 of space
available horizontally (including the text itself) in which to
expand when translated.
B. All prompts and titles should share the same font type MS Sans
Serif or Helvetica (either produces the desired result).
C. All prompts should have the following characteristics:
Font: 10 pt., medium weight
Edge: Clear
Fill: Clear
Text color: Black
D. All titles should have the following characteristics:
Font: 10 pt., bold weight
Edge: Clear
Fill: Canvas (gray)
Text color: Black
E. Prompts and Titles should only use Start, Center, and End for
alignment settings.
F. Display items may be used to show dynamic prompts and titles. A
display item acting as a prompt or title must have a height of
0.2, and be positioned 0.05 below a gridline.
G. All fields require unique prompts to identify them, except for
some displayonly fields whose prompts are obvious.
Name
SingleRecord Block Prompts:
Prompts should be positioned to the left of an item, with one
character cell between the rightmost character of the prompt and
the start of the item.
Specific settings should be like this:
Horizontal Origin: Right
Vertical Origin: Center
Horizontal Position of the Origin on the Grid: 0.1 to the left
of the start of the associated item
Vertical Position of the Origin on the Grid: Centered between
the gridlines. Multiline prompts must be positioned so that
the first line of text is positioned centered on the first row
that the associated item occupies.
Alignment: End

USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

Yes

No

Page 6 of 8

295134444.doc
41.

42.

43.

44.

MultiRecord Block Prompts 1:

Prompts should be positioned above the first record of each item.
Prompts for text items should be start, center, or end aligned
similarly to the data in their corresponding text fields, except in
the case of long prompts that use connecting lines.
Prompts for poplists should be always left aligned.
Prompts for check boxes should be centered above the box,
except in the case of prompts those use connecting lines. Do not
use the label property for check boxes in a multirecord block.
A prompt that pertains to several fields is, in effect, a region. It
may be drawn following the exact same standards as a region in a
multirecord block.
Prompts should be connected to their fields with connecting lines,
drawn as follows:
Color: Black
Thickness: 0 points
Inset: None
MultiRecord Block Prompts 2:
All prompts for multirecord blocks should have the following
vertical placement settings:
Origin: Bottom
Position of Origin: on the gridline
Horizontal placement should be determined as follows:
For leftjustified data elements, including lists:
Origin: Left
Position of Origin: 0.05 to the right of the left edge of the
associated field.
Alignment: Start
For centerjustified data, including check boxes (except when
using
Connecting lines with check boxes):
Origin: Center
Position of Origin: centered on the width of the item
Alignment: Center
For rightjustified data:
Origin: Right
Position of Origin: 0.05 to the left of the right edge of the
associated field
Alignment: End
Ellipses:
Ellipses (...) are used at the end of a menu entry or button label
if the entry or button opens a modal window.
for example, the menu entry About Oracle Applications.... or
the user
needs to provide further information about the action in another
window (modal or not) before the action can be completed.
Two examples are the menu entries Query Find... and Navigate
To....
Ellipses should not be used at the end of a menu entry or button
label if the button is used to open a nonmodal window that does
not require further information before the current action can be
completed.
Percent Fields:
Do not include Percent in the prompt always should use %.
In any case where the percent sign is used, should not enclose it
in parentheses or any other delimiters.

USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

Page 7 of 8

295134444.doc
45.

46.

Ranges:
Use the terms From and To to identify fields involved in a
range rather than Start and End or Low and High.
Access Keys (Mnemonics):
Controls that need to be operated with direct keyboard access
should provide an Access Key (underlined mnemonic access
character) to invoke them.
Should always provide access keys on the following objects:
All textual buttons, except OK and Cancel (OK is done
by Return and Cancel is done by Escape).
Option buttons or checkboxes that set a mode. Note
that only a check box or option button in a singlerecord
block can have an access key, because the label property
is not used in multirecord blocks.
In order of preference:
First letter of button or of key word.
First letter of the nonkey word
Second letter of button label
A strong letter of the label like.
Should not underline letters with descenders such as y, j, q, or p
as the underline and letter overlap. (y, j, q, or p)

Access keys must be unique within a window, and must not

conflict with the keys used by the top level of the menu (A, E, F,
G, H, Q, S and W) even if those menus are not used.
Note: USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

USE * FOR ANY NON-DEVIATION OF STANDARDS IN THE LIST.

Page 8 of 8