Message Usage Guidelines Print this Page
Version 2.0.0.1  

This guideline provides a decision matrix for the usage of inline or dialog box-based messages, and it outlines how validation works across different components so that teams can design a consistent messaging user experience for Oracle Fusion Applications.

 
Contents
 
Inline versus Dialog Box Messages
Return to Top

The Application Developer Framework (ADF) provides for inline as well as dialog box-based messages. The Message Pattern Set explains the use of each message type and the visual treatment. Use the following table to help decide where to use each option.

  Error Warning Information Processing Confirmation
Serious data or application errors or warnings requiring user response or help desk resolution

Dialog

Dialog

-

-

-

Errors or warnings when navigating or completing a heads-down task

Dialog

Dialog

-

-

-

Routinely occurring data validation or performed actions errors and warnings on same page

Inline

Inline

-

-

-

Warnings that require a question to be asked of users before continuing

-

Dialog

-

-

-

Infrequent warnings that explain the potentially destructive consequences of an action or process that users must know about

-

Dialog

-

-

-

Routinely occurring application, page, or business object changes that users may need to know about

-

-

Inline

-

-

Infrequent application, page, or business object changes that users may need to know about

-

-

Dialog

-

-

Progress of a process initiated by users or the application, whether indeterminate or determinate in duration

-

-

-

Dialog

-

Confirmations of an action taken by a user that is immediate, frequently performed, and have no visual indicator of change

-

-

-

-

Inline

Confirmations of an action initiated by users or the application that requires time to process, are infrequently performed, and have no visual indicator of change

-

-

-

-

Dialog

Confirmation of a navigation action between pages

-

-

-

-

Dialog

Keep these points in mind :

  • You cannot combine both inline and dialog box-based messages on the same page.
  • Use your choice of page or inline messages consistently across the flow.
Inline Messages
Figure 1. Inline messages

For more information and examples of inline messages, see the Message Pattern Set.

 
Validation
Return to Top

Oracle Fusion Applications product teams are responsible for the design of the validation of business and UI rules designed during the Applications Process Model functional design phase. Because of the technical nature of validation, the design is a collaborative process involving both product managers and application engineers.

In some cases, validation behavior is described in Oracle Fusion GPS messages (or other) patterns. If no such pattern or guideline is available, use this guideline to help design messages required by the product use case or business and UI rules. The following areas are covered:

Note: This guideline is based on the ADF validation framework and components and the Rich Client User Experience designs and guidelines. Other validations will need to be designed and coded. For more information about validation, see the Oracle Fusion Middleware Fusion Developer’s Guide for Oracle Application Developer Framework and the Oracle Fusion Applications Developer’s Guide.

 
Client Versus Server-Side Validation
Return to Top

Oracle Fusion Applications support client-side and server-side validation. A page may contain a combination of these two types of validation:

  • Client-side validation occurs in the browser with no round-trip required to the server. This allows for fast, performance-optimized validation. ADF provides a set of client-side validators and converters that fall into this category, and product teams can define others. Generally, this kind of validation is not suitable for interfield, page-level submissions and is not used for the validation of more complex business rules.
  • Server-side validation requires a round-trip from the browser to the server with business logic on the middle-tier using business rules to validate any submitted data. This is slower than client-side validation but allows for more complex processing of business rules, is generally more secure, and allows page design to be independent of any logic code.

With the exception of the ADF validators and converters that act when users enter data, all validation requires an explicit user action to act, such as canceling, closing, or navigating from a page or tab. These actions post data to the server.

 
Individual Form Fields
Return to Top

    Follow these guidelines for individual form fields:

  • Validate data when users leave the field.
  • Enable users should to complete fields on the current page in any order they want before need to submit the page using an action or navigate away from it.
  • Validate required fields (indicated by * symbols) and interfield dependencies when users submit a page using an action, such as Save, Submit, Publish, and so on.
  • Show error messages on editable fields using a component-level note window (figure 2). A list of these editable components includes a link to the field using the name of the field.
  • Design heads-down data entry tasks for validating fields when the page is submitted using an action button. Messages appear in a list (figure 3).
  • When component-level validation is not possible or for business rules that apply to the entire page, you can use a global message dialog box. This has no links to components, so name the fields with the errors in the message text to expedite resolution.
Component-level Message
Figure 2. Component-level message
Tables
Return to Top

Follow these guidelines for tables:

  • Show error and warning messages on editable fields using only a note window. A message list of editable components with messages includes links to the components.
  • Rows may be programmatically marked with an icon in the row header indicating an error if teams can determine how to do so (figure 4). Work with your application development team.
  • Individual fields should be validated the same way as form fields. Teams can convert entity level exceptions (that is, business rule dependencies) to attribute-level exceptions where possible.
  • For entity-level exceptions converted to attribute-level exceptions, tell users which fields have the error by naming the fields in the message text (figure 5). The application team can decide which field to show the converted exception on.
Table Row Indicators (Optional)
Figure 4. Optional table row indicators with an editable field error
Entity-level Validation on Table Row
Figure 5. Optional entity-level exception editable fields in a table row with optional table row header indicators
Page Navigation
Return to Top

Follow these guidelines for page navigation:

  • Navigating between pages should validate all editable fields on the current page, as if a final save or submit action was committed, before users can navigate to another page. Where component validation is not possible, name the fields that have an error or warning in the message text.
  • Do not allow navigation to continue until all errors have been fixed on the current page.
  • Use warnings each time users change data on the page.
  • If there is a risk of losing data when navigating or closing a page, then use the ApplCore and ADF page-level warning dialog box with a question and action buttons to enable users to understand the consequences and confirm their navigation intention. If you must use your own message, see the Save Model Guideline.
  • For confirmation messages used when navigating between pages, show the message on the destination page, so that the navigation is not blocked. For more information, see the Create in a Form pattern.

 
Tab Navigation
Return to Top

    Follow these guidelines for page navigation:

  • Require users to complete all editable fields on the each page when current. There is no out-of-the-box "hidden messaging" support from ADF for messages on hidden editable fields or nonactive train stops or tabs.
  • Enable users to perform submit actions only after editable fields are validated when the tab or train stop was current.
  • If validation errors or warnings occur on a hidden page, place an icon on the tab (figure 6) or train (figure 7) to disclose the location.
  • Use a page-level message to name the tab or train stop and fields with errors for any noncurrent tab or train stop. ADF provides a message for unsaved changes when navigating from a set of tabs. For more information, see the Save Model Guideline.
Icons on Tabs
Figure 6. Icons on tabs
Icons on Train Stops
Figure 7. Icons on train stops
Composite Components
Return to Top

Follow these guidelines for composite components:

  • For master-detail components, use an approach similar to that used with tabs. Validate each field as it is completed.
  • If the master field is the cause of the validation failure, use the same approach used for editable fields (figure 8).
  • If validation occurs on hidden details, place the icon before the master field and display validation messages on the editable fields when the master field is selected (figure 9).
Error on Master Object
Figure 8. Error on a master object
Error on Detail Object
Figure 9. Error on a detail object
Read-Only Components
Return to Top

    Follow these guidelines with read-only components:

  • Read-only validation of components is not supported. Instead, provide validation at a point in the task flow when users can correct editable fields.
  • Put dependent fields on the same page if possible, rather than across pages, and validate them on the same page.
  • When you cannot avoid dependencies across pages, use an in-field help note on editable fields to explain how the data will be used later, or use static instruction text explaining how to use the page or region, so that read-only situations can be anticipated later in the flow.
  • Use a page-level information message to tell users when a page changes to a read-only status and why it does so, if it is not obvious.
  • You can use status icons with tooltips to indicate errors, warnings, or information about read-only fields where appropriate. For more information, see the Fusion Icon Usage Guidelines. These are not considered messages.
 
Related Documentation
Return to Top
 
 
About Oracle | Legal Notices | Terms of Use | Your Privacy Rights