RCUI Document Version 5.1.1 for Oracle® Fusion Middleware 11g Release 1 Patch Set 1 (22.214.171.124.0)
A menu system provides access to all permissible commands for a page, region, or any FusionFX component supporting menus. Menus contain at least one menu item and optional submenus.
Note: Images in this guideline are provided as a general reference, and may not be exact representations of FusionFX pages.
Related ADF Elements
Refer to the ADF Faces Rich Client demos page to find demos and tag documentation for the ADF elements related to this component:
||For command-type functionality.
||For "Go" functionality.
A menu system provides access to all commands implemented for a page, region, or FusionFX component supporting menus.
FusionFX menus are only used within an application page, region, or component, and operate independently of browser menus.
Menus are similar to Toolbars, but there are some visual and functional differences:
- Menus and toolbars can be displayed in the same Toolbar Region.
- Menus contain all commands the user can execute on a page or specific component. Toolbars, on the other hand, typically contain buttons representing a subset of the most frequently used menu items, which can be executed with less mouse clicks.
- A toolbar can exist independently of a menu bar. A menu bar may exist independently of a toolbar. However, if all applicable commands fit easily on the toolbar, consider using a toolbar instead of a menu bar to save screen space and avoid duplication of commands.
- Product teams can disable or hide default menu items and toolbar functions:
- Product teams can also disable or hide toolbar functions independently of the menu system, so they can configure a toolbar when it is displayed alone, or hide a less frequently used toolbar item when the toolbar is displayed in conjunction with a menu bar.
- If product teams need to disable a function when a menu and toolbar are displayed together, they should disable it in both the menu and toolbar.
- In Accessibility Mode, menus must always be displayed. When not in Accessibility Mode, if the toolbar contains a subset of functionality from menus, display both the toolbar and menus.
There are four types of menus.
- Page-level Menus: Group page-level commands on a menu bar in the Global, Primary, or Secondary Control Panels near the top of the page. See the following subsection for details.
- Component Menus: Group component-specific commands on a menu bar above a FusionFX component that supports menus (such as a table, tree, or tree table).
- Context Menus: List the most frequently used commands for a component.
- Overflow Menus: Contain menu names that cannot fit into the horizontal space allotted to the menu bar.
: All types of menus may have submenus, except Header Toolbar menus. However, only page-level and component menus may include tear-off submenus. See Tear-Off Submenus
All types of menus support two types of content delivery: immediate and
- Immediate content delivery: Menu items are retrieved on page load and
display immediately when the user clicks on the parent menu or submenu.
Immediate content delivery should be used for most cases.
- Lazy content delivery: Menu items are retrieved only after the user
clicks on the parent menu or submenu. When the user clicks, the text "Fetching Data..." appears in the menu until the content is available to
display. Lazy content delivery should be used only when a menu is dynamic and
its content changes at runtime.
If the overall page or any component has very few commands, developers may use a toolbar without menus. For details, see General Principles above.
Technically, menus may be placed within a Header Toolbar Region, but this is not recommended, because header text followed by menu names may be confusing to users, especially if headers are truncated to fit menu and toolbar text without horizontal scrolling.
If it is necessary to provide many commands for a section or region of the page, such as in an Accordion panel, it is recommended to provide those commands as an inline selector on a toolbar. See Header Toolbars in the Toolbars guideline for details.
Page-level menus are used for selection-independent commands on a single, page-level object.
- Page-level menu bars may be implemented in one of three different locations:
- Global Control Panel
- Primary Control Panel
- Secondary Control Panel
- The control panel used affects the vertical placement of the page-level menu bar, as shown in the following subsections. In all three control panels, the menu bar is placed in that control panel's toolbar Region. For more information on control panels, see the Page Layout usage guideline.
- When discussing placement of menus, a menu can be referred to using the name of the control panel in which it is located, such as "Global menu".
- A page-level menu bar is often implemented together with a page-level toolbar. See the Toolbars usage guideline for more details.
Use this option when commands are both associated with the page and the overall application.
Page-Level Menus in Global Control Panel
- In managing an Application Server, a page-level menu can be used to startup or shutdown, refresh, and patch.
- Page-level menus can also contain non-object related commands, such as "Favorites".
Use this option when commands are associated only with the page.
Page-Level Menus in Primary Control Panel
When maintaining employee personal information within a Human Resources application, a page-level menu can be used to edit and remove data for that single employee, and no more.
Use this option when commands in the menu depend on the tab selected.
Page-Level Menus in Secondary Control Panel
In business intelligence reporting, each tab can represent different "layers" of data. One view of financial data may be yearly; others could be quarterly, monthly, or weekly. Different actions are available in the menu when different "views" of the data are presented under tabs.
Component menus are used for selection-dependent and selection-independent commands on objects for components such as Tables, Tree Tables, Trees, Gantt, and Map.
A component menu can perform actions on one record of an employee table, such as editing an employee's address from a list, deleting an old address from a list, creating a new address, printing all address listings, and also revising the View and format of address data as it appears on the screen.
- Component menu bars are always placed directly above the component.
- A component menu bar is often implemented in conjunction with a component toolbar. See the Toolbars usage guideline for more details.
- In rare cases, you can use a single component menu for multiple composite objects on one page. For example, if you have a tree and table on the page—and the tree controls the table—then one menu can be used to span across both the table and the tree.
Component Menus (attached to a Table)
Several images in this guideline show an ellipsis appended to object-specific commands provided by product teams, such as Create, Edit, and Duplicate. The ellipsis should appear only when more information is needed to complete an action. See Ellipses
A context menu is a shortcut menu that appears when the user right-clicks a component or uses an equivalent keyboard command.
- Context menus enable users to act on objects within Table, Tree Table, Tree, Pivot Table, and Gantt components.
- Only one context menu can be displayed at a time.
- Context menus do not have an explicit "Close" menu function. When the user clicks another part of the page, the context menu closes automatically and disappears.
- Page-level and component menus cannot be displayed at the same time as a context menu. However, a context menu may be displayed at the same time as a Floating submenu.
- Context menus do not support Tear-off Submenus.
- Items in a context menu vary since they are derived from the menu system of a specific component.
- For every context menu item, there must be a path for achieving the same command using a menu bar or toolbar.
- If a context menu has many menu items, they should be separated into groups. Groups should be logical, ordered according to function, with a menu item separator between groups. For example, group all common commands—such as Edit , Delete and Print—into one group, OR group all selection-dependent commands into one group and non-selection dependent commands in another. Create a separate group for other functions, such as text formatting or color formatting.
- There is no limit to the number of context menu items allowed. However, the general heuristic is to list no more than four context menu groups, and no more than 10 to 12 context menu items, to avoid creating a long list where it is more difficult to select items.
- The vertical order of menu items for the context menu automatically matches that of its associated menu and submenus, which are configured by product teams. This way, the entries are consistent between the main menu and the context menu.
Note: Most context menus consist of items from a single main menu, so may consist of one or more groups that follow the sequence of that main menu. When including frequently used items from a different menu, append them in their own group or groups at the bottom of the context menu.
The Overflow Menu contains menu names that cannot fit into the horizontal space allotted to the Menu Bar.
- Only one overflow menu is shown per menu bar.
- When a component changes width due to browser resize or component resize, the menu bar responds by extending or contracting to match the width of its component.
- As the menu bar extends or contracts, menu names may be added or removed from the menu bar as a result of the increased or decreased horizontal space available after resize.
- At least one menu name always remains visible on the menu bar.
- When menu items are added to the overflow menu as a result of resizing, then the items disappear from the menu bar. When resizing causes menu items to go back into the menu bar, those menu items disappear from the overflow list.
- Menu names move into the overflow menu list starting from the end of the menu bar. In other words, when a menu bar is resized to be smaller, the last menu name in the menu bar is the first to move into the overflow menu. If toolbars appear adjacent to the menu bar, then buttons from the toolbar, and menu names from the menu bar may move into overflow, based on the percentage of space allotted to the component accommodating the overflow.
Overview of All Menu Elements
The menu bar is the visual container for page-level and component menus.
- A page-level menu bar is placed near the top of the page in the Global, Primary, or Secondary control panel. A component menu bar is always attached to the top of the component it affects. For details on use of page-level menu bars in different control panels, see Page-Level Menus, above.
- A menu bar must contain at least one menu name.
- It is recommended that a page contain only one page-level menu bar and one menu bar per component. Otherwise, users could become confused as to which menu affects which sections of page content.
- Menu names support tooltips. Use a tooltip when the menu name has been shortened and it might be useful for the user to see more descriptive text. For example, for the menu name "Expense Reports", the tooltip might say "Expense Report Actions". Disabled menu names also support tooltips.
: Menu bars are often implemented together with toolbars. When a menu bar is combined with one or more toolbars, it is always the first, topmost bar in the Toolbar Region. See the Toolbar
usage guideline for more details.
Menu names categorize a set of commands available to a page or component.
- Menu names are listed horizontally on menu bars and open their corresponding menus.
- Default menu names and keyboard shortcuts should be provided for frequently used commands. See the Keyboard Framework usage guideline for more details on keyboard shortcuts.
- There is no limit to the number of menu names allowed. However, the general recommendation is to list no more than seven to make the list easier to read at a glance.
The default menu names are: [ObjectType], View, and Format. Product teams should specify the [ObjectType] menu name as follows:
- When actions on the page apply to multiple types of objects, the menu name should be "Actions" or "Objects".
- When actions on the page apply to a single object type, product teams may use the object type as the menu name. For example, in a table of sales orders, the object type may be "Order," and the Order menu lists all commands that perform actions on orders.
- Product teams are responsible for providing the [ObjectType] name for the menu and also for defining all menu access keys.
- See Object-Specific Actions Menu in the Table Elements guideline for more details.
Default menu names always appear in the default sequence: [ObjectType], View, Format, regardless of which menu names are displayed or hidden.
Product teams can configure menu names as follows:
- Hide default menu names based on product needs.
- Add additional menu names (plus their access key combinations). Additional menu names appear at the end of the default menu name sequence.
Note: As users interact with a component, menu names should remain static. They should not be dynamically changed, added to, removed from, or reordered.
Menu Items are the entries in a menu, which enable users to act on page-level objects or objects within a component.
- Menus must contain at least one menu item and may optionally contain submenus.
- Menu items can:
- Execute commands
- Launch secondary windows
- Navigate users to other pages
- Open submenus
- Default menu items are provided for some frequently used commands. See the individual component usage guidelines for a listing of the default menu items.
- Menu items should be named as follows:
- Use the short form for a menu item whenever possible, such as "Create".
- If the short form may cause ambiguity, use a longer, more specific form, typically by appending the object type to the short form, such as Create Order, Create Pricing Request, and Create New Version.
- Use headline capitalization for all menus. See Capitalization in the Language in UI guideline for details.
- Ellipses (...) should be appended to menu items when more information is needed to complete an action. See Ellipses for details.
- In general, menu items should be ordered as follows:
- Place commands that perform actions on the primary object at the top of the menu.
- Place commands that perform actions on secondary objects in the middle of the menu.
- Place general commands at the bottom of the menu.
- Place more frequently used items above less frequently used items.
- Menus with a large number of menu items should be divided into groups, using menu item separators between each group. See Menu Item Groups below.
- There is no limit to the number of menu items allowed. However, the general heuristic is to limit menu item groups to no more than seven groups, and no more than 17 menu items total.
- Menu items support use of access keys and accelerator keys (except the Submenu Name type). See the Keyboard Framework usage guideline for more details on access keys and accelerator keys.
- Menu items support tooltips. Use a tooltip when the menu item has been shortened and it might be useful for the user to see more descriptive text. For example, for the menu item "Create...", the tooltip might say "Create Expense Report". Disabled menu items also support tooltips.
There are multiple types of menu items, as shown below.
Menu Item Types
All types of menu items support accelerator keys, except the Submenu Name type. See the Keyboard Framework usage guideline for additional details on accelerator keys.
||Take a direct action.
- Open a dialog window
- Trigger a table refresh
||Take the user to a new page.
Navigate user to a new page
||Control two mutually exclusive states associated with the page or component, only one of which can be active at a time.
The states of Toggle Items are "remembered." That is, they appear in the same state the next time the menu is opened. Item text remains the same regardless of state.
|Dynamic Antonym Items
||Control two states that can be conceptualized as two terms with opposite meanings. The displayed term is the antonym to the current state of the page or component.
The states of Dynamic Antonym Items are "remembered." That is, they appear in the same state the next time the menu is opened.
|Radio Group Items
||Apply characteristics to a selection. Require at least two mutually exclusive buttons, only one of which can be active at a time.
The states of Radio Group Items are "remembered." That is, they appear in the same state the next time the menu is opened. Item text remains the same regardless of state.
|Submenu Name Items
||Open a single submenu at a time. Do not support use of accelerator keys.
Product teams can configure menu items as follows:
- Hide default menu items or an entire menu item grouping based on product needs.
- Add additional menu items together with their access key combinations to an existing or new menu grouping.
- The top-to-bottom sequence for the default menu items remains the same, regardless of which items are displayed or hidden, and regardless of whether product teams add new items.
- Additional menu items should usually be placed at the bottom of the default menu item sequence.
- If a new item is used more frequently than the default menu items, it may be placed as the topmost item in the group. This pushes the default menu items down the menu list, but it does not disrupt their relative order.
- Disable a menu item if it is conditionally unavailable. For example, a selection-dependent command is shown as disabled until the user selects a valid target object or target element for that action.
Note: As users interact with a component, menu items should remain static. They may not be dynamically changed, added, removed, or reordered.
Use separator lines to organize long menus into sets of related commands, making them easier for users to scan.
Groups in an Object Menu
- Place actions against the primary object, such as Add, Create, and Edit, in their own group at the top of the menu.
- If there are more than one Delete or Remove actions against the primary object, place them in their own group.
- Place all actions against secondary objects in their own group.
- Place any general functions in a group at the bottom of the menu.
- Within each group, order actions by frequency of use, with more frequently used actions at the top, unless there is a logical or common order to the menu items in a grouping, such as Cut, Copy, and Paste.
- If a frequently used menu item needs to be placed near the bottom of the menu, consider also providing this as a toolbar action. See the Toolbars guideline for details.
- Finding the right level of balance in a menu can be a challenge. Too few or too many items in a group can make the menu difficult to scan.
- Where possible, do not group menu items in sets of one. If some items don't fit with anything else, consider merging the item with a related group, or placing them together in a 'miscellaneous' group.
- Where possible, do not group more than five menu items together.
- The following image shows examples of both appropriate and inappropriate use of groups.
Appropriate and Inappropriate Use of Groups
The ellipsis character (…) is used on menu items and button labels to indicate that more information is needed to complete an action. It provides a clue to users that a dialog or another page may appear where they need to make a selection or enter further details before the action can be completed.
For example: A menu item like "Save As" requires an ellipsis if the user needs to enter the object name in a separate dialog window before the object can be saved.
Do not use an ellipsis when:
- The sole result of clicking a menu item is to navigate to a particular page and no other information is required during this process. For example, a menu item like "Version History" may take the user to a dialog that shows a history of check-ins, but no other information is needed to finish this action, so "Version History" should not have an ellipsis.
- The action only displays a warning or confirmation message for the action. For example, a "Delete" menu item may show a warning dialog to the user if there is a potential for data loss; however, "Delete" should not have an ellipsis.
Display additional menu items when the menu contains more than 14 entries, or a number set by product teams.
- Vertical scroll icons appear as scroll down and scroll up icons. The scroll up occupies the topmost position on the scrollable menu while the scroll down icon occupies the bottommost position.
- Vertical scroll icons are enabled and disabled based on the position of the menu items. When the topmost menu item is visible, the upper scroll icon is disabled. When the bottommost menu item is visible, the lower scroll icon is disabled.
Vertical Scroll Icons
The default and recommended value to trigger scrolling is 15, but product teams can configure the menu to show more items before scrolling if needed.
Submenus display a secondary level of menu items when users choose a submenu name from the parent (main) menu.
Submenus follow the same rules as regular menus, and can perform the same range of actions.
- Do not use a submenu for primary actions. These actions should always be visible in the first level of the menu.
- Submenus are useful for setting attributes or object status, though this can also be accomplished using other components and design patterns.
- Submenus can be used when providing many actions that repeat the same initial term, as long as they are not actions against a primary object or frequently used actions.
- Do not nest more than two submenus. The recommended maximum number of open
menus is three: primary menu from menu name, submenu from menu item, submenu from submenu item.
Submenu with Attributes
Submenu with Repeated Term
There are three types of submenus:
- Regular submenus
- Tear-off submenus
- Floating submenus
Regular submenus list menu items in the same way as submenus in a Windows application.
Tear-off submenus behave the same as regular submenus except that a tear-off submenu includes a "handle" on top. This handle allows the submenu to be pulled away from the main menu and remain "floating" on top of the page or component when the parent menu is closed.
The following diagram shows how a tear-off submenu becomes a Floating submenu.
Tear-Off Submenu Becomes Floating Menu
Note: Tear-off submenus can only be implemented in page-level and component menus. They cannot be implemented in context menus.
Floating submenus allow users to execute similar commands repeatedly without needing to open a menu multiple times.
- Once a tear-off submenu has been pulled away from its parent menu, the handle from the tear-off submenu is replaced with a window title bar. The title of the floating submenu repeats the originating submenu name.
- The submenu exists as a modeless dialog which may be repositioned anywhere on the user's screen, but may not be resized. See the Secondary Windows usage guideline for details.
- A floating submenu persists across users sessions until the user explicitly closes the window using the "X" (Close) button or keyboard equivalent.
- Two instances of the same floating submenu cannot exist at the same time.
- Two or more different floating submenus may exist concurrently. The user can click a floating menu to bring it into focus, or press Ctrl+Alt+W to cycle through the floating menus.
Floating submenus are helpful to users in many scenarios, such as when users:
- Execute similar commands repeatedly on a page.
- Execute similar commands on different rows of data in a large table, tree table, or tree.
- View data in long and wide tables or tree tables, and trees. Users can choose which columns or branches to hide or display with a single click.
- Format data in long or wide tables, tree tables, or trees.