FusionGPS: Guidelines: Page Actions Guideline

Page Actions Guidelines
Version 2.0.0.0

Introduction

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.

Note: This guideline does not apply to messages and notifications. For more information about messages and notifications, see the Message Pattern Set and the Notifications and Approvals Pattern Set.

Contents

General Principles
Page Model Details
Dynamic Tab Model Details
Secondary Windows


General Principles

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.

	Editable with Save	Editable without Save	Read-Only	Open-Ended Flow (Editable)	Open-Ended Flow (Read-Only)
Dialog Box	Save and Close	OK	Done	Save and Close	Done
Page with Dynamic Tabs	Save and Close	OK	Done	Save and Close	Done
Page with No Tabs	Save and Close	OK	Done	Save and Close	Done

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:

General actions (menu) or record navigation (menu or buttons)
Final actions (buttons)

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.

Figure 1. Page header (general actions and final actions)

Final Actions

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:

Avoid hiding any final actions in an action menu or representing them as icons.
Use only contextually relevant buttons. Don't use buttons from summary pages that are not applicable.

Figure 2. Page-level final actions

The final actions buttons should generally follow in order of general actions, record navigation, and then final actions (figure 3)

Figure 3. Page-level button order

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:

When you can perform several actions on a page, use an action menu if possible. If you can perform one or two additional actions, use text buttons with no action menu as the preferred display method.
Use a visual separator between page actions and final actions.
Place the action menu to the left of the final actions.
If there are more than two important or frequently used actions, consider using a toolbar.
When an action menu is used in conjunction with additional text buttons, place the buttons to the left of the action menu (figure 4).

Figure 4. Page-level (other) actions

Grouping

Follow these guidelines for grouping actions (figure 5):

Place the actions concerned with adding, creating, and editing of the primary object at the top of the menu in its own grouping (separator line).
Place the actions concerned with deleting or removing of primary objects in their own grouping, using a separator line between groups.
Place any general functions (such as Print) in a grouping at the bottom of the menu.
Group other actions by related functionality where applicable (separator line).

Order with Groups

Follow these guidelines for ordering groups (figure 6):

Within the functional groupings, place more frequently used actions higher in the order.
If a logical order to the menu items exists in a grouping (for example, States, Countries, and so on), follow that order when possible.
Do not separate any menu items in sets of one. If you find that you have a few items that don’t fit with anything else, consider grouping these miscellaneous items together.
Do not place more than seven items in a menu grouping.

Figure 5. Actions menu

Figure 6. Examples of good and bad groupings

Refresh Actions

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:

	Usage	Example
Page	Text button
Portlet	Icon button
Toolbar	Icon button
Subheader and Sub-subheader	Text button	or

Reset 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.

Figure 7. Reset button on editable page using a form layout

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.

Drill-Down Pages

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.

Editable Pages
When users can edit pages using a drill-down action or an edit action, the page buttons are Save and Close and Cancel (figure 8). When users can edit pages but the changes are not saved until users initiate a final action on the originating page, the only action button is OK (figure 9). For more information about save actions, see the Save Model Guideline.

Figure 8. Drill-down page (editable page with save action)

Figure 9. Drill-down page (editable page without save action)

Read-Only Pages

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.

Figure 10. Drill-down page (read-only page)

Figure 11. Drill-down page (editable and read-only flow)

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.

Figure 12. Drilling down into a read-only page with editable sections

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.

Figure 13. Updatable Summary page

Open-Ended Flows

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.

Figure 14. Editable open-ended flow

Figure 15. Noneditable open-ended flow

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.

Figure 16. Dynamic tab on a read-only page

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.

Figure 17. Dynamic tab on an editable page

Figure 18. Dynamic tab on editable and read-only pages

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.

Figure 19. Dynamic tab on a read-only page with editable sections

Secondary Windows

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 .

Figure 20. Secondary window

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.

Button Behavior

The default and most common buttons are:

OK	Applies changes, closes the dialog box, or returns focus to the primary page
Cancel	Discards any changes, closes the dialog box, or returns focus to the primary page

The following buttons may be appropriate in some contexts when the application is asking a question that requires a yes or no decision:

Yes	Applies changes, continues the process, closes the dialog box, or returns focus to the primary page
No	Discards any changes, closes the dialog box, or returns focus to the primary page

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.

Would users benefit from the originating page context to make some decisions?
Is this a simple object or process without heavy components (for example, tables, tree tables, tabs, and so on)?
Can the information fit into a page that is roughly 384 x 512 pixels (the maximum size for a dialog box)?
Will users generally complete this flow or task in one session?
Do no other actions exist that would necessitate a lengthy actions choice list.
Can the information fit cleanly in a smaller window that does not scroll?
Can this process be achieved without additional subprocesses launched from this secondary window (such as with a list of values, color picker, and so on)?

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.

Button Behavior

Done	Closes the dialog box or returns focus to the primary page (used for read-only pages).
OK	Applies changes to the dialog box or originating page, closes the window, or returns focus to primary page (used for editable pages).
Create Another	Applies changes to the primary page and refreshes the dialog box for creation of a new object. Changes are not committed to the database until you use a save action on the primary page.
Cancel	Discards any changes, closes the dialog box, or returns focus to the primary page.

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:

External Windows

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.

About Oracle | Legal Notices | Terms of Use | Your Privacy Rights