User interface guidelines: Language (rfc/draft)

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

Post Reply
Posts: 898
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia

User interface guidelines: Language (rfc/draft)

Post by matt_e » Sat Apr 05, 2003 5:57 pm

There's been lots of talk about creating some UI guidelines for Blender, but nothing's actually been accomplished so far. I thought I'd kick things off with one of the areas that would be included: Language. Here's a draft that I wrote up concerning usage of language in Blender's UI.

Please post with things you agree with/disagree with/think should be modified (with solid reasoning to back up your response!). Once we've all discussed/debated things, hopefully this can start to form some sort of official UI style guide document, eventually along with guidelines for other topics such as menus, icons, UI controls, etc.

Blender user interface guidelines: Language (draft)

Use simple action verbs or short verb phrases for labels (on buttons/menus/etc) 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

Additionally, (quoted from the Apple Aqua UI 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.

As an example, here is an actual (horrible) dialog in MS Excel 2000. The top screenshot is the original and below is a modified version I mocked up according to Apple's dialog guidelines. Using verbs as the button labels makes the dialog much clearer and eliminates the need for the paragraph of text describing what the 'Yes' and 'No' buttons actually do.

click for full size

Menu and button labels should have the key word(s) first.

Example from a fictitious word processor:

  • Insert page break
    Add Footnote
    Update Table of Contents
  • Insert
    Page break
    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 uses when they are scanning the list.

For capitalisation rules, I recommend following the Aqua Terminology style guide.

In any case, ALL UPPERCASE shouldn't be used (for example RENDER or ANIM) since it's more difficult to read, and inconsistent with the rest of the button labels. Also try to avoid capitalising two letters in the one word as in dot-com era marketing phrases (eg. RenderButtons). It's a lot clearer to read, and easier to translate when split into two words (eg. Render Buttons).

Write in the user's vocabulary and try to stick to conventional 3D terms.

An example of this is in the label 'Nor' for bump maps. It's unnecessary for the user to know that bump maps are calculated using the normals of the geometry, hence calling it a 'Nor map' is unnecessarily confusing to new users, particularly when 'bump map' is standard terminology in just about every other 3D program.

It's also good to avoid making up new terminology when there is already a standard term (for example Lightwave confusingly calling its subdivision surfaces 'MetaNURBS').

Avoid abbreviations where possible.

A screen full of abbreviated button labels can be very confusing to new users and needlessly obscures Blender's capabilities. If space is limited, before resorting to abbreviation consider either a) using alternate wording to convey the same information in smaller space or b) re-arranging button layouts or using different types of UI controls to accommodate more communicative labels.

Avoiding small UI controls and small abbreviated labels is also advantageous for internationalisation purposes - an idea that can be expressed in one language with one short word may need much larger, or multiple words in another language to express the same thing. It's best to design with surplus space, to allow for clearer, easier and more accurate translations.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests