Overview
This documentation describes the UI guidelines for the various types of messages seen in self service. It covers the UI guidelines for the following message types:
- Confirmation Message: Use to convey that a transaction was successful.
- Error Message: Use to convey that a transaction cannot be completed.
- Warning Message: Use to convey that the transaction may have completed successfully, but the user should review it and proceed with caution.
- Informational Text: Use to provide important or legally required information the user needs for completing the transaction.
Text Guidelines for Messages
In general, the text used in a message should always be a short, clear, and concise description of the information a user needs to know.
- Messages should contain as few words as possible.
- Messages should be direct imperatives; the word “Please” is unnecessary.
- The first letter of each sentence or phrase should be capitalized.
- If the message contains only one sentence, then no period is needed.
- Proper punctuation should be used if the message contains multiple sentences.
- Abbreviations should be avoided.
- The text should not refer to direction, color, image content, or any visual reference.
The amount of text needed to convey the message is typically determined by the type of message that appears.
- Confirmation messages should be short and concise, using just enough words to let the user know the action was completed. Since this type of message is usually short and not a complete sentence, a period at the end is unnecessary; however, the first letter of the phrase should be capitalized.
- Error messages should describe the problem encountered and tell the user, in as few words as possible, how to fix it. This type of message may contain multiple sentences, therefore, it should be punctuated correctly; for example, each sentence should be capitalized and each sentence should end with a period.
- Warning messages should let the user know that a problem may exist and what the outcome will be if they proceed. This type of message typically contains multiple sentences and, therefore, should be correctly punctuated.
Sometimes messages may also contain information that can be singular or plural, depending on the outcome or the results of the transaction. For example, the process may successfully save one or many rows of data. Avoid using counts if possible; however, if it is important to display how many rows were saved or processed, use a count with a description that conveys both singular and plural conditions.
In the following example, it is important to display how many performance documents were created because it is possible that not all documents were created. Since the outcome could be one or many, the word “Document” in the message can be singular or plural. In this situation, use an “s” in parenthesis (s) to indicate this condition without having to create two different messages.
Confirmation Messages
Confirmation messages convey that the action taken was completed successfully. Several different design patterns can be used for confirmation messages:
- Fading confirmation message
- Persistent confirmation message
- Confirmation message with alert
- Pop-up confirmation message
General Guidelines for Confirmation Messages
All confirmation messages, with the exception of the persistent confirmation message, should return the user to the page where they can select the next item in the list or the next action they will want to perform. This functionality will eliminate the need to navigate to the menu under most circumstances.
In the following example, the user selects the approval row from the Pending Approvals list:
The user is transferred to the transaction details, where they click the Approve button:
Once approved, the system returns the user to the Pending Approvals page and displays a Confirmation message. The user can select the next transaction in the list to approve.
Fading Confirmation Message
A fading confirmation message lets the user know that the action they just completed was successful and then it disappears from the page. It is commonly used to convey that a transaction was saved or submitted without the need for user interaction. This type of message is beneficial when the data on the page is editable or could be editable, thus allowing the user to interact with the page without having to dismiss the message or close a modal window. This message type is the preferred method for displaying simple confirmation messages on editable pages since it does not require user interaction. If the page is read only, then the persistent confirmation message style, covered in the next topic, should be used.
The fading confirmation message area appears at the top of the page and covers all panels, regardless of form factor or page layout. It overlays any existing data on the page, and the message is centered in the middle of the message area. The message appears on the screen for about 5 seconds before disappearing. The message can be dismissed by selecting the Close icon (x) in the message area. The message should be short and should fit on one line on the phone if possible.
Note: Accessibility mode is handled by PeopleTools for this type of message.
One-Panel Layout
Two-Panel Layout (left and right)
Small Form Factor Layout
Persistent Confirmation Message
The persistent confirmation message is physically part of the page and cannot be dismissed until the user leaves the page. Use this type of message when:
- The message contains more text then what can be easily read in 3 seconds (consider using the confirmation message with alerts in this case).
- The page is a confirmation page (read-only) and requires no further interaction from the user. Confirmation pages are typically used as the last step of a guided process or where there is not a page that the user can be returned to.
- The message contains information that the user may need to record or print, such as an order number, confirmation number, telephone number, or address that is not otherwise reflected on the next page.
The persistent confirmation message area appears at the top of the page and pushes down the content in the page or panel. Examples follow.
One-Panel Layout
Multi-Panel Layout
In a multi-panel layout, the message area pushes down the content in the transaction area (right pane) but does not push down the content in the left pane.
Two Panel Layout
Three Panel Layout
Small Form Factor Layout
Confirmation Message with Alert
A confirmation message with alert is a two-step message that gives the user the opportunity to cancel out of the action before it is confirmed. Use this type of message when:
- Data is being deleted from the database and cannot be undone. This is critical for Web Content Accessibility Guidelines (WCAG), which state: “Performing an operation where data is deleted and can’t be recovered should raise a pre-action confirmation message to make sure that you really want to do what you are about to do.”
- The user needs a way to back out of the action they selected before it is completed. For example, if the user accidently selected the wrong button and it is difficult or cumbersome to undo the action.
- Additional options can or must be done before completing the transaction. For example, entering comments before submitting a transaction.
The intermediary or alert message should appear in a modal window where the user has the ability to cancel the transaction or continue with the action they are performing.
Data is Deleted or Action is Difficult to Undo
After the user selects the action on the primary page, a message appears in a modal window, giving the user the option to back out and not delete this entry. This message should be as clear as possible, and it should be easy for the user to decipher the action they need to take. In the following example, the user would click the Yes button to confirm the delete action and the No button to cancel the action and back out of deleting the data:
Once the action is confirmed, a confirmation message should appear to confirm that the action was successful. In general, a fading confirmation should be used; however, a persistent confirmation message is also acceptable. In certain instances, it is also acceptable for no confirmation message to appear, although in this instance, it should be obvious to the user that the action completed successfully.
Data is Deleted or Action is Difficult to Undo in Small Form Factor Layout
Additional Input (such as Comments) is Available
In this example, once the user selects the action on the primary page, a modal window is presented that allows the user to add their comments before submitting the action. In this case, use a standard modal window with buttons at the top. One button should enable the user to cancel the action, and another button should enable them to complete (submit) the action.
Once the action is confirmed, the system should display a fading confirmation message indicating that the action occurred. It is also acceptable to use a persistent confirmation message if it follows the rules or no confirmation message if it is obvious to the user that the action was successful.
Error Messages
The system should display an error message if the transaction cannot be completed and the user must correct the error before proceeding. Errors can occur when saving or when a user enters an incorrect value in a field on the page.
General Guidelines for Error Messages
These are the general guidelines for error messages:
- Error messages should appear in a modal window.
- An OK button should be used to close the modal window and return to the page so the user can correct the error.
- The error should clearly describe the problem encountered and identify the field that needs to be fixed.
- If possible, the error message should provide guidance to the user as to how to correct the error.
- The cursor position should be set in the field with the error, if possible.
Example of an error message in a modal window issued when saving the page
Sometimes errors cannot be fixed and the user cannot complete the transaction. In this case, the message should instruct the user to contact their Administrator, as shown in this example:
Warning Messages
Typically, the system displays warning messages when a user saves or submits a transaction. Warning messages let the user know that something could be wrong or incorrect on the page and that they may want to reconsider before proceeding.
General Guidelines for Warning Messages
The general guidelines for warning messages follow:
- Warning messages should appear in a modal window with the ability for the user to continue with the action they are performing or cancel the action and go back to the transaction and review their data.
- An OK button should be available to let the user continue with the save.
- A Cancel button should be available to return the user to the transaction so they can review the data.
- The warning message should clearly describe the potential problem and provide guidance on how to address it, if applicable.
- Available options are Yes/No; Yes/No/Cancel; and OK/Cancel.
Examples of warning messages:
Additional Information for Messages
Additional information is any text that is necessary to have on a page that aids the user in completing the transaction. It is generally used to:
- Provide guidance on how a user can complete a transaction when it is not obvious on the page.
- Display text that is legally required to be included on a page.
- Provide disclaimer text about information on the page.
- Describe additional actions the user may need to take after the transaction has completed.
General Guidelines for Additional Information for Messages
These are the guidelines for additional information:
- The text should appear directly on the page and be left justified.
- If the text applies to the whole page or transaction, it should be placed at the end of the content with a line above the information text. The style for this text is “psc_text-disclaimer” (see the first example below).
- If the text pertains only to certain sections or fields on the page, the text should be placed under the appropriate section or fields (see the second example below). A line should be placed under the information text to separate it from any remaining page content that is below it, if applicable.
- If it is important to draw attention to the information text, an icon should be used and placed in front of the text. A line should appear above and below the text. The style for this text is “psc_text-important” (see the third example below).
Note: In accessible mode, Alternate Text for the image is mandatory. Additionally, if the text is important, a pop-up modal should be used in accessible mode.
This example shows text that is legally mandated and pertains to the Ethnic Groups section. Note that a line divides the message from the content section.
This example shows disclaimer text that pertains only to the Balance Information section:
This example shows an icon used to draw attention to important text:
Accessiblity Standards for Messages
To comply with Web Content Accessibility Guidelines, these additional requirements apply so that messages can be correctly read by a message reader:
- Any message text on the page should be put in a pop-up modal window for accessible mode; therefore, it needs to work like the PeopleTools MsgGet function. Using the MsgGet function will immediately announce and read the message area. This standard should apply to all confirmation messages, error messages, and warning messages. For fading confirmation messages, this construct is already built into the widget.
- In PeopleTools 8.55 for any on-screen message architecture, such as a persistent confirmation message, an Aria-alert or similar alert must be used so the message reader knows to read the message to the user immediately.