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, that developers can easily contribute to and extend the application, and that the software remains easy to test and maintain.

These human interface design and style guidelines are a resource for Slicer developers who want 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.

Organization

This document is organized into the following three sections:

1. Slicer User-Centered Design Process

2. Slicer Module Design Principles

3. Slicer Widget and Interface Style Specifics

Within these sections, developers will find:

• a “touchstone” process for designing Slicer module interfaces that are easy to learn and use
• downloadable materials to assist in assessing user needs and evaluating prototypes, and
• human interface and style guidelines that promote usable and consistent Slicer module interfaces, and link to technical resources where appropriate

Section 1. Slicer User-Centered Design Process

Slicer’s lightweight user-centered design process is designed to be compatible with OSS software efforts, which are often composed of a small developer team, or even a single individual. The process is built on the following five recommended practices.

1. Understand your users and how they work.

2. Engage users in your prototyping process.

3. Refine your implementation iteratively with user feedback.

4. Provide documentation that describes your module, its status, its features, and how to use them.

5. Monitor and address feedback on software bugs and usability issues.

Value and benefit: why bother with this when you already know what you want to build? In OSS efforts operating in a research setting, software development is often driven principally by feature requirements (a feature-centered design approach) in service of advancing research. Mature tools often evolve from software prototypes designed to test an algorithm, or they’re created for use in a particular research laboratory by experts familiar with the algorithms and their parameterization. Usability issues are often approached at the time a tool is translated out of the laboratory, long after design and implementation decisions have hardened the underlying technology and the way it’s exposed to users. Asking “what do the users think?” at this point will likely expose the need for significant re-design and re-engineering that a project can’t afford and developers don’t want to think about.

So, while establishing a clear set of technical requirements is paramount for a tool intended to reach a broad audience and to have a strong impact on scientific research, it’s not enough. If the software isn’t easy and satisfying for people to use, the tool’s use can be limited or can vanish when a more satisfying alternative becomes available. This outcome minimizes the utility of a team’s or individual’s contribution, and diminishes the impact of a project’s sponsoring agencies or institutions. Sometimes, adoptive user communities spend valuable time drafting and maintaining their own local versions of training materials for unfriendly tools (keeping instructions in binders in the lab, on local wiki pages, etc.) to train new users and support ongoing use. This outcome transfers (and multiplies) the time-cost from developers to users – effort the development team saves by designing software tools without engaging users must be spent later by each adopting user group to assemble in-house training and support materials.

Instead, Slicer modules 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’s easy to understand, learn, and use.

Easy adoption: engaging users early in a way that fits your project and its timeline ...