RCUI Document Version 5.2.2 for Oracle Fusion Middleware 11g Release 1 Patch Set 1 (11.1.1.2.0)
Last Updated
01-Mar-2011
Toolbars group iconic and textual commands which act on objects on a page or within a component (Tables, TreeTables and Trees). Toolbars contain at least one button along with optional separators, standard web widgets and overflow lists.
Guideline Contents
Note:Images in this guideline are provided as a general reference, and may not be exact representations of FusionFX pages.
Related Guidelines
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:
Examples |
Notes |
af:commandToolbarButton |
Toolbar button |
af:group |
Groups related toolbar buttons together |
af:toolbar |
Toolbar container |
Purpose:
Toolbars group iconic and textual commands for a page or component in one place.
Usage:
- Unlike Menus, which contain ALL commands the user can execute on a page or specific component, toolbars typically contain buttons representing a subset of the most frequently used menu items, which can be executed with less mouse clicks.
- If all applicable menu items fit easily on the toolbar, use a toolbar instead of a menu bar to save screen space and avoid duplication of commands. However, if the toolbar only contains a subset of functionality from menus, display both the toolbar and menus.
- The toolbar should contain at least one button, and may optionally contain separators and standard web widgets.
There are four types of toolbars.
- Page-level toolbar: Groups commonly used page-level commands.
- Header toolbar: Groups commonly used commands for a section or region of the page.
- Component toolbar: Groups commonly used commands for a component (for example, Table, TreeTable or Tree)
- Quick Search toolbar: Adds a Quick Search component to a page.
All types of toolbars group commands (both iconic and textual) in one place. The different types of toolbars should never duplicate functionality.
Placing too many toolbars on a page can confuse users. See Setting Limits on Toolbars for more information.
Purpose:
Use for selection-independent commands on a single, page-level object.
Usage:
- Page-level toolbars may be implemented in any of the following locations:
- Global Control Panel
- Primary Control Panel
- Secondary Control Panel
- The control panel used affects the vertical placement of the page-level toolbar, as shown in the following subsections. For more information on control panels, see the Page Layout usage guideline.
- A page-level toolbar is often implemented with a page-level menu bar. See the Menus usage guideline for more details on use of page-level menus.
Purpose:
Use this option when commands are associated with both the page and the overall application.
Examples:
- When managing an Application Server, a page-level toolbar can be used to startup/shutdown, refresh, and patch.
- Page-level toolbars could also contain non-object related commands, such as a 'Favorites' icon.
Page-Level Toolbar in Global Control Panel
Purpose:
Use this option when commands are associated only with the page.
Examples:
- When maintaining employee personal information, the page-level toolbar can be used to edit and remove data for a single employee.
Page-Level Toolbar in Primary Control Panel
Purpose:
Use this option when commands in the toolbar change based on the tab selected.
Examples:
- In business intelligence reporting, each tab can represent different 'layers' or views of data. One view of financial data may be yearly; others could be quarterly, monthly, or weekly. Different actions are available when different 'views' of the data are presented under tabs.
Page-Level Toolbar in Secondary Control Panel
Purpose:
Use for selection-independent commands on a single, section or region-level object.
Usage:
- Header toolbars may be implemented in any of the following locations:
- Page header
- Subheader
- Accordion panel header
- Search region header
- A Header toolbar should not be implemented with a menu bar, because header text followed by menu names may be confusing to users, especially if header text is truncated to fit menu and toolbar text without horizontal scrolling.
- A Header toolbar may contain an inline selector button instead of an object-specific actions menu (see the Menus guideline for details):
- When actions on the page apply to multiple types of objects, the button label should be "Actions". When the page contains a single object type, it is recommended to use the object type as the button label, such as "Orders".
- The selection panel may contain as many actions as needed, divided into groups of related actions where appropriate. See Menu Item Groups in the Menus guideline for details.
- If there are two or less actions, place them directly on the toolbar instead of in an Actions button.
- When used in a page header, the Actions button should be placed consistently before page-level buttons that finish work on the page, such as Submit and Cancel.
- If it is necessary to call attention to one or more actions, they may be implemented as individual buttons and placed before the Actions button.
- When displayed at the minimum supported screen resolution in a maximized browser window, Header toolbar buttons may be pushed into an Overflow list if there is not enough space after the header text. Consequently, it is recommended to limit the total number of buttons so that no more than 50 percent are pushed into the Overflow list.
Header Toolbar in Page Header
Header Toolbar in Subheader
Header Toolbar in Accordion Panel Header
Purpose:
Component toolbars are used for selection-dependent and selection-independent commands on objects in components such as Tables, TreeTables, and Trees.
Examples:
- A component toolbar 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.
Usage:
- Tables, TreeTables, and Trees each have a default toolbar. Product teams have the option to create specialty toolbars for each of these components, and to hide the default toolbar. See the following section for details on specialty toolbars.
- A component toolbar is often implemented in conjunction with a component menu bar. See General Principles above for more information.
- In rare cases, product teams can use a single component toolbar for multiple composite objects on one page. For example, on a page with both tree and table, where the tree controls the table, one toolbar can be used to span across both the table and the tree.
- A component toolbar should always be displayed after the component menu bar and appear start-aligned above the component.
- Buttons for common, object-specific actions, such as Create, Edit and Delete, should appear on a toolbar before any default ADF (View) buttons, such as Go Up and Go to Top.
Table (Component) Toolbar with Table Menu Bar
Purpose:
Specialty toolbars are created by product teams for product-specific actions.
Usage:
- Typically, only one specialty toolbar should be visible at a time.
- In complex cases (such as where a component contains multiple types of objects with non-overlapping functions for each type), a second row of specialty toolbars may be used.
- By default, a specialty toolbar is stacked below the default toolbar, but product teams can set specialty toolbars to appear adjacent to the default toolbar. Adjacent toolbars are placed as follows:
- Default toolbars appear before specialty toolbars unless the placement is overridden by product teams.
- When more than one adjacent toolbar is needed, product teams can set the priority of each toolbar, with lower priority toolbars appearing after those with higher priority.
- If horizontal space is not adequate to show all the adjacent toolbars, the toolbar with highest priority uses available space first, and buttons on the lowest priority toolbar move into overflow.
- Adjacent toolbars require less vertical space. They are recommended when:
- All toolbar buttons can be displayed at the same time.
- The gain of additional vertical space offsets the delay in access to the end-aligned toolbar buttons.
- When the default buttons (provided by ADF) are used in a toolbar, they always appear after any custom buttons added by product teams.
Adjacent Toolbars
Stacking Toolbars
Purpose:
Use for conducting simple searches.
Usage:
The Quick Search toolbar should not be used within a component toolbar. See the Search and Query usage guideline for more functionality details.
The Quick Search toolbars may be implemented in one of three different application control panels:
- Global Control Panel
- Primary Control Panel
- Secondary Control Panel
Purpose:
Use the Quick Search in the Global Control Panel when the search spans the entire application hierarchy, or, for products that are part of a suite, when the search extends to other applications in that suite.
Examples:
- In a complex application such as Projects, use the Quick Search in the Global Control Panel to search for project, resource, timecard or even project accounting information.
Quick Search Toolbar in Global Control Panel
Purpose:
Use the Quick Search in the Primary Control Panel when the search spans the entire application hierarchy, but does not extend to other applications.
Example:
In an Expense Report application, if the user is searching for a specific expense report, the Quick Search toolbar in the Primary Control Panel can be used to help find an exact match.
Quick Search Toolbar in Primary Control Panel (within a page-level toolbar)
Purpose:
Use the Quick Search in the Secondary Control Panel when the search is applicable to a selected area of the application.
Example:
In a Manufacturing application, if the user is searching for a specific product within a "Raw Materials" tab, the Quick Search toolbar in the Secondary Control Panel can be used to help find the needed product.
Quick Search Toolbar in Secondary Control Panel (within a page-level toolbar)
The following diagram lists the principal toolbar elements.
Principal Elements of a Toolbar
Purpose:
The Toolbar Region is the visual container for the toolbar and menu bar.
Usage:
- Page-level toolbars and Quick Search toolbars are typically placed at the top of the page. Region toolbars are end-aligned next to header text. A component toolbar is always attached to the top of the component it affects.
- A menu bar can also be included within any toolbar region, but it is not recommended to use menu bars in conjunction with Region toolbars. When a menu bar is included, it is always the first, topmost bar in the toolbar region. See the Menus usage guideline for more details about the menu bar.
Purpose:
Toolbar buttons provide access to commands for a page, region or component.
Usage:
- The buttons for a toolbar can reside on the toolbar itself or on the Overflow List.
- A toolbar must have at least one button.
- Iconic text buttons should be ordered before text buttons on the toolbar.
- Toolbars should generally include buttons for the most commonly used menu commands.
- Toolbar buttons should only be used for actions. Toolbar buttons may perform an action directly, open a dialog box, or navigate to another page if necessary. Navigation to another page should only be used when:
- The object being created or edited is too large to fit into a dialog window.
- Multiple objects are being created or edited at the same time.
- The creation process requires the use of a train.
- If buttons are selection-dependent they must be disabled when the action is not applicable.
- When toolbars contain multiple buttons, they should be divided into groups. For detailed recommendations, see Toolbar Separators.
- Toolbar button labels should be consistent within and across products.
- Many buttons issue commands. When this is the case, use a verb to label a button (such as Delete, Print, Zoom). However, there can be exceptions to labeling all buttons as verbs, especially when paraphrasing is necessary to save screen space. For example, when a button is available to create a new paragraph, the button can be labeled "Paragraph" (as opposed to a lengthy, verb-form such as "Create New Paragraph").
- If a button uses short label text (in order to visually fit in the toolbar), yet the label still requires further explanation, use button tooltips on hover. See the Help Framework usage guideline for details about tooltips.
- See the Buttons usage guideline for more details and examples of how to label buttons.
There are three button formats used in the toolbar.
- Iconic Button (Butcon) - Icon only
- Iconic Text Button (Text Butcon) - With an icon and text
- Text Button - With text only
Button Formats
Usage:
- For visual consistency, it is recommended that application teams implement either Iconic Text buttons or Text buttons throughout all application pages. Either type may be combined with groups of Iconic buttons.
- When more than one button format is displayed on a toolbar, it is recommended to group buttons with the same format together wherever possible, to provide visual consistency within each group.
Iconic buttons (Butcons) require the least horizontal space of all button formats, and should be used for common functions that are generally associated with specific images or symbols. FusionFX provides a set of standard iconic buttons on the default toolbar for the Create, Edit, and Delete commands. If product teams need to provide additional iconic buttons, they should place them on a specialty toolbar.
Iconic Text buttons (Text Butcons) require the most horizontal space of all button formats, but are both the most noticeable and recognizable of all three formats. Consider using Iconic Text buttons when the number of buttons is relatively low and graphic resource usage is not a limitation.
Text buttons require a medium amount of horizontal space, are readily recognizable, but not as noticeable as the other formats. Consider using text buttons for functions that do not have a standard iconic button, especially in applications that need to minimize graphic resource usage. A toolbar may contain multiple text buttons if space permits.
There are five button types used in the toolbar.
- Command Button
- Toggle Button
- Radio Group Button
- Inline Selector Button
- Tool Button
Usage:
All button types may use Iconic button, Iconic Text button, or Text button formatting. See the following sections for details on each type.
Purpose:
Command buttons take a direct action and typically refresh the page or launch a dialog box.
Examples: Print, Save, Delete
Purpose:
Toggle buttons apply characteristics to a selection.
Description:
A toggle button remains in "pressed" state when clicked.
Examples: Bold, Italic and Underline (mimics checkbox interaction).
Toggle Buttons in "On" State
Purpose:
Radio group buttons apply characteristics to a selection.
Description:
Radio button groups require at least two mutually exclusive buttons.
Examples: Align Left, Align Center and Align Right (mimics radio group interaction)
Purpose:
Inline selector buttons associate a range of related actions with a single button.
Description:
Inline selector buttons contain a drop-down arrow that displays an inline selector when clicked (similar to a select choice list).
Examples:
- Color picker button and selection panel
- An inline selector button labeled "Create", with a selection panel listing different object types.
Table Toolbar with Inline Selector Button
Usage:
- Product teams can configure the button in two ways:
- Single Button: Clicking the button or down arrow opens the selection panel.
- Split Button: Clicking the button performs an action directly; users must click the down arrow to display the selection panel.
- See Selection Panel in the Buttons guideline for more examples and recommendations.
Tool buttons allow user access to tool functionality, typically involving a cursor change.
Examples: Zoom, Crop
Note: Tool buttons are not provided by ADF, and, when needed, must be manually constructed by product teams.
Purpose:
Toolbar separators are vertical lines that visually divide buttons into groups.
Usage:
- Two separators should not be adjacent to one another.
- Separators should not appear in an overflow list.
- Separators should not appear as the first or last item in a toolbar.
Use the following heuristics to develop groups of toolbar buttons:
- Group buttons based on the following considerations, in decreasing order of importance:
- Place Toggle buttons together. The group may also contain related buttons.
- Place Radio Group buttons together. The group may also contain related buttons.
- Place buttons with similar or related functions together, such as Create, Delete and Edit.
- Place buttons with similar formats together, where this does not conflict with previous recommendations.
- Order groups based on the scope of action:
- Groups of buttons that create, delete, or modify an object should precede buttons that affect display within the component, the format of data, or other general functions.
- Order buttons within a group based on:
- Commonly used orders for related actions, such as Create, Edit, Delete.
- Frequency of use, from most frequent to less frequent.
- For toggle and radio group buttons for application-specific functions that affect spatial relationships, use the following established sequences:
- Left, center, right, and other (justify) horizontal alignment
- Top, middle, bottom and other vertical (baseline) alignment
- Front, back
- For font controls, use the following sequence: Font, Font Size, Bold, Italic, and Underline. The overall sequence should remain the same even if some font controls are omitted.
- Although there is no limit to the number of buttons per group, no more than seven are recommended, both to emphasize the most commonly used commands and to avoid screen clutter.
Purpose:
Toolbar dividers are vertical lines that visually separate multiple types of toolbars (like default toolbars and specialty toolbars). Toolbar dividers are also used to separate the menu bar from the toolbar.
Usage:
- Two dividers should not be adjacent to one another.
- Dividers should not be the first or last item in a toolbar region.
Purpose:
The overflow list contains buttons that cannot fit in the horizontal space allotted to the toolbar.
Description:
- Only one overflow list is shown per toolbar. For example, a default toolbar and a specialty toolbar each have its own overflow list.
- When a component changes width due to browser resize or component resize, the toolbar region responds by extending or contracting to match the width of its component.
- As the toolbar region extends or contracts, the toolbars within the toolbar region also extend or contract. Buttons may be added or removed from the toolbar as a result of increased or decreased horizontal space.
- At least one button always remains visible on the toolbar.
- Buttons removed from the toolbar move into the overflow list. Buttons added to the toolbar are removed from the overflow list.
- Buttons move into the overflow list starting from the end of the toolbar. In other words, when a toolbar is resized to be smaller, the last button in the toolbar is the first to move into the overflow list. If multiple toolbars appear adjacent to one another, buttons from each toolbar move into the overflow list of each toolbar based on the percentage of space allotted to each toolbar.
- Buttons move into the toolbar starting from the top of the overflow list. In other words, when a toolbar is resized to be wider, the first button in the overflow list moves into the toolbar.
- Product teams may set grouping or prioritizing rules to control the population and depopulation of buttons in the toolbar. For example, all character formatting icons may descend into the overflow list at once to make room for a text button which requires more horizontal space.
Purpose:
Quick Search functionality uses a text field, a select choice list of object attributes, and a "Search" button to conduct searches within an application.
Usage:
See the Search usage guideline for more details about Quick Search functionality.
- A page may only have a single Quick Search toolbar, unless the page contains an Accordion panel, in which case it may have a separate Quick Search toolbar.
- A page may contain multiple page-level toolbars in the same location or multiple component toolbars in the same location, if they are needed to support different types of actions.
- To save space, especially after translation, each header should have no more than one toolbar.
- Placing toolbars in multiple locations on a single page can confuse users as to which toolbar affects which objects or page properties. Consequently, it is recommended to avoid placing toolbars in different locations on the same page unless the toolbar functions are clearly distinct, such as the following combinations.
- One page-level location and one component location
- Two component locations for different components or instances of a component
- One page-level location and one subheader location
- One header toolbar for each page subheader, up to a maximum of three per page.