Last Update: August 12, 2024

Platform: Web

Designer: Kathrin Fischer, Matthias Stenzl

User Assistance Developer: Pierre Thomé

Intro

The message box is a special dialog that allows you to display messages to the user. In gerneral the message box is used to display information what is related to the entire UI, in comparison to a message pop up that is not related to a field on the UI, such as technical errors.

Formulate messages in plain language, describe the issue precisely, and suggest a constructive solution. Always help your user to recognize, diagnose, and recover from messages. Bear in mind that no message is always preferable to even a good message. When you design your apps, aim to prevent problems from occurring in the first place.

For some cases in SuccessFactors we rearranged the elements in the message container to improve the clarity of the UI component. The cancel button was moved to the left position for the primary action. Even when cancel is a negative path action, we decided to use the cancel button in the emphasized button style to give him more attention. The positive path action is represented by a transparent button and displayed on the secondary position.

Usage

You want to display non-field-related messages.
You want to interrupt the user while he or she performs an action.
You want to display error, warning, success, confirmation, or information messages.
You need to interrupt the user for some other reason.
You need the user to acknowledge the message.
You need the user to make a decision.
You want to display a short success message. (Use a toast instead. For more information, see message toast.)
You can show the message directly in a form field.

Types

The following categories of messages are available:

Error
Warning
Success
Information
Confirmation

Structure and Components

The message box contains the following sections and options:

Title text appears in the message box header.

This area contains the actual content of the message box.

The footer can contain one or more buttons. We recommend limiting the number to two: A primary action and a negative path action.

Behavior & Interaction

Always display a message box as modals. Message boxes can be relatively small in comparison to the entire screen size. There is no need to display a simple message in a full screen dialog. For messages which contains larger elements as lists, tables or forms use the sap.m.Dialog control. Smaller message can also contain a editible field (confirmation message with note).

For better readability, display a maximum of 7-10 words in one line. Keep the text short and crisp, longer sentences are more difficult to read. Questions should generally be formulated more generally. More than three lines of text make the content rather confusing. Use common sense information instead of technical details.

Use sematic color für Warnings (orange) for icon and seperators. Error messages uses the red color, Information messages blue and Success massages green. For more detail information about icon formats please go to the page Iconography – Horizon

Responsiveness and Adaptiveness

The message box what we are using in SuccessFactors has the same responsive behavior as the sap.m.MessageBox and the sap.m.Dialog control. The message box should only be opened in modal mode.

The of a message box is to

For more information, see the GL chapter of the sap.m.dialog.

UX Writing Guidance

When creating a message text:

Keep the length of the message text short and crisp. More than 3 lines are not read anyway.
If you have a choice, use a familiar term rather than a technical term.
Don´t use abbreviations.
Don't use synonyms.
Use active formulations.

The following links point to:

a chapters in the Frontify UX Guideline for additional information: About UX Writing
the page: SAP SuccessFactors HXM Suite - Product Assistance: SAP SuccessFactors HXM Suite

For questions to the UA Team, please use the following DL:

mailto:DL_6463A20EA1D4B3D3F6DA72BB@global.corp.sap

Each error message should give the reason for the error and the action the user can take to correct the error and move on.

Write friendly messages, not frightening ones.
Make your error messages clear, courteous, and useful.
Make your error messages positive and calm.
Write messages in sentence style.
Capital letter at the beginning, period at the end.
If there are two or more sentences in your message, separate them with periods.
Use contractions, for example, “can’t” instead of cannot.

If possible, use the positive instead of the negative.

Examples

Error Message

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div> <p>Select a team in the "Development" area. "Marketing"</p> <p>isn't assigned to this area.</p> </div> <div> <p>You can’t select a team in “Marketing” because it’s not assigned to this</p> <p>area.</p> </div> <div>Emotional Design: Positive User Experience</div> </div>

Warning Message

Use warning messages to:

Make the user aware of something that needs their attention
Make the user consider their action

Make sure you're using relevant action buttons.

Don't repeat the action button text in the question.

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> <div>Buttons</div> </div> <div> <div>You have unsaved changes. Your changes will be lost. </div> <div>You have unsaved changes. Are you sure you want to leave this page?</div> <div> <p>Using a relevant</p> <p>action button allows for a shorter text.</p> <p>The question is redundant.</p> </div> <div> <p>"OK" to acknowledge unsaved changes and continue.</p> <p>"Cancel" to not continue and keep working on changes.</p> </div> </div> <div> <div></div> <div></div> <div></div> <div></div> </div>

Success Message

Don’t write “successful” or „successfully” in your success messages. The message header and the message already indicate success. The words “successfully” or “success” are redundant
Use the present perfect.

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>Project has been created.</div> <div>Project was created successfully.</div> <div>The message header and the message already indicate success. The words “successfully” or “success” are redundant.</div> </div> <div> <div>Provisioning access has been removed.</div> <div>Provisioning access successfully removed.</div> <div>The message header and the message already indicate success. The words The words “successfully” or “success” are redundant.</div> </div> <div> <div>Email delivered.</div> <div>Email successfully delivered.</div> <div></div> </div>

Special Case: Success Messages for Operations

Operations such as validations, processes and imports require a special success message

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div> <p>Job completed with errors/warnings. [can only complete if there are no errors.]</p> <p>Job completed without errors.</p> </div> <div>Job successfully completed.</div> <div>Job ran without errors and is in status “Completed.”</div> </div> <div> <div> <p>Imported file validated.</p> <p>Imported file validated without errors.</p> </div> <div>The imported file has been validated successfully. No error was found.</div> <div>There might be a lot of ways in which the import can fail, but the user expects the software to work.</div> </div> <div> <div>All records processed.</div> <div>All records processed successfully.</div> <div>There might be a lot of ways in which processing a record can fail, but the user expects the software to work.</div> </div> <div> <div>Records processed with errors.</div> <div>Records successfully processed with errors.</div> <div>Some records had errors.</div> </div>

Confirmation Message

Change the title of the message box to the action that has to be confirmed, such as “Delete” or “Remove”.
Repeat the action in the primary button, for example, “Remove”. Don’t write “Yes” or “OK” for confirming actions.
Don’t write "Are you sure“ or “Do you really want to“ in confirmation messages. This makes users question their choice. If you want to start your message with “Are you sure”, you’ll probably want to write a Warning message.
If your target user is likely to see the message frequently, use a short form that’s easy to scan.

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div>Approve purchase order 12345?</div> <div>Do you really want to approve purchase order 12345?</div> <div>No need to question the user’s choice, text length</div> </div> <div> <div>Delete the item?</div> <div>Are you sure you want to continue to delete the item?</div> <div>If the user sees the message frequently, for example, when deleting something from a shopping cart, there's no need to question the user’s choice.</div> </div>

Information Message

<div> <div>Correct</div> <div>Incorrect</div> <div>Explanation</div> </div> <div> <div> <p>Mark the days on which you drove to your place of work in a company car</p> <p>or rental car.</p> </div> <div> <p>The days on which you actually drove to your place of work in a company</p> <p>car or rental car must be marked. Days on which you did not drive to your</p> <p>office, ride public transport, bike, carpool, or walk should not be marked.</p> </div> <div>Keep the message short. More than 3 lines aren’t read anyway.</div> </div>

Accessibility

Please follow the Web Accessibility Quick Guide

Resources

If you want to dive deeper, please follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

https://experience.sap.com/internal/fiori-design-web/message-box/#Messaging-FormFieldValidation2

https://wiki.wdf.sap.corp/wiki/pages/viewpage.action?pageId=2035285081