RCUI Document Version 5.1.0 for Oracle® Fusion Middleware 11g Release 1 Patch Set 1 (22.214.171.124.0)
A Secondary Window appears on top of the main window. FusionFX products use secondary windows to display inline selectors, dialog boxes, note windows, and content external to the application.
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:
||Inline selector window.
||Launch element for inline selector windows.
||Modal or modeless dialog.
||Modal or modeless dialog (without action buttons).
The primary uses of each type of secondary window are as follows:
- Inline Selectors: Display a list of options or values.
- Modal Dialogs: Perform subtasks, and display messages.
- Modeless Dialogs: Set properties, and display messages.
- Note Windows: Display embedded Help information.
- External Windows: Display a multi-page Help system, external applications, or Web sites.
The method used to dismiss each type of window affects the type of content they may contain:
- Inline Selectors and note windows have no controls to dismiss the secondary window. Instead, users dismiss these types of secondary windows by clicking anywhere in the main window or performing an equivalent keyboard action. Consequently, they can only be used for read-only content, because users have no way to confirm or cancel changes made within the secondary window.
- Modal and modeless dialog boxes may contain both read-only and editable content. They contain at least one control to dismiss the secondary window, and save edited content if necessary.
- External browser windows are fully controlled by the browser and external application or Web site. They may contain both read-only and editable content, but changes made in the external window should have no effect on the originating FusionFX application. Users should be able to close either the external window or the base page without any loss of data.
An inline selector is a selection panel that provides contextual information for an object or a quick in-place selection mechanism for a field on the primary page. The selection panel supports both single and multiple selections.
Note: In ADF Faces, inline selectors are represented by the "popup" and "showPopupBehavior" components.
Inline selectors are used in the following components:
See the individual component guidelines for more details.
Toolbar Button with Inline Selector
- Inline selectors may be launched by clicking a launch element next to a component, or by moving the mouse over a component. Product teams should use a drop-down arrow as the launch element for inline selector buttons.
- Do not use editable fields inside an inline selector, because inline selectors do not provide an explicit method for the user to apply or cancel changes.
- Inline selectors size to their content. The recommended maximum size is one-fourth the width of a maximized browser window at 1024 x 768 resolution.
- Do not truncate or clip content; users must be able to see the complete name of each entry.
- Allow for 100 percent expansion in translation—up to the full width of the browser.
- The user closes the panel and confirms the selection either by selecting a value using the mouse or pressing Enter. If select-many is supported, clicking outside the panel or pressing Tab or Esc exits the panel.
- The user closes the panel without selecting an option either by clicking anywhere outside the panel without first making a selection, or by pressing Tab or Esc to exit the panel.
Dialog boxes display subtask details, property sheets, or messages.
Dialog boxes may be modal or modeless:
- Modal Dialogs: Must be closed by user action before the user can continue work on the main page.
- Modeless Dialogs: Allow users continued access to the main page without closing the dialog box.
Application subtasks can be performed with dialog boxes, a new task page, a main page refresh, or a guided process (train/wizard).
- A dialog box should not be the primary interface for the user; it should only be used for secondary tasks that are supplemental to the main page.
- Dialog boxes should be used for only a small number of subtasks on the main page. If a page requires many dialogs, reconsider the task flow; the page may be too complex or the application hierarchy may be too flat. For example, when object information is entered very frequently, it may be more efficient to allow the user to enter the information inline on the page rather than in a dialog box. Likewise, when object information is entered very infrequently and doesn't require context from the main page, it may be simpler to move this information to a separate page rather than keeping it in a dialog box.
- Dialog tasks should be self-contained and should not call pages for unrelated tasks or processes.
- Dialogs should be used for actions or information that are contextual to the current page and not global to the entire product.
- A dialog box should be used when it is useful to refer to the main page while performing a subtask. For example, when entering details of a calendar appointment in a dialog, it is useful to see the appointment in context on the calendar on the main page.
- A dialog box can be used for subtasks that are done either often or seldom, without causing problems, unless the information is highly complex.
- A dialog box can contain low or high levels of detail. Nested dialogs can be launched from other dialog boxes as needed to progressively disclose higher levels of detail. For example, a dialog box that shows user options may launch another dialog with advanced options that are pertinent to less than 20% of all users. However, it is recommended to nest no more than three levels of dialogs; that is, if dialog A launches a second dialog B, avoid having a situation where dialog B would launch a third dialog C.
- A dialog box should be used for subtasks with a low or medium level of complexity for application users. For subtasks with a medium level of complexity, dialogs may provide a small amount of help text to guide a user.
- Dialog boxes may grow up to 100 percent in width when translated into certain languages. Thus, the recommended size of a dialog is no more than half the width of the screen in US English, that is, 512 x 384 pixels at 1024 x 768 resolution.
- It is recommended to show the dialog offset from the launch element when it is first launched.
- Dialog box use should be consistent throughout the product. If a dialog flow is used for a specific task (like Create Objective) on one page, then that dialog should be used for the same task on all other pages.
Modal dialog boxes are used to display messages or for subtasks that must be completed before the user continues with the main task.
- To help users maintain context, avoid using more than three levels of nested dialog boxes.
- Keyboard focus should be placed on the first editable field. If the information is read only, keyboard focus should be on the default button.
- Modal dialogs with editable content—where the user edits information in the dialog box and must either apply or discard those changes—should have a minimum of two action buttons: an acceptance button, (frequently labeled "OK" or "Done") to accept changes made in the dialog and close the dialog box, and a rejection button (frequently labeled "Cancel") to discard changes and close the dialog box. This type of dialog box should not include Yes and No buttons. If additional action buttons are needed, place them before the acceptance and rejection buttons. See Buttons in Dialog Boxes in the Buttons guideline for placement recommendations.
- Modal dialogs with read-only information should have a single action button (frequently labeled "OK" or "Close") that closes the dialog.
- Modal dialogs are also used for messages that require a response from the user:
- When users must choose whether to proceed with an action, the dialog box should contain Yes and No buttons.
- When users must choose between a positive action, a negative action, or no action, the dialog box should contain Yes, No, and Cancel buttons, or buttons with descriptive labels that perform equivalent functions. For example, if users have unsaved changes on a page and try to navigate to a different page, they may be presented with three options: save changes and go to the new page, discard changes and go to the new page, or cancel navigation and return to the originating page. In this case, descriptive button labels such as 0Save Changes" and "Discard Changes" are preferred over "Yes" and "No".
- An optional Help button may be included to launch context-sensitive help in an external window. See the Iconic Help Button section below.
Modeless dialog boxes are used to display messages or subtasks, or property sheets that can be edited based upon selections on the parent page.
Modeless dialogs follow the same guidelines as modal dialogs except as specified below:
- Modeless dialogs should have an additional action button (frequently labeled "Save" or "Apply"), which accepts the changes made in the dialog box without closing the dialog box. This button should be disabled until the user makes changes.
- Modeless dialogs that contain read-only information should have a single action button (frequently labeled "OK" or "Close") that closes the dialog box.
- It is not recommended to nest modeless dialogs (that is, call one modeless dialog from another) because it makes the task hierarchy unclear.
By default, dialog boxes are positioned in the center of the browser window when they are launched. Application development teams can launch a dialog box in a different position as needed. Recommendations are as follows:
- Where possible, dialog boxes should not obscure the launch element:
- Dialog boxes should initially appear after and below the launch element at sufficient distance to leave the entire launch element unobstructed.
- If there is insufficient space in the window to display the dialog box in the initial position without obscuring the launch element, the dialog box may be placed below and before, after and above, or before and above the launch element to uncover it.
- If the dialog box is so large that it obscures part of the launch element regardless of position, it should be placed to maximize exposure of the launch element.
- If the dialog box is launched by a drag gesture on the primary page, the dialog box should be positioned at the final position of the mouse cursor.
- When a dialog box is launched from another dialog box, it should be positioned in the center of the previous dialog box.
Title bar text identifies the dialog box or the task the dialog box is performing.
- Title bar text should have the same syntax as headers. See the Headers usage guideline.
The iconic help button displays context-sensitive Help on the dialog box.
- The iconic help button should be used if context-sensitive Help is available for the dialog.
- Context-sensitive Help is recommended for complex dialogs.
The iconic close button closes the dialog box without saving the changes in the dialog. It provides the same function as the Cancel button.
- Do not use an iconic close button when the result of closing the dialog box is unclear. For example, in a Processing message, users may not know whether closing the dialog box affects the transaction being processed.
- Most modal dialogs do not require an iconic close button because the user is forced to commit or discard their changes using action buttons. However, if there are no action buttons in a modal dialog, the iconic close button must be present.
Tabs divide dialog content into multiple sections that can only appear one at a time.
- Use tabs if it is necessary to break down large amounts of information.
- Use a minimum of two tabs in a set.
- The maximum number of tabs depends on the complexity of the task, but the dialog should not exceed 50 percent of the screen width when the tab set is displayed.
- When the user closes and then reopens a tabbed dialog, it is recommended to show the tab that was last active before the dialog was closed.
- For more information, see the Tabs guideline.
Action buttons act upon changes in the dialog.
- Omit action buttons if an action within the dialog content area applies a change, such as selection in a table. In this case the iconic Close button must be displayed, so users can exit the dialog box without changes.
- The maximum number of buttons depends on the effect of button text length on dialog width. The dialog should not exceed 50 percent of the screen width.
- If required fields exist, the OK (acceptance) button should be disabled until the required fields are filled in.
- Button labels should follow the guidelines in the Buttons guideline.
- If the "OK" label is unclear or inappropriate for ending the task performed in the dialog, the OK button may be replaced with another button that is more appropriately labeled.
- When a dialog has additional options that are not mandatory, or are considered to be advanced options that are relevant to less than 20% of all users, an "Advanced..." button should be placed in the context of the information that has additional options. The button could appear within a form layout or within a subheader depending on the content of the dialog. The Advanced button would launch a modal dialog containing the advanced options.
- Most dialogs have a default action button that can be activated using the Enter key. The default action button should generally be the OK button or equivalent. The Cancel button or equivalent may be assigned as the default action button when there is a high risk of loss of data.
Allows users to quickly increase or decrease the size of a dialog box to view a desired amount of available information.
Dialog Box Showing Resizer
- Resizing is off by default.
- Dialogs containing simple, single-column forms do not require resizing.
- The initial size of each form element should be large enough to contain most data values, with room for 100% expansion after translation. The Resizer allows the user to allocate more or less space for necessary elements.
- The user should not be required to resize in order to be able to see everything in the dialog, or to see everything in the dialog box at a usable size.
- The default size of the dialog should provide adequate space for all of its containing elements without causing the dialog to scroll.
- The default size of the dialog is the minimum size; however, product teams may set the default size to be larger. Users are not allowed to resize dialogs smaller than the minimum size.
- Having the Resizer does not nullify the recommendation that dialogs should be compact. The default size of the dialog should be no larger than half the size of the browser window in width and height.
- Product teams may turn on the Resizer when the dialog contains components that typically require more room to display, such as tables, shuttles, trees, tree tables, and multi-column layouts.
- When the Resizer is on, the components inside the dialog should be made to stretch or shrink to accommodate the resizing, rather than allowing the dialog to scroll when the components do not fit within the resized dialog.
Resizing a Dialog Box (with outline showing projected resize of the dialog)
Resized Dialog Box
FusionFX products open external browser windows to display content that is independent of the starting application.
An external window may be used for a Help system that does not require synchronization with the main window.
Oracle Help in External Window
- External windows are used to display content from outside the application.
- External windows may be used to compare options that can be used independently of the base page.
- In most cases, launching a second external window should replace any existing external window that was launched from the application to avoid cluttering the user’s desktop with too many windows. However, when performing comparisons between two objects, it is useful to launch the second external window alongside the first.
- The text in the external window title bar should match the primary header in the external window. See the Headers guideline for more information.
Note: Firefox 2.x inserts the secondary window URL before the title text set by product teams, which can cause the title text to be hidden. To avoid this problem, product teams should display a read-only location bar in the window; the URL then appears in the location bar rather than in the window title bar. See DOM:window.open in the Mozilla Developer Center documentation for directions.
This issue does not exist in Firefox 3.x.