User interface best practices

NOTE: This page was previously in the Standards Security, and Best Practices section http://drupal.org/node/360052 - moved it in with the UI Guidelines section, but probably its information needs to be incorporated into other pages. This information has not been as thoroughly discussed as the other UI guidelines in this section. Sorry about any confusion!

-----

Form Elements

When offering a choice of two options, use a checkbox if the options are easily understood to be the opposites of each other (e.g. yes or no question, turning a setting on or off, etc.). Use radio buttons if the options are not necessarily opposites of each other (e.g. use format A or format B for output).

When offering a small number of choices, use checkboxes if the options can be independently selected, and radio buttons if they are mutually exclusive.

When offering more than 10 options, always use a select list rather than radio buttons or checkboxes.

Never use a fieldset for a single form item.

Screen text

General

• Active writing
• Call for action in links, for example: “There are no links to display. Add link”. ‘Add link’ is a hyperlink
• Keep introductions as short as possible, don’t describe options in detail. It would be best if no introduction is necessary because the screen and its behaviour are intuitive
• Don’t describe default user interface usage/behaviour (drag-and-drop etc.)
• Put longer and more detailed descriptions on a ‘More help’ page
• The order of tabs/actions is always (where applicable): List – Edit – Add – Delete

Menus

• Always use verb and noun (‘Add menu’)
• EXCEPT: A page listing items is always called ‘List’, so don’t use ‘List categories’ for example
• Use singular and plural properly, don’t say ‘Add links’ when you can add one link at a time
• Always use ‘Configure’, not ‘Settings’
• Capitalize (only) the first word (‘Add menu’)

Elements in form

• The first field of each element is the name of the element followed by ‘name’ (‘Gallery name’)
• Only add descriptive text under elements when they don’t make themselves clear -- they’re not always necessary

Buttons

• The submit button is always called ‘Save’ when the actual action is saving
• The reset to defaults button is always called ‘Reset to defaults’
• The delete button is always called ‘Delete’
• The cancel button is always called ‘Cancel’ (when used)

Tables

• Capitalize the first word in each column header (‘User since’)
• When the table involves actions, call the column ‘Operations’
• Write the actual operations in a row without capitalization (‘edit’)
• If possible, put the available operations in one row. If that’s not possible, put them right underneath each other
• If the table contains no records: display within the same table a concise "call to action" message with a link which allows the user to add relevant content.

Links (internal and external)

• Give the link a clear name, don't use 'click here' and try to avoid printing the full URL