Writing Style¶
Text plays an important role in user interfaces. Take the time to ensure that any text you use is clearly written, easy to understand, and looks good.
Guidelines¶
Your main goal should be to ensure that text is easy to understand and quick to read.
Keep text short and to the point. This improves speed of comprehension for the user. It also reduces the expansion of text when translated (remember that translated English text can expand up to 30% in some languages).
Do not shorten your text to the point of losing meaning. A three-word label that provides clear information is better than a one-word label that is ambiguous or vague. Try to find the fewest possible words to satisfactorily convey the meaning of your label.
Use words, phrases, and concepts that are familiar to the people who will be using your application, rather than terms from the underlying system. This may mean using terms that are associated with the tasks your application supports. For example, in medicine, the paper folder that contains patient information is called a “chart”. Hence, a medical application might refer to a patient record as a “chart” rather than as a “patient database record”.
Text should adopt a neutral tone and speak from the point of view of the software. Pronouns like “you” or “my” should be avoided wherever possible. However, if it is impossible to avoid referring to something as belonging to the user, “your” is preferable to “my”. For example, “Your Records”.
Use the standard GNOME terms when referring to parts of the user interface, such as “pointer” and “window”. The HIG can be used as a reference in this regard.
Avoid repetition where possible.
Sentences should not be constructed from text in several controls. Sentences that run from one control to another will often not make sense when translated into other languages.
Latin abbreviations such as “i.e.” or “e.g.” should be avoided, since they can’t always be easily translated and can be unintelligible when read by screen readers. Instead, use full words like “for example”.
Capitalization¶
Two styles of capitalization are used in GNOME user interfaces: header capitalization and sentence capitalization.
Header Capitalization¶
Header capitalization should be used for any headings, including headings in header bars, tab titles, and view titles. It should also be used for short control labels that do not normally form proper sentences, such as button labels, switch labels and menu items.
Header capitalization should capitalize the first letter of:
All words with four or more letters.
Verbs of any length, such as “Be”, “Are”, “Is”, “See” and “Add”.
The first and last word.
Hyphenated words; for example: “Self-Test” or “Post-Install”.
For example: “Create a Document”, “Find and Replace”, “Document Cannot Be Found”.
Sentence Capitalization¶
Sentence capitalization should be used for labels that form sentences or that run on to other text, including labels for check boxes, radio buttons, sliders, text entry boxes, field labels and combobox labels. It should also be used for explanatory or body text, such as in dialogs or notifications.
Capitalize the first letter of the first word and any words that are normally capitalized in sentences, such as proper nouns.
For example: “The document cannot be found in this location.” “Finding results for London.”
Headings¶
Headings are written in a concise form and do not form complete sentences. As part of this, auxillary verbs, such as “have” and “is”, are often omitted. So are articles, like “a”, “an”, “the”.
For example, a heading would typically be written as “Three Documents Updated”, as opposed to “Three Documents Have Been Updated”.
Headings typically use header capitalization and a heavy font style.
Informal Headings¶
When a heading exists without accompanying information, it can be useful to express it as a full sentence. In this case:
Write the heading as a sentence, including auxillary verbs and articles.
Use sentence capitalization.
Omit the period from the end of the sentence.
Continue to use a bold font style.
This heading style should not be used in the majority of cases, but when it is used, it can help to give a more informal feel.
Ellipses (…)¶
Use an ellipsis (…) at the end of a label if further input or confirmation is required from the user before the action can be carried out. For example, Save As…, Find… or Delete….
Do not add an ellipsis to labels such as Properties or Preferences. While these commands open windows that can incorporate further functionality, the label does not specify an action, and therefore does not need to communicate that further input or confirmation is required.