|
|
| (9 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | [[Slicer3:Interface_Design|Return to Slicer3 Interface Design and Usability ]]
| + | <big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3:Usability here]</font></big> |
| − | | |
| − | | |
| − | | |
| − | = Community-centered design for Slicer3 =
| |
| − | | |
| − | | |
| − | 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 community-centered design approach for Slicer3's application and software modules. This approach is built on five principles:
| |
| − | | |
| − | | |
| − | '''1.''' Understand who your users are, what they need, and how they work. | |
| − | | |
| − | '''2.''' Engage users in your design and 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.
| |
| − | | |
| − | | |
| − | ==Value and benefit:==
| |
| − | | |
| − | 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 after 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 reveal 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 necessarily 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 the time-cost from developers to users (and often multiplies it) – what the development team saves by designing software tools without engaging users, users must spend later by providing in-house help.
| |
| − | | |
| − | == Slicer3 design and usability goals ==
| |
| − | | |
| − | Following the design philosophy outlined in this document should avoid those pitfalls and promote the following goals:
| |
| − | | |
| − | * 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 community-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.
| |
| − | | |
| − | == How to apply these recommendations ==
| |
| − | | |
| − | Read through the recommended practice described below; it probably won't surprise you. Most of the strategies it promotes are quite common in commercial software development efforts, where unhappy users leads to an outcome more easily measured than in free, OSS efforts. Think about how the process will fit into your project and your project timeline. The basic pattern is scalable, so you can apply it in a manner appropriate to your application.
| |
| − | | |
| − | == Recommended light-weight community-centered design practice ==
| |
| − |
| |
| − | | |
| − | ===1. Define your target user communities ===
| |
| − | | |
| − | The most basic requirement of a user-centered software design practice 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 of Slicer’s codebase, we're targeting these core communities and types of users (hence community-centered), but we welcome and encourage input from any others.
| |
| − | | |
| − | '''Core Slicer3 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 two or three of these categories. The application you are developing may target a different audience, so a first step is to decide who your core users will be, and whether additional communities are likely to become active users of your software. Make a list of these communities as a “framing device” and post it where you’ll periodically encounter it. Often times, the list will grow as your project progresses. This crucial information will help you to identify potential user-collaborators from whom to seek information and feedback, can expose additional feature requirements, and should flavor how you think about your software’s functionality and its interface throughout your design and development process.
| |
| − | | |
| − | ===2. Assess the needs of your target user communities===
| |
| − | | |
| − | Once you’ve identified your target audience(s), take some time to develop an understanding of how each distinct community will use your software. This step is essential for meeting both the technical and usability requirements of a user community. Every user group is unique; empirical study is the only approach to a good understanding of your users – how they think about what they do, how they accomplish their work and what sets of needs reside within that framework.
| |
| − | | |
| − | A community-centered design approach considers people’s (likely diverse) background and experience, needs and skill levels, tasks that must be accomplished, the environmental conditions, pressures and risks under which users work from the beginning and throughout the design process. With this information framing your design and implementation, you’re very likely to develop a software product that’s more appropriate and usable for your target community, and promote both its potential reach across applications and the longevity of its usefulness.
| |
| − | | |
| − | It’s most likely that you’ll find your future users very happy to spend time talking with you about their research, what their current tools and workflows are like, the technical challenges they present, and what kinds of tools might address them. You may understand these things at an overview level, but the richest information is often revealed in the details; it’s almost always worth spending time to listen. Moreover, this discovery process often reveals new ideas that you may want to include in this or another project.
| |
| − | | |
| − | | |
| − | '''Here are some simple suggestions for gathering information about your users’ needs:'''
| |
| − | | |
| − | Before you begin coding or even designing, make appointments 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. You already know a lot about the technology you’re developing. This step represents an opportunity to learn how to translate your plans into the world your users inhabit. Try to talk with users from every community that may eventually want to use your software module: identify commonalities that can lead to generalizations in your design, and differences that will require accommodation in your design. In addition to observing work settings and workflows, ask salient questions and listen carefully to responses.
| |
| − | | |
| − | '''Find out things like:'''
| |
| − | | |
| − | ** what challenges your users are trying to solve;
| |
| − | ** what stereotyped workflows they use;
| |
| − | ** what tasks consume a lot of time and what are notable obstacles;
| |
| − | ** under what kinds of physical conditions are these tasks being performed;
| |
| − | ** what level of stress and what risk is involved during their work;
| |
| − | ** what kinds of process recording or data provenance is required;
| |
| − | ** what other software do people use;
| |
| − | ** what do they like about other software and what don't they like;
| |
| − | ** what new features do people need and might people like to have; it’s often useful to classify these in two ways: from the user’s point of view, critical needs, future needs, blue-sky wants; and from your point of view, easy, challenging, not tractable. Clear collaborative project workplans with matching expectations can result from such a simple derived chart;
| |
| − | ** what kind of application information (parameters and settings) is recorded;
| |
| − | ** and how are users trained to use new software packages.
| |
| − | | |
| − | * If you already have a technical proposal or a set of technical requirements to develop for this group of users, wait to address its details until after you understand their story to avoid biasing the exchange.
| |
| − | * It’s very important to learn your users' language: application scientists may talk about things differently than computer scientists and algorithm developers. Find out how your target user communities talk about what they're doing and make your interface compatible with their terminology.
| |
| − | * If you are performing a needs assessment but you’re not the primary developer, take the time to report your findings to the developer team face-to-face – many a written report does not get read and considered. It could be very frustrating for the users who contributed their time and expertise (and embarrassing for you) if their input is ignored.
| |
| − | * Absolutely credit contributing users on the project. Depending on the extent to which their time and effort helps to shape the final product, it may be appropriate to make them co-authors, or at least to acknowledge their contribution.
| |
| − | | |
| − | '''What if your target user community is not local, and you can’t travel to spend time with them?''' If in-person interviewing isn’t feasible but you have collaborating users, you can use online meeting services (like WebEx) in combination with telephone conferencing to learn quite a bit. While there’s a disadvantage to not being there in person, certainly some information gathering is better than none. The issue of remote user assessment and usability testing in distributed development efforts is currently an active research topic. So, share what works and what doesn’t work with us and others – your experience will be valuable to this and other efforts.
| |
| − | | |
| − | '''What if you have no access to an appropriate user group?''' One thing you can do is to post a brief description of your project, and a sketch and description of your interface to slicer-users@bwh.harvard.edu, our user mailing list. You can ask for feedback on the design and the functionality you are exposing -- you may discover suprising applications for your work and get some useful input that way. Otherwise, we presently have no other formal infrastructure to support your design and implementation process. As the Slicer3 effort develops, we hope to provide a list of current well-qualified challenges (in terms of technical and usability requirements) to guide developers interested in becoming active participants.
| |
| − | | |
| − | ===3. Create and test design mockups === | |
| − | | |
| − | This is a step often skipped in open source efforts, but the process described below can strengthen the match between your creative interface ideas and the users’ stake in the final product. So rather than creating a design to meet requirements derived in the previous process step and jumping straight to implementation, consider developing a design prototype and refining it with your users’ input. Even one round of interaction is very likely to generate interface improvements. Some things to think about as you go are:
| |
| − | | |
| − | * '''Is the design reproducing known usability problems?''' Read through the existing application interface user feedback for Slicer2 and Slicer3 linked below. Also check for usability reports listed below on specific Slicer2 modules that may be relevant to your work and check your design against them.
| |
| − | * '''Do early prototypes promote discussion and modification?''' Start quick and dirty, and refine your design with user input. Start with flexible, non-precious initial mockups that invite discussion and easy modifications (sketches, whiteboard drawings, or paper prototypes are great) and change it with user participation. Starting with well-thought-out or highly crafted designs will cause everyone to resist making substantial changes, even when they’re clearly called for.
| |
| − | * '''Are the interface’s layout, representation, behavior, and workflow appropriate?''' Work toward a good interface layout, double-check that the terminology and iconography is appropriate, and step through the behavior of the interface to make sure it behaves in an intuitive and appropriate manner. This activity can be accomplished in as little as one meeting per target user group (though it’s best to take as much time as you need and can afford).
| |
| − | * '''Does the interface accommodate all target user communities?''' If you are trying to generalize the layout or terminology in your GUI to satisfy several different user communities, note these compromises so users understand your reasoning and decision making based on their input and are encouraged to participate in determining a good solution.
| |
| − | * '''Do people understand your interface?'''
| |
| − | * '''Does the interface accommodate different levels of expertise?''' 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.
| |
| − | * '''Is the design simple and likely to be stable?''' Design principles from best practices in software development are absolutely applicable to interface designs: Simplicity in design should be a key goal, so keep it simple; and try to arrive at a stable design that hides information – when underlying implementation details change, a user doesn’t have to learn how to use a new interface.
| |
| − | * '''Will the interface accommodate an expanded user base?''' Even if you're adding a command line module to support the work of your own laboratory, remember that you may eventually want to share the code and new end-users may need help to understand the meaning of parameters and suggestions for reasonable values to try. Make your help appropriately detailed, and take care to give parameters that will be assigned widgets in the GUI intuitive names.
| |
| − | * '''Does the interface conform to the Slicer3 style guidelines?''' Check our human interface and style guidelines to work within Slicer3 style conventions; try not to deviate from these recommendations in your GUI and keyboard interface.
| |
| − | | |
| − | | |
| − | '''Suggestions for Observation and Usability Testing Sessions'''
| |
| − | | |
| − | If you’re not a usability engineer, here are ten simple suggestions that will help you to gather useful information about the usability of your software. They apply to most testing situations in which your goal is not to gather quantitative statistics on task performance time or error rates. Rather, they are designed to help you determine where people are having a difficult time using your module, and to collect information about how to address any challenges you observe.
| |
| − | | |
| − | # If possible, choose a small set of features for testing at any given session; this maintains session focus, and respects the busy schedule of your participants.
| |
| − | # If you can afford it, bring some cookies and coffee to get everyone in a happy and conversational mood.
| |
| − | # Make sure that users participating in a usability/testing session know how long the session is expected to take, that it’s OK for them to quit the session at any time, for any reason. None of your participants should feel pressured to complete a test.
| |
| − | # Make sure that participants feel that it’s the module design being tested, and not themselves!
| |
| − | # Try asking users to talk aloud as they use your interface, saying whatever comes into their mind as they work, make decisions, view and interact with results. The free-flow of their thoughts can reveal their expectations and their workflow strategies. (The Apple Human Interface Guidelines suggest that a good way to prepare participants for this kind of exercise is to ask them talk aloud while imagine preparing a cup of coffee.)
| |
| − | # Try not to mention what you’ll be observing specifically – this way you are less likely to bias the session. Instead, remind participants what your software does in general, and describe in very general terms what participants will do during the session.
| |
| − | # It’s quite easy to become frustrated when someone is confused by your interface or has suggestions on how some feature set could be different and better. Try not to be defensive or impatient, even if you’ve already considered and ruled out their suggestions for good reasons. Instead, without mentioning your opinion or explaining and justifying your design decisions, take the opportunity to ask questions and understand their difficulties and suggestions. If someone is describing a different approach, find out why they think the approach is better than the prototype as presented. You are not obligated to take the advice you get, but you should strive to gather as much information as possible to ensure that your design decisions are well-informed and principled.
| |
| − | # If a participant begins to seem confused or have trouble figuring out what to do, resist the urge to immediately provide help, even if they explicitly ask you for it. Instead, remind them that your goal is to make the software easy to use, so you’d like to find out what’s confusing (this implicitly blames the software and not the user, while giving you an opportunity to gain valuable information.) Of course, you don’t want participants to become totally frustrated either. So, be a good judge about when you should step in and provide some guidance, and how much to provide without spoiling your test.
| |
| − | # Note the names of your participants and take notes during your session. In addition to capturing the information you are targeting, make sure to note any unexpected but relevant surprises, and whatever patterns you observe during use of your software. Make sure to appropriately acknowledge your participants, and make sure to fold the information you gather back into your design process.
| |
| − | # At the end of your session, discuss specifically what you were testing and ask the participants if they have any additional questions.
| |
| − | | |
| − | ===4. Implement and test with user feedback===
| |
| − | | |
| − | Once a design is finalized, implement and test. Incorporating sessions to evaluate collections of your module’s features before the interface is hardened will help you to catch any problems that were overlooked in prototype. Try to test one or a small set of features at a time – this keeps the impact on everyone feeling low, and helps to get very focused feedback each time you engage people.
| |
| − | | |
| − | * Check our coding guidelines for developers so the programming style conforms to Slicer3 community conventions.
| |
| − | * During your development process, sit down at appropriate junctures with as many users as you can -- and as many different datasets as possible. Even a few brief, focused testing and feedback sessions will likely strengthen the usability of your software.
| |
| − | * Only test a few features at a time to keep the test easy for users and the feedback focused.
| |
| − | * If users are testing your software on their own time, without you present, provide them with a clear method of reporting their comments.
| |
| − | * Capture notes on these user-testing sessions so no user contributions are lost, and so the entire process can be reviewed and included in publications.
| |
| − | | |
| − | ===5. Document and maintain your code===
| |
| − | | |
| − | To make sure the software remains accessible for beginning and intermediate users especially, use Slicer’s documentation tools and practices:
| |
| − | | |
| − | * Comment your code appropriately so that doxygen generates a good description of your code for developers who want to use or extend it
| |
| − | * Create a description page on Slicer’s wiki that describes your module, and links to any additional information that users or developers may want to consult. Use this [[Slicer3:Module_Documentation_Template | template ]], and link it from Slicer’s [[Slicer3:Module_Documentation | documentation wiki page ]].
| |
| − | | |
| − | To maintain your software:
| |
| − | | |
| − | * Check Slicer’s [http://na-mic.org/Mantis/main_page.php bugtracker] periodically to see if any problems with your module are being noted by users. Software bugs obviously get the highest priority, but usablity issues also important to address.
| |
| − | | |
| − | = Public suggestion section: Comments about the practice above =
| |
| − | | |
| − | Please add your comments and suggestions here
| |
| − | | |
| − | = Collecting user feedback =
| |
| − | | |
| − | We are collecting '''[[Slicer3:FeatureRequests|Slicer3 feature, conventions and resource requests]]''' from application users and software developers. Appropriate entries from [http://www.na-mic.org/Bug Slicer2's bug tracker] and [http://na-mic.org/Mantis/main_page.php Slicer3's bugtracker] will be periodically added to this repository also. All usability problems should be reported there.
| |
| − | | |
| − | = Usability Sessions =
| |
| − | | |
| − | * [[ Slicer3:ApplicationUsabilitySession | Application GUI sessions ]]
| |
| − | * [[ Slicer3:EditorUsabilitySessions | Editor Module sessions ]]
| |
| − | * [[ Slicer3:FiducialsUsabilitySessions | Fiducials functionality ]]
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | <br /> | |
| − | | |
| − | ''' Return to TOC '''
| |
| − | | |
| − | [[Slicer3:Interface_Design|Return to Slicer3 Interface Design and Usability ]]
| |
