This section describes how to design texts. It deals with topics such as abbreviations, hyphenation, use of country-specific characters, and also highlighting. A further section discusses points to be borne in mind when translating the R/3 System into other languages.
You have to provide the user with a work environment that is easy to understand: when choosing terms, when specifying pull-down options consisting of an object and an action or when creating the different messages. The following guidelines deal with the formulation of such texts.
If possible, use terms that the users know and that they understand.
Except for the word "personnel number", you can do without the suffix "number". For example, we talk about a "vendor" and not a "vendor number". Use suffixes such as "key" and "indicator" only if they are necessary to understand the field.
Texts in the Form of Questions
Texts containing questions should be formulated positive.
If you use short formulations, use the sequence verb -> noun (English) or noun -> verb (German) without the article. Avoid making verbs into nouns.
Exception: If several short phrases appear one after the other (for example, in a pull-down menu), the part containing the information, that is the verb, is always written first. This also applies to German.
Space restrictions may necessitate the use of abbreviations in many situations: in dialogue boxes, for field names in the applications, for lines in the menu bar or pull-down menus, and for function key names. Use Webster's Ninth New Collegiate Dictionary or for German the Duden as the reference for abbreviating words.
Do not use abbreviations if sufficient space is available or if the user rarely accesses a particular screen.
Using Accepted Abbreviations
If there is already an accepted abbreviation for a word, use it. Use abbreviations only if you are sure that the user can easily understand them. In general, do not use abbreviations that consist of only one letter.
Creating New Abbreviations
If there is no accepted abbreviation available, words can be abbreviated according to the following guidelines arranged in order of priority.
Abbreviating A Two-Word Structure
The guidelines for creating a new abbreviation apply here as well.
The individual word fragments are not separated by a period. Each new word fragment always begins with a capital letter if the previous word fragment has been abbreviated.
"Start date" becomes "StrtDate", "Document type" becomes "DocType", "Tolerance key" becomes "TolKey", "Object group number" becomes "ObjctGrp."
Abbreviating Several Words
Proceed as follows when abbreviating several words:
Choosing From Several Words
If you look at the short descriptions in the ABAP Dictionary, you can also find complete phrases, such as "Fixed machine-related capacity requirements in hours". For the abbreviation, only choose the significant words. You may need to change the word order to form a suitable abbreviation. The guidelines 1. to 3. apply for the creation of abbreviations.
"Fixed machine-related capacity requirements in hours" becomes "Mach.fix" or "Mach. fix"
In the case of different abbreviations for words which consist of more than two word fragments, make sure that individual word fragments are not completely omitted. Otherwise, it could result in the impression that two different things are meant. For example, "Minimum order amount" could be abbreviated to "MinAmount" and also to "MinOrdAmount". Here, it is better to use either "MinOAmt" or "MinOrdAmount", so that the word fragment "order" is not forgotten.
Further Text Issues
Do not hyphenate words on a screen, so that they extend over two lines. Write words with a hyphen in the same line.
Exception: With long sections of continuous text (more than 50 characters), words can be hyphenated if this would otherwise result in large "gaps" on the right border.
Use lower and uppercase letters. Do not use uppercase letters as design elements to highlight headers or other elements.
Use country-specific characters, for example, the umlaut and ß in German.
You can achieve better legibility in the work area of a screen by highlighting important or structuring elements.
From the ergonomic point of view, the possible types of highlighting can be divided into the following three groups:
The highlighting in the first two groups is to be used only if all means of spatial and conceptual structuring have been exhausted.
As a rule, not more than 10 % of the screen should be extra emphasized.
This section groups together some of the most important precautions that need to be taken to ensure that the R/3 System can be translated into other languages.
Translation of texts from English or German into other languages may increase the length of the text by 30 percent or more. If you do not leave enough room on the screen, translators have to abbreviate terms beyond recognition.
As a rule of thumb, you should allow space for text expansion by about one quarter to one third during the translation.
User Interface Elements
For field names, use the standard lengths provided by the system so that sufficient space is available for the translation. Sometimes, you can use the second largest length, but leave at least two blanks.
The same applies to short texts as to field names. However, due to the greater length, the translators have more room to find an appropriate word for the available space.
For menu texts, the system standard is 20 characters. If the texts in the menu bar are very long and the entries no longer fit on one line of the menu bar, the menu bar is split into two lines. This causes problems with small monitors, as a screen line may get lost.
With pull-down menu texts, there are no length problems except that the limitation of 20 characters may cause a problem.
Pushbutton texts, like to menu texts, are restricted to a maximum of 20 characters. For pushbuttons, however, you have to keep in mind some special features, although these do not affect the translation. The system displays as many pushbuttons as can be accommodated in the window depending on the text lengths of the individual pushbuttons. Thus, if you want to make sure that a certain number of pushbuttons is displayed in the standard size window, you have to abbreviate the texts, if necessary. On the other hand, the number of pushbuttons increases when the window is enlarged, provided a sufficient number of pushbuttons is defined; correspondingly, if the window is reduced, fewer pushbuttons are displayed.
If you want to include an icon into the pushbutton, keep in mind that this will cost you another 4 characters! That means that you may have to abbreviate the pushbutton text. Do not drop the three punctuation marks that indicate a dialogue box, abbreviate instead.
During the enhancement of a user interface, problems may occur when replacing a function text. If this change is used to eliminate a guideline violation and if it does not change the nature of the function, it is useful. Otherwise, please always create a new function with a new function code! This is necessary, because the foreign language version does not necessarily have the same status as the current German or English version. This may lead to unwanted functions being called!
Source: SAP R/3 Style Guide