Messages appear in dialogue boxes and in the status bar. They inform users on different aspects: error conditions, warnings, success, infos. Therefore, it is important that the users understand these messages.
If the system detects an error, it displays a message either in the status bar or in a dialogue box, depending on the type of error. The message is to state the problem and to offer a solution so that the user can proceed without outside assistance.
Be as precise as possible! Messages should describe the situation which has occurred as unambiguously as possible. Be specific and address the problem in the user's terms. Avoid error messages which contain technical descriptions or explanations.
Offer the user direct support for the error recovery. Do not just state the problem, but rather indicate what needs to be done. If this is not possible, use a positive tone to explain the problem as precise as possible. You can provide additional support in parentheses, if known. Have a courteous and positive tone, rather than being imperious or condemning the user. Avoid the use of "may", "must", "should", "belong", "wrong", "insufficient", "incomplete", "not allowed", and so on.
Use a clear and simple sentence structure and only write complete phrases. Articles can be omitted; a verb (at least "is" or "are"), however, should always be present. Use present tense, if possible. Be consistent in your use of language; do not mix different languages.
Some more Don'ts...
Do not conclude the message with a period or with an exclamation mark. Suggestions for the error correction can be given in parentheses. Always leave a space after a period and never before. Do not use special characters such as < >, as they will not necessarily be known to the user; value specifications such as % can be used, however. Do not introduce or conclude messages with asterisks (***). Never put field names, report names and table names in quotation marks.
Figure 1: Structure of a message
Examples of Good and Bad Error Messages
The following topics list examples of bad and reformulated error messages (without comments) to illustrate the above-mentioned guidelines.
Messages Which can be Formulated More Specifically
Bad: Key is not in table
Bad: The cursor is not placed on a line which can be selected
Bad: Release order specifications incomplete
Messages to Be Formulated Less Ambiguously
Bad: The line is not in table 134
It would be better to explain this message in detail in a dialogue box or to name the reference to the individual entry fields in the long text.
Bad: Entries incomplete
Bad: No change
Messages Prompting the User
Bad: Deletion flag incorrect, only 'J', 'S', ' ' allowed
Bad: Postal code not entered or has incorrect length
Bad: Percentage rate must be smaller than 100%
Bad: No items selected
Bad: Release date entered incorrectly
Message Types and Error Groups
The messages in the R/3 System can be classified according to different types. The message type determines where the message is issued and how the system responds.
Messages which refer to errors, so-called error messages, can be grouped in terms of their contents on the basis of the events triggering them or the objects affected. Error messages are to state the problem and, if space permits, should offer suggestions for removing the error.
S-type messages are displayed in the status bar on the same or next screen. The message has no influence on the user's work. It only informs about the successful execution of system functions.
This message has a modal character, that is, the user must acknowledge the message. Therefore, display I-messages in a modal dialogue box. The user can continue the processing by pressing the ENTER key.
So-called W-messages interrupt the processing and allow the user to make corrections. For this reason, fields are ready for input. Display W-messages in the status bar if the messages have been issued by a primary window. If a dialogue box issues the message, display the message in a separate dialogue box.
With regard to the system response, warnings can be compared with E-messages. E-messages, however, require the user to change the entry.
When the system detects an error, use E-messages. Incorrectly completed fields must be ready for input. Do not only make the incorrectly filled field ready for input but also those fields whose entries have contributed to the error.
Depending on whether the E-message was issued by a primary window or a dialogue box, display it either in the status bar of the primary window or in a separate dialogue box.
A-messages are also of a modal character and are displayed in modal dialogue boxes.
A-messages do not allow the user to make any further entries. The user can only confirm the message. The task is abruptly terminated and the system returns to a higher-level menu.
Issue A-messages only in extraordinary circumstances, for example, when a system-related error occurs or if the error can no longer be controlled by the task.
The following error groups form a classification of possible errors while working with R/3. They are intended to aid you in designing messages for possible error conditions.
Errors in Tables
Generally, the user is not authorized to make changes in a table. Therefore, the short text of an error message which refers to tables should not contain a reference to a table. This information is contained in the long text, together with the possible hint to contact the system administrator.
If the display of the message was initiated because a system table does not include an entry which was expected to be listed, the short text should not contain a reference to the table but at most a note on the entry:
E-Message: Order type is not expected (Please check entry)
If the error is related to tables, which are only of importance for the SAP System itself or if the cause for the error cannot explicitly be assigned to a particular entry, the message should refer to the system administrator:
A-Message: No further processing possible (Please contact your system administrator)
The long text should always contain a detailed error diagnosis which can also be of a more technical nature (which, however, is marked correspondingly).
If special reference is made to lines which are not contained in a table and if the table is important for the user, that is, if he has maintenance authorization for the table, use the following message pattern:
A-Message: Please enter country in country table first
Input Values Aren't within the Valid Value Range
The user has entered an entry which was not within the valid, usually numeric value range.
E-Message: Please enter posting period in allowed value range
If the value range is known or predefined, the error message should ask the user to enter a value within a specified range:
E-Message: Please enter a posting period between 1 and 12
In some situations, the user attempts to carry out an action which is meaningless from a business point of view (the system should be able to prevent these actions).
E-Message: Please create bill of material first
E-Message: Order type of outline agreement cannot be selected for &
System Error, System Limits Are Exceeded
If a non-user error occurs in the system, the message should explain that a system-related problem has caused the error. It should also point out how the user can respond. Technical descriptions should be avoided.
For temporary problems, the following "good" example can be used:
Bad I-Message: Global lock table is full. Locking is currently not possible
Give a detailed explanation of this message in the long text.
If a more severe system error interrupts the user's interaction with the system, you can display the following message:
A-Message: No further processing is possible (Please contact your system administrator)
Again, give detailed explanation of this message in the long text.
No Entry Made in a Certain Field
If particular entries are required to continue processing, the required specifications are, however, missing or incorrect:
E-Message: Please enter the batch number for material
E-Message: Please enter required-entry field material
If an operating error occurs, for example, the user chooses a function which requires a selection beforehand, the message should specify the initiated action and the error diagnosis, if possible:
W-Message: You have chosen Copy (Please select an order first)
W-Message: You have chosen Delete (Please delete all items individually)
Collisions Due to Certain Conditions Set in the System
If records are locked, the user is missing the required authorization, etc.:
I-Message: You are not authorized for printer & (printer destination)
I-Message: Vendor master record & is currently locked
Invalid Result After Executing an Action
If a calculation would lead to a meaningless or invalid result, do not only give the diagnosis but also a note on how to eliminate the error.
E-Message: The specified quantity is smaller than the delivered quantity (Please enter again)
We talk about a success message if the system has executed a function and the user receives a confirmation message on the activity (for example, due to its importance).
S-Message: New record with field was added to list X
S-Message: Physical inventory document with the generated number has been posted
To avoid contents-related errors early on, the system checks entries for their plausibility, if possible.
W-Message: Please check pricing
Source: SAP R/3 Style Guide