|Page Actions Guidelines|
|This guideline describes how and where actions are handled in either the Page model or Dynamic Tab model, including actions at the page level, section level, and secondary and external windows. For more information, see the Save Model Guideline, Secondary Windows Guideline , Introduction to Work Areas, Keyboard Shortcuts, and the other links listed throughout this guideline.|
This section provides some basic principles and guidance that apply to pages in the Page model or the Dynamic Tab model.
Quick Reference to Page Action Buttons
The following table shows the button labels associated with different dialog box and page actions.
Note: For certain setup pages available within the Setup and Maintenance work area, you can also provide a Save and Go to Task functionality.
Page-Level Button Groupings
Page-level actions are divided into two groups:
These groups are divided with a separator, with general actions and record navigation on the left and final actions on the right. The Cancel button appears in the rightmost position.
Final actions (including Save, Submit, Cancel, and so on) are the most important actions and should always be visible on the page. While there is only one Cancel button, in some cases, more than one save action is relevant. Save and Save and Close actions usually appear as dedicated buttons on the page, but if multiple Save or Submit actions (for example, Save and Create Another, Save As, and so on) are applicable to the transaction, these actions can be grouped together in the same drop button with the most common action appearing as the default.
Note: In some cases, a dedicated Save button is not mandatory (figure 2). For more information on final actions, save options, and interactions, see the "Save Model Interactions and Button Combinations" section in the Save Model Guideline.
Follow these guidelines for final actions:
The final actions buttons should generally follow in order of general actions, record navigation, and then final actions (figure 3)
General Actions Against Object (Actions Menu)
In addition to the final page actions previously described, additional actions can be used (if necessary) and should conform to the following conditions:
Follow these guidelines for grouping actions (figure 5):
Order with Groups
Follow these guidelines for ordering groups (figure 6):
The refresh action enables users to update data across tables, portlets, tabs, or entire pages. Place this action consistently following the standards outlined previously in the General Actions section. The following table provides examples of refresh actions:
The reset action enables users to quickly set all editable fields, choice lists, and so on back to their default state without manually changing each component. This model is recommended for basic or complex form pages or dialog boxes, but discouraged for smaller, dialog box-based forms where the number of fields does not warrant it.
|Page Model Details|
The Page model is the default model and the most common way of architecting pages. Each change of context refreshes the entire local area with a new page. This can be done through actions, processes, drill-down pages, and so on. You should be aware of some additional considerations when using this model as it relates to page actions.
Users drill down from an originating page (often a summary table) to a detail page. This model is recommended when an object or process is complex, when there could be many actions performed, or when there are a variety of heavier components (large tables, tree tables, subtabs, and so on). You should use any relevant contextual information from the originating page, along with a breadcrumb trail and page return actions.
When pages have both a read-only and editable version, the page action buttons are Edit and Done. Done navigates users from a read-only page to the originating page (figure 109), and Edit gives users an editable version of the page with Save buttons present. For more information about save actions, see the Save Model Guideline.
Read-Only Pages with Editable Sections
When you use pages that are read only and edit them at the section level, the only page-level button is Done. The Edit buttons are used in the appropriate sections to accommodate changes (figure 12). For more information, see the Secondary Windows section of this guideline or the Save Model Guidelines.
Note: If the content being edited at the section level requires another drill-down page instead of a dialog box, consider using subtabs or another mechanism.
Updatable Summary Pages
Some pages may be composed of updatable tables, master/detail layouts, and so on, meaning that they can be updated without navigating or drilling down. In these cases, do not use the Cancel button. All changes are cached until the explicit action (Save or Submit) is selected (figure 13). For more information about save actions, see the Save Model Guidelines.
For flows where you must use an explicit action button other than Save to signify the completion of a flow, Done is the required page action.
|Dynamic Tab Model|
The Dynamic Tab model enables users to open multiple pages concurrently. For more information on the Dynamic Tab model, see the Introduction to Work Areas Guideline.
Read-Only Dynamic Tab
When a dynamic tab is read-only, the page buttons may include Edit (if appropriate) and Done (located in the page header region). The Edit button opens a new tab for the selected object in Edit mode. The Done button closes the read-only tab (figure 16). Once the read-only tab is closed, the most recently active tab becomes active again.
Editable Dynamic Tab
When pages in a dynamic tab are editable, the page buttons below the tab are Save and Close and Cancel (figure 17). Either button closes the tab, and the most recently active tab becomes active again. Other final actions such as Submit are also acceptable. For more information, see the Final Actions section under General Principles in this guideline.
Note: Closing page actions (for example, OK, Done, and so on) are limited to the top level of the tab, and you should not use them on drill-down pages from a dynamic tab because duplicate actions at different levels can be confusing and leave users wondering if the action applies to the whole page or only a section.
Dynamic Tabs on Read-Only Pages with Editable Sections
When pages are read-only and you edit them at the section level, Done is the only page-level button. The Edit button is located at the appropriate section levels and opens dialog boxes to accommodate changes. For more information, see the Secondary Windows section of this guideline or the Save Model Guideline.
Note: If the content that you are editing at the section level requires another drill-down page or any type of subflow processes, this method is strongly discouraged.
The following section provides details for actions performed in secondary windows, which can be used in either the page model or dynamic tab model. For more information on secondary windows, see the Secondary Windows Guideline .
Modal Dialog Boxes
Modal dialog boxes prevent users from interacting with the primary page until they take action or close the dialog box. In these cases, the page buttons are generally OK or Cancel, and you should use them when a decision needs to be made before moving back into the mode of the originating page. In some cases, only the OK button or only the Close icon may be appropriate.
The default and most common buttons are:
The following buttons may be appropriate in some contexts when the application is asking a question that requires a yes or no decision:
Note:You can also use the Next, Back, or Record Navigation widgets if the window is part of a train or stepped flow. You can use the Submit button if the dialog box launches a process.
Modal Transactional Windows
A transactional secondary window is generally a modal window generated from a primary page that enables users to interact with transactional data (similar to the page model described previously). You complete transactions in this window before returning to the originating page.
In some contexts, such as certain Create, Update, or other process flows, users may not need to drill to another page to complete the transaction. If the answer to the following questions are Yes, the solution may be the right one. Otherwise, consider using the drill-down and detail page model previously discussed.
Modeless Dialog Boxes
Modeless dialog boxes enable users to interact with the primary page content while the dialog box is open, providing them with contextual information.
Note: You can also use the Next, Back, and Record Navigation widgets if the window is part of a train or stepped flow. You can use the Submit button if the dialog box launches a process.
Here are some current examples in use. This list does not reflect the full range of appropriate uses:
You can use a separate browser window to display the context for the primary window, providing that the windows do not need to interact with each other.
By default, no buttons are loaded onto these external pages. These external pages (not part of Oracle) will be browser windows, and closing these window is done by clicking the X at the top of the browser widow. In some situations, you can use Close as a button if appropriate. See Secondary Windows Guideline: External Windows for more information.