| Message Pattern Set |
| Confirmation | Version 2.0.0.0 |
||
|
|||
| Description | |
Confirmation messages inform users that an action that they, or the application requested, has completed. Confirmation messages appear in the most logical step in the flow after the action or application processing is done. For example, after a user deletes data or when a scheduled process completes, a confirmation message appears. In the case of navigating between transactional pages, a confirmation message appears on the destination page so that navigation is not blocked. No interaction is required from the user other than to dismiss the confirmation message, though teams may consider other action buttons to allow users to continue a flow. Confirmation messages can also appear in dialog boxes or inline. Confirmation message dialog boxes are modeless. Inline messages are set using the inline attribute on the ADF af:messages component. Important: A page cannot contain a combination of inline or dialog box-based messages. The choice is determined at the page level by the ADF af:messages component, which allows only one type on each page. Individual messages on the page use the af:message component. Confirmation messages are not used at the component level. A "Do not show this message again" style of feature is not supported in a confirmation message or by application end-user preference. |
Confirmation |
|||||
Tells users that the data they entered in a field violates a business, user interface (UI), or formatting rule, and explains how to correct the error. |
Yes |
No |
No |
No |
No |
Tells users about important consequences of a validation of a UI or business rule, or a process execution, that they must be aware of either now or later in the taskflow. Or Tells users about potentially dangerous or destructive consequences of their actions or the application's progress. May include a direct question asking users to decide between alternative actions before proceeding with their tasks. |
No |
Yes |
No |
No |
No |
Tells users about the status or changes of a business object, a page, or the application itself that was not initiated by the users and does not require any immediate actions to be taken by them. |
No |
No |
Yes |
No |
No |
| Tells users about the progress of an action or a process that they or the application initiated. | No |
No |
No |
Yes |
No |
| Tells users when an action or process that they or the application initiated has completed. | No |
No |
No |
No |
Yes |
| Determining the Need for a Confirmation Message | |
Use a confirmation message when users need to know that an action or process has completed and when no other obvious indicator can be used (for example, in a hidden area, multiple data deletions, and so on). Use confirmation messages consistently. Research indicates that users prefer to have more confirmation messages rather than fewer when important, nonobvious results are concerned and when complex or long processes are involved. Users may not be present for the duration of the entire process, so they also need a confirmation message that the process has completed. A process should not be allowed to end without the user confirming completion. See the Processing Message Pattern. You do not need a confirmation message if the result of the confirmed transaction is clearly visible on the page (for example, an action to add a new employee to a table that results immediately in a new row with the added employee visible).
|
| Pattern Sample | |
| Design Considerations | |
|
| Related Guidelines | |
| Messaging Usage Guideline | Guidelines for messages usage based on the Rich Client User Experience (RCUX) designs |
| Oracle Fusion Message Usage Guideline | Guideline about validation across different components in the Oracle Fusion Application's UI that explains when to use dialog boxes or inline messages |
| Secondary Windows Guideline | Guidelines for the secondary window component |
