Revision as of 01:46, 25 July 2007

Home < Slicer3:Human Interface and Style Guide for Developers

Slicer Human Interface Design and Style Guidelines

Introduction

3D Slicer (or Slicer) is a large and continuously developing application. Its base is designed to offer substantial core functionality, and its modules extend that functionality to include specialized and cutting-edge research tools and interoperability with other open source softwares. The development effort seeks to simultaneously ensure that:

Slicer meets the needs of a broad user community,
developers can easily contribute to and extend the application,
the software remains easy to test and maintain, and
the appearance and behavior of Slicer's interface are easy to learn & use, and aesthetically pleasing.

These human interface design and style guidelines are a resource to help Slicer developers to create module interfaces that are easy to learn, understandable and usable, and that conform to Slicer’s general appearance and behavior conventions. The recommendations in this document are designed to be easy for developers to apply and their adoption is strongly encouraged. However, a developer’s interface design can depart from convention when these guidelines appear inappropriate for a particular application.

The guidelines are intended for software developers, interface designers, and graphic artists who will be creating core functionality or software modules for 3D Slicer. Included design recommendations are based broadly on cognitive science, human perception, human factors and HCI. Included is information on basic interface components, choosing and using them effectively and in a manner consistent with Slicer conventions.

Organization

This document is organized into the following two sections:

1. Slicer Design Principles

2. Slicer Widget and Interface Style Specifics

Within these sections, developers will find recommendations that promote usable and consistent Slicer module interfaces, and link to technical resources where appropriate.

Slicer Design Principles

Design for scientists and engineers

Remember that design is not just about appearance and style; it's about communicating ideas and solving problems.

Most users of the software you develop for Slicer will be from one (or more) of these communities:

Algorithm researchers (who work within Slicer's development environment and with associated toolkits)
Biomedical engineers (who rely on Slicer's interactive enironment and scripting capabilities)
Application scientists (who use Slicer as a desktop application and turnkey system)

In general, these categories of users will not want appearance and style to get in the way of the task they want to accomplish. Interfaces should have a well-organized, accessible, simple and clean design that:

exposes essential features,
provides access to essential information,
permits tasks to be accomplished efficiently and reliably,
provides adequate feedback, and
is forgiving of mistakes.

Accessibility & appropriateness

Currently, Slicer has neither an accessibility component in the design & engineering effort, nor a program to internationalize or localize its interface. However, because keeping Slicer usable and appropriate for a large and diverse user base is important, developers are encouraged to design interfaces that are appropriate for users with disabilities and for users from multicultural, multinational, or multilingual backgrounds.

In the absence of formal engineering infrastructure to support a principled approach, Slicer is not yet compatible with sensory assistive technologies. In addition, Slicer relies on the English-language keyboard character set, uses hard-coded strings and concatenated strings (which Tcl makes particularly easy), a left-to-right convention for reading/writing that manifests in layout, no number and date formatting, and so on. Until formal approaches to both accessibility and internationalization are implemented, the following informal design recommendations are offered:

Make sure your language (what you name things and how you phrase things) is appropriate,
Try to make sure your graphics aren't overloaded with meaning you don't intend
Make sure all widgets (especially icons) have explanatory labels or pop-up balloon help text,
Provide keyboard access for important functionality in a manner consistent with Slicer's conventions,
Try not to override the font specification in Slicer's theme, which users can adjust (somewhat) to fit their preference,
Use the Application Settings infrastructure to save user preferences wherever it makes sense to do so,
Minimize the physical and mental stress of performing repetitive actions,
Provide appropriate prompting and feedback for all actions.

Following these general suggestions will improve the usability of your interface for all users.

Design for varying levels of expertise

Slicer users can be classified into three broad bins: novice, intermediate and expert users. Each type of users will desire a different user experience, and would like to use the interface to your module's functionality in a different way. Ideally, an interface will support the needs of all three types alike.

Novice users: Novice users will likely rely heavily on the GUI widgets, their pop-up balloon help (which should include any available keyboard hot-keys), and external sources of information like tutorials or documentation. Novice users may work at a relatively slow pace, since they are both exploring the scope of functionality provided, and learning how to use it.

Intermediate users:

Expert users:

Keep it simple

Use clarifying layouts

Keep it stable

Keep users informed

Allow users to correct mistakes

Respect users' wishes (application settings)

Maintain consistency with Slicer's appearance and behavior

Make principled design decisions

Follow Slicer's User-Centered Design Practice

Slicer's light-weight User-Centered Design Practice document is a resource to help developers take a human-centered approach in an open source development effort (in which interface & information designers and usability experts are not often part of the team.) Using this design approach offers the following benefits:

Users will learn to use your module faster, because its interface will be understandable and interface elements will look and behave in an expected manner.
Users will be able to accomplish their tasks by following an appropriate and satisfying workflow, or a curiosity-driven exploration, at an appropriate pace.
Your module will be accessible to users at all levels of expertise (novice, intermediate and advanced).
Your module will have a nice look & feel that fits within the 3D Slicer environment.

Modules that hit these marks should maximize the reach of a developer’s research, design, and programming effort, offer contributing agencies, institutions, and individuals the maximum impact for their investment, and provide the user community with cutting-edge functionality that they find satisfying to use. The Slicer community ultimately leaves the choice about design and implementation process to contributing developers, and the recommendations in this document are not enforced. Since we believe that incorporating user-centered design will improve Slicer overall, developers are strongly encouraged to adopt this light-weight and flexible practice, and adapt it to fit their environment and project timeline.

Slicer Interface Design & Style Information

Overall Look and Feel

GUI Style: Try not to add style elements (like foreground and background color, font, relief, etc.) to the interface you create; let the options database (as set up by the vtkSlicerTheme class) specify the style for the widgets in your module so that all modules appear consistent within the Slicer3 application.

Module style

Collapsing and Tabbed frame styles

Application windows

Types of windows

Window appearance

Message windows & dialogs

Other pop-up windows

Menu bar and its menus

What goes in the File Menu

What goes in the Edit Menu

What goes in the View Menu

What goes in the Help Menu

Application settings

Confirm on delete

Check vtkSlicerApplication::ConfirmDelete setting; if a user has requested to be presented with a confirm on delete, then give them that option.

Adding your own application setting options

Mouse modes

Mouse modes are currently in transition in Slicer3 Beta. Mode-free design is ideal. Modes are required to disambiguate what a mouse click means in Slicer's 3D Viewer and Slice Viewers.

Basic mouse modes

Adding new mouse modes

Mouse cursors

Basic mouse cursors

Defining your own mouse cursors

Keyboard shortcuts

Keyboard shortcut paradigm

Basic keyboard shortcuts

Defining your own keyboard shortcuts

Event Bindings

With respect to the specification of keyboard accelerators, please follow these three recommendations;

Before assigning "hot-keys" to functionality, either in the main Slicer application or in a new module, please consult the Slicer3 event bindings table (and design plan) to make sure the key is not already assigned.
Across Slicer modules, try to use similar "hot-key" assignments for similar functionality; this consistency makes Slicer easier to learn.
Once you assign "hot-keys" in your module, please add those mappings to the Slicer3 event binings table for others to reference.

Application Font

Verdana is the font chosen for the 3DSlicer brand.

Maintaining consistency of type is an important component of maintaining a coherent look and feel for 3DSlicer and any related or derived visual communications. Verdana was designed specifically to be read on a digital display; it is recommended that we use Verdana (or Geneva) wherever possible in 3DSlicer's web presence and online tutorial materials, and wherever reasonable and appropriate in formal printed materials.

Within the software, since it can't be guaranteed that these fonts will be widely available on all platforms, Helvetica or Arial should be used as a substitute. Slicer's theme sets the application font to be Helvetica 8 normal. Please avoid typefaces with serifs.

Icons

Icons can be a powerful way to represent complicated information within a small footprint on the GUI panel. They associate a visual image with data, state, or a particular operation.

They should be easy to parse, convey a strong metaphor, and not require significant time for a user to interpret.
They should be memorable so that a user can recognize them quickly in future sessions with your module.
If an icon already exists within 3DSlicer to represent the data, state or operation you want to indicate, then re-use that icon (indicate visibility with the open/shutting eye, for example.)
Note: if the concept is too difficult to represent with a picture, then a text label can always be used instead!

When designing icons, do bear in mind that it's possible to offend users with images that have cultural or polictal connotations. Even colors can have connotations for users in different parts of the world that may be surprising and unintended for the designer and developer. Generally speaking, it's useful to avoid images that contain:

icons that depict only hands or feet
images of animals
maps containing disputed boundaries or region names.
lists of countries that are not in alphabetical order.
pictures of flags
pictures of money

Slicer icon conventions & developer resources

3D Slicer icons should all be of dimension 21x21 pixels.

Enabled icons should have:

a white background (r=255, g=255, b=255, or #FF FF FF)
a black hairline along the perimeter (r=0,g=0,b=0, or #00 00 00)
or (for radiobuttons) a grey dashed hairline along the perimeter (r=178, g=178, b=178, hex value #B2 B2 B2).

Disabled icons should have:

a grey background, value (r=230, g=230, b=230, or hex value #E6 E6 E6)
a grey hairline perimeter of value (r=178, g=178, b=178, hex value #B2 B2 B2)
or (for radiobuttons) a grey dashed hairline along the perimeter (r=178, g=178, b=178, hex value #B2 B2 B2).

Icons as PushButtons, MenuButtons RadioButtons and CheckButtons

These icon blanks are provided for download and use:

PushButtons

Enabled Pushbutton:
Disabled Pushbutton:

MenuButtons

Enabled Menubutton:
Disabled Menubutton:

For CheckButtons and RadioButtons represented with icons, it's preferred to reflect the button's state with the icons themselves, rather than using the indicator as well (redundantly). Blanks for the Selected, Deselected and Disabled CheckButton are as follows:

CheckButtons and RadioButtons without Indicators (preferred)

Enabled, selected Radiobutton icon:
Enabled, deselected Radiobutton icon:
Disabled Radiobutton icon:

Since custom icons are already used application-wide in Slicer to display the CheckButton indicators in a consistent way across all development platforms, using an icon and an indicator together require a custom icon that incorporates both. Below are blanks that can be downloaded and used to generate your own icons for the "Selected" "Deselected" and Disabled states of your checkbutton.

(non-preferred) CheckButton Icons with Indicators at the Bottom