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 developer’s experience with GUI 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

Feature, Conventions and Resource requests

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

Usability Sessions

• Application GUI session
• Editor Module sessions

Special Usability Session at MIT Project Week Meeting 06/27/06

At this session, we requested feedback from attendees on the general design of Slicer3's user interface in its current form. The participants included 4 Slicer users but the majority of attendees were principally Slicer developers and developers of software tools and toolkits who are interested in compatibility with Slicer. The discussion was informal and the topics discussed (some in more detail than others) are listed below.

Tabbed versus collapsing frames for module GUI sections.

The issues: Slicer2's convention is to organize a module's GUI into different functional sections notebook-style, using horizontally arrayed tabbed panels. Each tab's UI panel has a vertical scrollbar if the panel is longer than the size of its containing frame. If more tabs are used than fit the horizontal extent, a "more" tab is displayed which, when clicked, switches the the display to show the new set of tabbed panels in place of the old. This tabbed organization has the advantage of being familiar to Slicer2 users; and symbolically represents the different tabbed sections as non-hierarchical in nature. Disadvantages are that developers feel constrained to create very short (non-descriptive) labels for the tabs so they'll fit within the panel's extent, and the "more" tab can be confusing.

The Slicer3 embodiment so far uses vertically stacked collapsing frames in place of tabs and a vertical scrollbar. Frames can be collapsed to save space, and navigated an intuitive manner. Switching back and forth between a module's GUI sections can require a lot of scrolling however, especially when each GUI section contains a long UI panel. A "scroll helping widget" (that goes to preset locations in the scrolled frame) was suggested and could be useful in this scenario. This organization may be useful in presenting a serialized workflow.

Moderate preferences for both styles were expressed; no very strong preferences were expressed. Ideas for accommodating three types of module GUIs was discussed (notebook style, where each tabbed panel can contain stacked collapsing panes, simple style with a set of stacked collapsing panes, and multi-step workflow wizard).

Right now to open and close a collapsing frame, one has to click the little arrow/x icon; it was suggested that double-clicking the icon or the frame label should trigger the same behavior. In a tabbed notebook implementation, if tab labels are short, mouseover them could display a more detailed balloon help after a very brief mouse-hover time.

Improved visual parsing of the Module GUI panel

Currently Slicer's theme is applied throughout the entire application, and to each module. To improve visual parsing of the module GUI and its components, we'll modify Slicer's theme to distinguish these elements. (This is mocked up in the figure above.)

Presenting module help

A point was made that it's sometimes useful to keep a module's help window open while using other parts of that module's GUI or while using another module. It was suggeted that in place of each module's Help tab that we use a help system or compiled-in searchable html help. This has the added advantage of simplifying each module's GUI panel and encouraging the contribution of more detailed help with each module.

Contributor logos and including an "About" popup

For each module include an "About" button which pops up standardized information about the module and the contributing author(s) and Laboratory (including a relevant url and potentially a link to a tutorial for using the module). This might be linked to a group's logo as well as a button. Displaying a contributor's logo prominently and not dominating it with the Slicer logo was noted as being very important.

How to classify and organize modules in Slicer's module selection widget

Votes for each of the following options were expressed: a single list of all modules listed alphabetically, a cascading pulldown menu of modules organized by general functionality, and a search interface that returns a list of modules that correspond to your search terms.

Customization

Requests for the ability to customize Slicer were expressed; many of these can probably be added to the application settings interface. Noted were: ability to specify the type of file formats to load, set the home module or a list of commonly used modules (creating numbered icons each with a module assignment?), particular view configuration to use, setting display parameters (like turning interpolation on by default).

List of feature requests

These will be added to the feature request list below as well:

• Ability to "clone" a view;
• A PAX-type file browser to use in a load module;
• Ability to specify slice window controller display behavior (whether it disappears when not being used, or whether it is persistent);
• 3D Drawing tool that allows ROI tracing directly on models;
• Ability to regenerate models in one button click after updating label maps;
• Good widgets for measuring: angle, distance between two points, and displaying results in mm or pixels;
• Good widgets for defining ROIs with ellipses or polygons and providing metric information (area etc.);
• Ability to select and display: Axial, Saggital, Coronal, and an arbitrary reslice in the Slice GUI; given the last option, use a 3D Widget to place the plane within a volume;
• Ability to specify a curvilinear reformat and display in the Slice window;
• Adding a hotkey for window/level in each Slice window;
• Providing intelligent presets for Window/Level to choose from;
• Compositing and displaying more than two volumes and label maps in the slice windows;
• Ability to apply an ROI drawn in one slice to multiple slices.

Slicer3 design and development climate

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.

Notes on OSS and user-centered design

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