The applications UI Shell is a page template specifically intended for use by application designers and developers. With its five areas (global, regional, work area information, local, and contextual), the UI Shell provides stability and consistency while allowing the flexibility needed to optimally support specific user roles and user tasks.

These usage guidelines help you decide what content to put in each area and what the interaction should be between these areas.

• Design Goals
• General Interaction
• UI Shell Layout Areas
  • Global Area
  • Regional Area
  • Work Area Information Area
  • Local Area
  • Contextual Area
• Regional vs Contextual
• Fusion Application Screen Types

The UI Shell areas support different aspects of the following design goals:

• Provide a cohesive user experience through consistent placement and behavior of user interface elements and seamless integration across applications, business processes, and user tasks
• Promote user productivity and efficiency by optimizing (reducing) the number of windows, pages, and clicks required to accomplish users tasks
• Provide common locations for basic functions and features
• Promote “discoverability” of features through visual affordances and common patterns
• Provide timely and relevant information supportive of users’ goals and tasks
• Support multiple modes of learning and task styles from task-based, object-oriented, and other conceptual models that user may have
• Provide personalized workspaces for end users to specify a user interface that accommodates their individual needs and preferences
• Maximize use of screen real estate to provide information within the context of users’ goals and tasks and avoid needless navigation
• Make the enterprise software experience comparable to the consumer website experience
• Make use of emerging standards in user interface technology

For more information on these goals, see the respective sections of this document (global, regional, local, and contextual).

The global area, across the full width at the top of the UI Shell, is stable, consistent, and persistent for individual users. The global area contains controls that in general drive the contents of the other three areas (regional, local, and contextual).

The regional area is in the left pane of the UI Shell. It has controls and content that in general drive the content of the local and contextual areas.

The local area is in the center of the UI Shell, where users do their work. The local area is the main work area and typically contains the transaction form with the menus and controls that enable users to be productive. Controls in and the content or state of the local area in general drive the contents of the contextual area.

The contextual area is in the right pane of the UI Shell, with controls and contents that in general are driven by controls in or the content or state of the local area although in specific cases, the contextual area can also, in turn, drive the contents of the local area (causing a local-area reload).

Of the five areas, the global area requires the least design because most of its UI controls are provided as part of the UI Shell, including:

• Branding (can be customized per app, if required, consistent with Oracle standards)
• Sub-branding
• Accessibility
• Personalization
• Administration
• Help
• Sign Out
• User Identifier
• Processing Indicator
• Home
• Navigator
• Recent Items
• Favorites
• Watchlist
• Tags
• Group Spaces
• Notifications
• Global Search

While these controls are provided and available, only the branding control is required in all but the Kiosk mode (the default branding can be customized as needed for or by the customer).

The regional area is located in the left pane of the apps UI Shell. It contains accordion panes with controls that drive the contents of the local area; that is, using a control in the regional area should in general result in refreshing, manipulating, or otherwise updating the local area. Users should get the sense, after extended use of an application, that regional area controls target the local area and its contents.

As a standard, the regional area is empty and closed when the local area contains the user home dashboard. In addition the regional area should be collapsed once users navigate to a detail page or subflow.

Determining Which Regional Area Panes to Include

What to include in the regional area should be determined based on what goals your users have in the current work area (which is the collection of task flows, involving a single key user object, that are perceived as an application or a major area of functionality within a complex application).

The regional area panes should provide controls and content that optimize efficiency and support your user goals by:

• Facilitating navigation between tasks or object instances
• Providing access to tools that are common across multiple tasks and instances within a work area

Figure 3. UI Shell regional area detail

Only one regional area accordion pane is defined as a standard for most applications: the Tasks pane. The Tasks pane appears in the top position of the regional area. All other panes are recommended but optional and should be used only when appropriate. Regional area panes should update, change, expand, or collapse based on what users are likely to want to do when they navigate to a work area.

• Tasks: Use to navigate to available task flows in a work area. See the following section on identifying tasks in the tasks pane. The Tasks pane is in the standard regional area pane in most applications.
• Regional search: Use for transaction searches across instances of the key user objects in a work area. Constrained to transaction data. Include if you expect users to search often within a work area (for example, for open vouchers). See regional and local area search.
• Quick create: Include if you expect users to create instances of objects outside the current work area on a regular basis. Enables users to create an instance of another object (other than the key object in the current work area) without having to leave the current work area.
• Navigation tree of object instances: Include if you expect users to need to access different instances of the key user objects in the current work area for reference or comparison (for example, salary or performance appraisals across several years in a compensation work area).
• Tool palettes: Include if you expect users to run specific reports, analytics, or other tools against instances of the key user objects in the current work area.

See Figure 1 for the location of the work area information area in the UI Shell template layout.

For more information, see the Introduction to Work Areas guideline.

The local area is where users do their work, where they create work units, ane where they are productive in a measurable way. For most of our users, how well and efficiently they use the local area determines how quickly they get through their work and how much they get compensated.

Keep in mind that because either the regional area or the contextual area, or both areas, can be closed by users, any controls and content that are core (that is, essential) to the completion of the current task should be in the local area. If any content or controls are important though not essential and located in either the regional or contextual areas, application designers and developers can choose to programmatically set the relevant area to be open as a default state when a specific page or task flow is in the local area.

Note: Because the local area is meant to contain only task flows, specific standards and guidelines on how to design the user interface to the pages in task flows are beyond the scope of these UI Shell usage guidelines. See related guidelines on page layout , work areas, and tables .

The remainder of this section describes guidelines on common interactions between regional area controls and local area containers, specifically, tabs.

The contextual area is in the right pane of the apps UI Shell, with accordion panes containing controls and content that are sensitive to the context shown in the local area so that as the task flows change and information is entered, the contextual area contents change and update accordingly. After extended use, users should feel like the contextual area is driven by what they are doing in the local area.

As a standard, the contextual area is not configured or defined when the local area contains the user home dashboard or other dashboard.

All contextual area panes are recommended as a guideline and should be used only when appropriate. In general, contextual area content has no significance or useful meaning to users outside the local area context.

Several examples when the contextual area is recommended:

• Decision assistance: Business intelligence data and other analytics, context-sensitve reference material
• Collection containers: Shopping carts and similar controls that collect instances selected from the local area (see the Contextual Container Pool pattern)
• Related links: Navigation to related tasks in other work areas

The content and controls should be contextually driven by (in increasing levels of specificity) the current task flow in the local area, the local area control (field, table row, cell, or other control) that has keyboard focus, the selected control, and the value entered in an editable control. Contextual area panes should update, change, expand, or collapse based on the current page, the control in focus, the selected control, and the current value of the selected control.