Dev:2.5/Source/UI/Terminology and Language

Language and Terminology

Using consistent, clear and relevant language helps blender communicate quickly and easily to users. As well as being functionally useful, correct spelling, grammar and style helps give an impression of professionalism and polish, while also making messages easier to decipher for foreign language speakers.

Grammar

Use simple action verbs or short verb phrases for labels that perform an action

Verbs are a lot faster than other labels such as 'Yes' or 'No' since it reduces the amount of mental processing required and leaves less room for misunderstandings. A user can tell at a glace exactly what action the control will perform, rather than having to read through accompanying text (more info at asktog.com).

Fortunately, Blender's dialogs and popup menus are constructed in such a way that this behaviour is generally the default, with the user selecting the menu item that describes what action will take place.

Write in US English

The majority of English speaking Blender users have been taught US English, and this should be standardised on as a default. It's entirely possible to make a UK/CA/AU/NZ English translation file though, if anyone is up to the task :)

Capitalization

UPPERCASE should not be used. Apart from looking obnoxious, it is typographically harder and slower to read, as there is less differentiation between the shapes of letterforms. Latin alphabets are generally scan read by identifying discrete word shapes, rather than as a string of characters one after the other. The same rationale also applies to DoubleCapitalization - avoid it when possible.

Labels

Both pulldown or popup menu titles, or button or menu item labels should use Title Case.

Eg: Align View to Selected

Menus

To aid scanning, menu labels should have the key word(s) first. As an example from a fictitious word processor:

Bad:

• Insert page break
• Add Footnote
• Update Table of Contents

Good:

• Insert
• -------
• Page Break
• Footnote
• Table of Contents

Although the first (bad) example is more descriptive and accurate, the second (good) example is faster, because the first word (Page, Footnote, Table) is what the user sees when they are scanning the list.

Buttons

From the Apple Aqua Human Interface guidelines:

• If a button acts on a single setting, label the button as specifically as possible; "Choose Image" for example, is more helpful than "Choose". Because most buttons initiate an immediate action, it shouldn't be necessary to use "now" ("Scan Now," for example) in the label.

Messages

When writing error messages or OK confirmations, use plain, natural sentences unless doing so would make the message extraordinarily long and unweildy. The benefits of smooth reading, interpretation and clarity in natural language generally outweights minor and often unnecessary space savings when abbreviated.

Eg: "There is no active object" rather than "No active object" or "No objects are selected" rather than "No objects selected"

Always write in the user's vocabulary and avoid exposing technical implementation concepts that are irrelevant to a user's ability to complete his task.