Slicer3:Usability

Return to Slicer3 Interface Design and Usability

Slicer3 design & usability goals

1. Enable a user to understand and effectively use the content and tools being presented;

2. Enable a user to accomplish a principle task by following an appropriate and satisfying workflow or a curiosity-driven exploration, at an appropriate pace;

3. Enhance and support the user’s experience with interface and software infrastructure, and guidelines that simplify and clarify their work.

Core domain uses & needs assessment

The most basic usability requirement for any software package is a thorough understanding of who the target audience is. Our Slicer3 development funding designates the following communities to be among our core user groups, though the package is used in many other scenarios as well. In design and development, we're targetting these core communities, but we welcome and encourage input from any others.

Core user communities:

• (NAC) Longitudinal and multi-channel dataset analysis
• (BIRN/NA-MIC) Individual and group analysis
• (IGT/AMIGO) Real-time control and tracking in the operating theater
• (IGT) Neurosurgical planning and guidance

Types of users:

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

(Many people in our user community fit all three categories).

Recommended light-weight user-centered design practice for 3DSlicer

Historically, much of Slicer2's underlying architecture and user interface were developed by a large (and distributed) community over time, lead and framed by strong technology vision, but without a coupled interface/interaction design and usability effort. Wherever possible, we are encouraging a user-centered design approach for Slicer3's application and software modules. This approach is built on 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 problems.

For module developers who don't have the luxury of usability experts and interface & interaction designers on their development teams to work with, a light-weight user-centered design practice is recommended below, and some supporting documents are included to make it easier to implement:

Before you design:

• Read through the existing application interface user feedback for Slicer2 and Slicer3 linked below.
• Check for usability reports listed below on specific Slicer2 modules that may be relevant to your work and read through them.
• Even if you're adding a command line module, remember that some end-users will need help to understand the meaning of various parameters, and if appropriate, suggestions for reasonable values to try. Make your help rich in detail, and take care to give parameters that will be assigned widgets in the GUI intuitive names.
• Of course, check our coding guidelines for developers
• Ditto, check our human interface and style guidelines
• Take time to consider who the users of your software module might eventually be, even though initially you may be developing codes for use in your own research group (we want your software to enjoy a sustained and useful life in the broader community). Make a list of each distinct user community (including different skill levels) that may be interested in using your software.
• If you have a couple of hours to sit with eventual users of your software, observe how they work and understand their workflows; this small investment will help you better understand how your module can support that workflow and be easy for your target audience to use.
• Ask questions and listen carefully to responses: find out what challenges your users are trying to solve. Learn about other software people use, what they like about it and what they don't. Ask what new features people might like to have, and learn how users are trained to use new software packages.
• Learn your users' language: find out how they talk about what they're doing and make your interface compatible with terminology your target audience uses.

Your initial design:

• Create a thoughtful design, but create a flexible mockup that invites modifications (sketches or paper prototypes) and change it with user input.
• Remember that most people who use your software will likely be intermediate-level users. Your design should strike a balance to ensure you support the workflow of intermediate-level users while making your software as easy to learn as possible for novice users, and as convenient to use as possible for expert-level users.

Your iterative implementations:

• Try not to deviate from Slicer3 conventions in your GUI and keyboard interface (consult the style guidelines for this information).
• During your development process, sit down at appropriate junctures with as many users as you can (and as many different datasets), and let them test what you're building and give you some feedback. Even an afternoon of testing and feedback will likely strengthen the usability of your software.
• When you release your module for use, create a place for users to record their comments as they become more familiar with the module and use it more regularly, and check back there regularly; save some time to make reasonable and appropriate refinements your module according to this feedback.

At very least, we ask that before you start coding, you grab a cup of coffee, relax and read through some of the information collected from Slicer users so far. Many people have already taken time to contribute a lot of information about the things that they’d like to see in Slicer, ways they’d like it to behave better, and some things they feel impedes their workflow. Within that information, there may be comments applicable to your specific project; at very least, comments there may help you to avoid repeating a pattern that has known usability problems.

Finally, the user feedback page also has a place for developers to request features and improvements for the development infrastructure; please add your own comments and suggestions there as well.

User feedback

We are collecting feature, conventions and resource requests from application users and software developers. Appropriate entries from Slicer2's bug tracker will be periodically added to this repository also.

Usability Sessions

• Application GUI sessions
• Editor Module sessions
• Fiducials functionality

Notes on OSS and user-centered design

OSS projects express their own distinct cultures, and each likely presents an unique and interesting climate in which to launch a user-centered design component. For the Slicer3 effort, we're developing a new user interface within a very active OS development environment which has adopted the "Extreme Programming" methodology. Developers communicate and work collaboratively via local meetings, weekly t-cons, a dedicated wiki, intermittent programming meetings, using shared CVS and Subversion code repositories. At the start of this project, no usability studies have looked at earlier versions of Slicer, or any of its many individual components. A coarse style guide exists in the form of a limited preferred-use widget set, and conventions for color-coding, fonts, GUI layout, providing help, tooltips, and documentation. Members of our small usability team are also members of the Slicer developer community, and have worked with and developed software explicitly for members of Slicer's user community. As such, we're starting this effort with a good understanding of both of these communties, and a strong sense of the core values of the Slicer effort and the software artifact.

As an open source software effort and artifact, Slicer has a unique compound characterization; it's an extensible platform for research and development with a fairly consistent coding style; an interactive end-user application with high-performance C++ image analysis and rendering and a fairly consistent user interface, and a supported mechanism for translating emerging tools rapidly from re search laboratories to both user and developer communities.

Culturally, as in many OSS efforts, most of Slicer's underlying architecture and user interface have been developed by a large community over time, lead and framed by strong technology vision, but without a coupled interface/interaction design and usability effort.

Recently, OSS projects such as GNOME, KDE, Mozilla and OpenOffice.org have had notable success in incorporating usability teams into their efforts. While the typical role of interface designers and usability experts in the development of commercial products is well known and very deeply coupled, the manner in which a user-centered design effort can interact with and productively shape OSS development remains a challenging topic.

For example, in industry, usability experts are involved in development before coding even begins, and their designs strongly shape the form, behavior and etiquette of a software product throughout its development cycle. Many open source developers enjoy coding for themselves, as part of a distributed working meritocracy, developing according to their own -- and often excellent -- intuitions. While the success of projects like GNOME inspire interest in collaborating to promote both technology excellence and usability, no standard prescription extists yet for how to implement that collaboration.

We can look at the GNOME project as a case study: In March 2001, Sun Microsystems performed a three-day GNOME usability study (Smith S, Engen D, Mankoski A, et al., "GNOME Usability Study Report", Sun Microsystems, July 2001) and results were subsequently presented at a GNOME users and developer's conference (GUADEC). The study recruited a dozen technical, business and creative professionals with computer experience, but none with GNOME. Participants were tasked with logging in, commenting on the desktop, customizing the desktop and managing files. Their report categorized and itemized important feedback from participants, and offered design recommendations. (note: link to study). This presentation marked the first time many GNOME developers became aware of the user community's experiences with the software.

Shortly afterward, a usability team was formed within the project, tasked first with developing a set of guidelines (now the GNOME Human Interface Guildelines, HIG 2.0) against which GNOME applications are checked for conformance prior to release. The team also introduced a usability keyword for bug reporting so that usability-related bugs could be properly tracked and assigned. Other OSS efforts have formed usability teams too (i.e. KDE Usability Project and Mozilla UI Sector) and have published their own usability studies and sets of usability guidelines (i.e. KDE Human Interface Guidelines). (note: link to guidelines).

Strategies for building open source software tools that users love to use can still be greatly improved. Some of the following issues are noted as current challeges for advocates of usability in OSS efforts (Benson C. "Meeting the challenge of open source software usability", Interfaces 60, Autumn 2004):

• Encouraging a thorough understanding of the core user community;
• Having a usability team consult more deeply in the development process;
• Adopting distinct ways to regard and address usability and functionality bugs;
• Developing OSS tools that automate generation of guideline-compliant interfaces for developers;
• Creating convenient oportunities and mechanisms for users to comment on usability issues;
• Finding ways to share and consolidate experience among usability teams across OSS projects;

To address the last issue, some useful resources exist, notably openusability.org, which has a useful bibliography linking to usability discussions, relevant articles, news, guildelines and published studies. Openusability.org is a professional meeting ground for open source developers and usability experts, and clarifies very simply the benefit of their collaboration: "There are many Usability Experts who want to contribute to software projects. And there are many Developers who want to make their software more usable, and as a consequence, more successful."

Return to TOC

Return to Slicer3 Interface Design and Usability