Interapplication Navigation

Last Updated 09.28.03

General Description

The primary goal for the BLAF guidelines is to provide a common user experience throughout Oracle Web applications. Enforcing standards for navigation between these applications, as well as other types of applications (external Web sites, Java applications, etc.) is essential to achieve this goal. Interapplication navigation points used within BLAF applications are as follows:

Navigation between BLAF Applications and Oracle Applications Portal
Navigation between BLAF Applications
Navigation between Forms and BLAF Applications
Navigation from BLAF Applications to External Web Sites
Navigation between BLAF Applications and Third Party Applications Using Web ADI

Guideline Attributes

Spec Version # - 3.1
Spec Contributors - Betsy Beier, Radhi Parekh (WebADI), Mervyn Dennehy
UI Models - all models
Example Products - all products
Related Guidelines - Navigation Between Applications and the Portal: Content Container, Global Button - Return to Portal, Application Switcher, Related Links/Shortcuts
WebADI: Messaging Templates, 2 Step Process Page Templates, Step by Step 3[+] Page Templates, Processing Templates

Interaction and Usage Specifications

Navigation Between BLAF Applications and Oracle Applications Portal

BLAF guidelines provide navigation methods for two-way navigation between the Oracle Applications Portal and BLAF applications.

Portal to BLAF Application

The Oracle Applications Portal is a launching pad to many applications, content and other Web sites. The portal contains portlets with different types of application-specific content, such as a status summary of a project, and more general content, such as weather reports. Many of the portlets provide access to BLAF applications.

There are two common portlets that provide access to BLAF applications, the "Favorites" portlet, a customizable portlet where a user can link his/her frequently used applications and/or Web sites, and the Applications menu portlet, which lists all the available applications the user has privileges/security to access.

A user may also access an application from an application-specific portlet. Individual product teams may provide a specific portlet(s) that allows quick access to data elements and functionality provided within the specific application.

BLAF Application to Portal

All BLAF applications provide navigation back to the Oracle Portal by means of a global button, called "Return to Portal." See Global Button Guidelines for details.

Navigation Between BLAF Applications

There are two methods for integrating diverse application functionality: by creation of a single application, or by providing navigation methods between different applications.

Integrated Applications

When modules or applications are integrated, the experience should be seamless to the user. If the business decision is to integrate applications, the tab/navigation structure should be reconsidered with respect to the combined functionality. Also, the branding of the product should remain constant throughout the integrated product. See the Introduction to BLAF Applications for an overview.

Separate But Related Applications

Many times applications share related functionality, but each application has its unique functions as well. Integrating these applications as one would make the resulting application too cumbersome, and overload the user with too many functions, content and options.

In this case, applications need to provide a simple method to cross reference related applications. Some suggested solutions for this type of interapplication navigation are:

Use of an Application Switcher. With this method, users select another application from a choice list.
Use of a Related Applications Content Container: With this method, Related Links/Shortcuts are placed in a Content Container on the home page of each application. Usage guidelines are as follows:
- The content container title is "Related Applications"
- The content container title must have the related applications icon.
- The content container must appear on the home page of each related application, to enable navigation back and forth between applications.
- If the home page contains more than one content container in the third column, the related applications content container is always the top-most container.
- If within the application at a lower level in the hierarchy of information it is appropriate to provide links to related applications (given the relative nature of the specific task flow at hand, and another task flow in another application), the "Related Applications" content container may be used at this lower level instead. All the above guidelines as mentioned above apply.
- Instruction text may be used in the "Related Applications" content container if necessary.
- Other related links/shortcuts may be provided in the "Related Applications" content container if necessary. Some links may take the user to a specific task within another application.

Navigation Between Forms and BLAF Applications

While many Forms applications are transitioning to BLAF (html), there needs to be a solution for launching a BLAF application from Forms, and vice versa. This guideline should be used when a Forms application is transitioning to BLAF, and the entire set of functions have not yet transitioned.

Opening a BLAF Application (Page or Pages) from Forms

A BLAF page or set of pages launched from Forms should ideally be a complete replacement of a Form, not a subset of functions from a Form. If this is not possible, the level of functions placed within the BLAF page(s) should be able to be performed independent of any other transaction.
A BLAF page or set of pages can be launched from:
- the Forms Navigator
- a button and/or menu entry within a Form
Since Forms runs in the context of a specific responsibility, the BLAF page(s) (launched from a Forms application) will be run in the same responsibility as the current form.
Functions provided in the HTML pages may be either for inquiry (read-only) or transactional. Consider providing transactional functionality only if all of the following are true:
- The user is extremely proficient in Forms.
- The user runs Forms applications on a daily basis and is comfortable navigating back and forth between them.
- The BLAF application has many points of Forms integration (the interaction is common in the BLAF application).
- Data does not need to be synchronized when the user returns to BLAF to continue performing tasks.
- After the user completes tasks in the Forms environment, the only logical page to return to is the page where the user launched the Forms application.
Specific Forms functionality that has been translated into BLAF page(s) should not launch directly from the portal. Typically the functionality is only applicable when the form is first launched.
When transitioning functions from Forms to BLAF, it is important to analyse whether a tabbed environment (in the BLAF page[s]) is necessary. Typically, the functions being transitioned do not warrant a full-fledged tabbed environment, and should use the "No Tabs" look. See Tab/Navigation: No Tabs for examples.
The Help system and Preferences/Profiles between Forms and BLAF applications should ideally be integrated, so that the user has a seamless experience in the integrated Forms/BLAF cases.

Forms to BLAF to Forms Page Flows

In this flow, the user is in Forms and launches a BLAF page or BLAF pages from the Navigator window, Form Button and/or Menu Entry:

Second Browser window opens. Modal script is on window.
- Modality: Modality of the secondary browser window is mandatory. Exceptions to this standard TBD.
User performs tasks. Secondary browser window may be replaced several times if there are multiple pages. Tertiary modal LOV window may be opened as well.
User finishes task, decides to go back to Navigator/Forms, and:
- Closes the window with the browser "X" function
- Closes the window by right clicking on the Browser Title bar area
- Selects a Global "Close Window" button. This button replaces the "Return to Portal" functionality. The "Logout" functionality is not available.
  - The default global buttons for BLAF page(s) integrated with Forms should be (in order from left to right): Close Window, Preferences, Help
  - See the Icon Repository: Global Icons for the global Close Window icon.
- In some cases, there may be a page level "Finish" button which closes the BLAF page. This button should only be placed on a page where applicable, and the user has completed his/her tasks.
If user performed transaction in BLAF pages, the user must then select a "Synchronize" button in Forms to see the latest data.

Forms to HTML Page (BLAF) and Back to Forms (Transactional)
(The functionality in HTML is transactional)

Forms to HTML Page (BLAF) and Back to Forms (Inquiry)
(The functionality in Forms is only inquiry [read-only], so no synchronization is required on return to Forms. See the flow steps above.)

BLAF to Forms to BLAF Page Flow

When launching a Forms application from BLAF, use the following flow:

The user launches the Forms application using a page- or section-level action/navigation button, or a functional icon in a table. The button label follows the syntax "Advanced {FunctionName}", such as:
- Advanced Order Entry
- Advanced Account Management
- Advanced Part Configuration
User performs task(s) in separate Forms window. Data is saved to the database.
User exits Forms by:
- Closing the Forms window
- Exiting Forms
- Toggling back to the BLAF browser window
On return to BLAF application, user can select "Synchronize" to update the page with the latest data from the Forms application.

HTML Page (BLAF) to Forms and Back to HTML (Inquiry and Transactional)
(The functionality in Forms may be either inquiry [read-only] or transactional)

Navigation From BLAF Applications to External Web Sites

In few specific contexts, it may be appropriate to have a link to an external Web site from within a BLAF application. In this case, place a related link in a Content Container, with the title "Related External Links" or "Related Links" (if mixture of internal application and external links.)

When an external link is selected, the external Web site is launched in a secondary browser window, to ensure that the state of the instantiating application is preserved (i.e., login status, data state is not disrupted.)

Navigation between BLAF Applications and Third Party Applications Using Web ADI

Web ADI (Web Application Desktop Integrator) allows a user to create mapping templates and layouts to import and export data in and out of third party applications, such as Microsoft Excel. Once the data has been imported into the third party application, the user can take advantage of the functionality that is provided within that application. Also, within the third party application, users can access functionality from BLAF HTML pages, such as a List of Values (LOV).

Heuristics for Use of Web ADI

The following heuristics help decide when it is appropriate to use Web ADI and Excel with an existing BLAF application.

When to use WebADI and Excel:

Users must have IE 5.0 or Excel 97 or higher. Both are required for WebADI.
High volume, production data entry. Large scale means a lot of records each of which has many fields (e.g. 50 to 100+ rows with 7+ columns). A good example is transcribing a college applicant's paper application into the computer. There are clerks who spend days doing only this. Each application has a lot of fields. ADI provides a good balance of LOV validation and a very large single form.
Large scale data analysis: Large scale means working across time periods with a lot of increments. For example, doing planning over a 2 year period where you want to see each month as a column. 24 columns in HTML would result in a lot of horizontal scrolling.
Any time you want to leverage the analytical or ad-hoc powers of Excel. If you wanted to bring down a lot of data rows to use to create Excel charts for a PowerPoint presentation, ADI would be helpful.
Anytime high flexibility is needed in data entry. Using the transcribing paper applications example above... Clerks might want to do multiple passes when entering in a large set of paper applications. So, you might want to enter in all the names and addresses off of your stack of applications and then go back and enter more details in another pass. It could be that you want to establish records for all the applicants first and then enter in the bulky data later (or through OCR). Excel would give you the flexibility to work on the spreadsheet for a while, save it for later and then do a bulk validation once you are finished on the spreadsheet.
Anytime a user may want to do data analysis or data entry in disconnected mode.
Use WEB ADI when the user already has existing spreadsheets in Excel that they will want to leverage. Often existing spreadsheets have individual columns that are quite complex, are crosslinked to other spreadsheets and/or have numerous formulas.

When not to use WebADI and Excel:

Users will not have IE 5.0 or Excel 97. Both are required for ADI.
Low volume data entry (e.g. 0-50 rows x 5 columns worth of data).
Data requiring immediate and forced validation. Excel lets you put values in a field without consulting the LOV. These fields are validated when the spreadsheet is uploaded but there can be a time lag here.
Infrequent and irregular usage (e.g. less than 1 hour per week on average). While it is not difficult to setup ADI, it is more complicated than launching a Web application.
When users will not have access to some sort of training. Before effectively using WebADI, users need to understand that Excel will behave somewhat differently than usual. They will have to know that the data is not in the database until they "Upload" data. They need to know that double clicking on a field will bring up an LOV. Users will need some training on the system (either in person or via online help) to be able to use it effectively. For the experienced Excel user this could be a dismissable help file that opens up when they first use a WebADI spreadsheet. For the unsophisticated Excel user this would involve some hands on training.

Web ADI Flow

The flow for use of WebADI with Excel or other third party viewer is as follows:

The user launches WebADI from a BLAF page by selecting a table-level button. The button label specifies the function to be performed and the target application name. The syntax is "{Edit | Create} in {ApplicationName}". For example, if the function is to:
- Export data for manipulation in Excel, the label should be "Edit in Microsoft Excel".
- Create a new Excel worksheet, the label should be "Create in Microsoft Excel".
The viewer application opens in a separate window, either with exported data or with a blank document, depending on the action selected in the BLAF application.
The user edits/enters data in the document, and then opens the Oracle menu and selects "Upload".
If upload parameters are required, the user is directed through a 1, 2, or 3[+] step process in a secondary window. The number of steps depends on the complexity of the upload parameters. See the related template guidelines for more information on designing these pages. On completion of the step-by-step process, the user selects the Upload button to execute the upload as specified.
A processing page appears, indicating the data upload time in a status bar. The processing page remains on screen until the upload is completed. See the Processing Templates guideline for details. If errors occur, an error message page appears with a description of the error and a "Fix Errors" button:
- If the error(s) occurred during upload, the user is returned to the upload parameters process, where errors are marked inline. See the Messaging Templates guideline for details.
- If errors occurred within the viewer application, the secondary window closes and the errors are detailed in the header region of the viewer. In this case the user must first correct the errors and then restart the upload as described above.
If the data is uploaded successfully, a confirmation page appears. The user then closes the secondary window to return to the viewer application.
When the user returns to the BLAF application, the user can select a "Synchronize" button to update the page with the latest data. Otherwise the new data is displayed when the BLAF application is next launched, or the page is reloaded.

WebADI Upload Data Flow