Texts

Screen Titles | Messages | Message Short Texts | Capitalization

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.

Formulations

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.

Guidelines

Terms

If possible, use terms that the users know and that they understand.

Suffixes

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.

Shortened Sentences

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.

Abbreviations

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.

Guidelines

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.

1. Omit the end of the word

   If possible, create abbreviations for individual words by omitting the end of the word. Menu options and function key names should have a period at the end of the word.

   In a table column heading, also use the period, if possible.

   "abbreviation" becomes "abb."

2. Omit vowels

   Omit vowels only if you cannot form a meaningful word fragment. Vowels that do not influence the pronunciation of the word very much can be left out.

   "group" becomes "grp."

3. Create an acronym

   Create acronyms (artificially created new terms consisting of the first letters of the word fragments or individual words) only if this is clear from the application field (for example, GR for goods receipt in purchasing) or if this is required for table column headings.
   

   "Data Processing" becomes "DP", "Human Resources" becomes "HR", "General Ledger" becomes "GL"

   Never use a closing period if the last letter of a word is contained in the abbreviation.

   For example, "screen" becomes "scrn". The word fragment "number" is generally no longer used in the field name. An exception to this rule is "Personnel number" which can be abbreviated to "Personnel no.".

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:

1. If the previous word was abbreviated according to the guideline "Omitting The End of the Word", it should end with a period and be followed by a blank, if there is enough space.

   "Fixed vendor" becomes "Fix. vendor" or even "Fix.vendor",
   "Fixed capacity requirement" becomes "Fix. CapReq." or even "Fix.CapRep."

2. If the last letter of the word is used, insert a blank between the words.

   "Create new charge" becomes "Crte new chrg.", "Fixed vendor" becomes "Fixed vend."

3. If the second or a following word is written in lowercase, use the lowercase.

   "Fixed date" becomes "Fix. date"

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"

Compounds

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

Hyphenation

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.

Uppercase/Lowercase

Use lower and uppercase letters. Do not use uppercase letters as design elements to highlight headers or other elements.
Exceptions: Use uppercase letters for report names, transaction codes, names of tables and files.

Country-Specific Characters

Use country-specific characters, for example, the umlaut and ß in German.

Highlighting

You can achieve better legibility in the work area of a screen by highlighting important or structuring elements.

Highlighting Types

From the ergonomic point of view, the possible types of highlighting can be divided into the following three groups:

1. Tolerable highlighting: use it very sparingly and only in the case of an emergency (see below)
   • Lines as single lines, interrupted lines and double lines
   • Intensity
2. Hardly tolerable highlighting: avoid it, if possible
   • Semi-graphic symbols such as * ! #
3. Ergonomically bad highlighting: do not use it on a screen
   • Uppercase, spaced text, flashing, color

Highlighting Usage

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. 

Translation

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.

Basic Rule

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

Field Names

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.

Short Texts

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.

Menu Texts

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

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.

Function Texts

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!

top

Source:  SAP R/3 Style Guide