2011 Project Week Breakout Session: Slicer4
Summer Project Week Breakout Session: Slicer4 Module Usability
9am-11am, Tuesday June 21, 2011, Star room.
All Slicer4 developers and Ron.
Purpose: Review of existing slicer4 functionality and user interface with an eye towards creating a consistent and pleasant user experience with a logical grouping of functions to accomplish standard tasks.
Review of features and next steps with the idea that developers and users can vote on priorities for development effort
- Main application GUI: compare Slicer 3 and Slicer 4
- Stabilizing the Main application GUI has high priority.
- Performance enhancement for the features in the main application GUI are also critical.
- Reorganizing panels above both the slice viewers and 3d viewers for consistent look and feel.
- Review keybindings and mouse behavior on different platforms
- Compare Slicer 3 and Slicer 4
- Identify inconsistencies
- How to handle Mac trackpad, multitouch I/O, single button mouse
- Slicer-side I/O
- Load/Save: Default is the scene only, which includes sceneviews. Everything else is exposed by opening an advanced panel. This will require Slicer to make some assumptions at save time, such as what format to use for data to be saved. How do we maintain dicom header information so that it survives a round trip?
- Import/Export: to and from Dicom, other data formats (see below under infrastructure)
- Module template: Help, Acknowledgements, location of I/O panel, behavior of "frames" such as auto-stretch.
- Current List of Core modules: should they stay or should they move into other categories? Add new ones? Order?
- Annotation Module (xx)
- Color Module (xx)
- Data Module (xx)
- Interactive Editor (Steve Pieper)
- Sceneviews (xx)
- Slice Controls Module: Should present controls for: Slice viewers, compare viewers, 3D viewers: rename to Layout controler?
- Slicer Welcome Module: update?
- Volume Rendering Module: I/O should have same user experience as I/O in Slice viewers
- Volumes Module (xx)
- Transforms Module (xx)
- instrumenting dimensions for sliders, seeds etc.: Slicer users have data range from cells to organisms to galaxies. E.g. Mouse DTI versus Human DTI: need different defaults. This is currently not working well.
- Remote IO options (save/restore of slicer data and scenes via DICOM, Midas, wiki...): Use a zip ball with a Dicom header and some thumbnails?
- Performance enhancements/bottlenecks
- Enhancements to module functionality
- command line modules (slicer execution model)
- python scripting
- Embedding slicer4 packages in standard python interpreter
- Support for new datatypes?
- Icon associated with each datatype
- I/O registration in qSlicer[Core]IOManager
- Official module for each node type "Edit properties..." (current hack)
DTI needs different defaults than human DTI, for instance.
- web/mobile deployment options?
- motivating use-case scenarios?
- Is this just a "cool thing", a me too, or a critical path capability?
- other ideas or requests?
General Slicer4 TODO items for discussion among developers
- Porting remaining SWidgets (Crosshairs, Model/Slice Intersections, Reformat Widget...)
- Removing slicer3 legacy code from slicer4 repository (that is, code which is not being used in backwards compatibility mode)
- What modules from the core should become extensions?
- Move all command line modules outside the core as extension? this would greatly reduce the package size and compile time, unclutter menus. What is the impact on ease of installation for end users?
- Node management in slice logic 
- Progress bars (and how to make interruptible loops)
- Overall Goals
- Stable core for extension developers
- Performance Improvements under heavy loads
- Search for common themes between 3D and Slice views - how to unify the interface concepts?
- How to hide controls so that the interface isn't as cluttered by default
- Multi-layer slice viewers