Slicer3:UserFeedbackAndFeatureRequests

Return to Slicer3 Interface Design and Usability

Return to Slicer3 UI Design

Overview

Feature requests (software functionality) and Resource requests (provisions like documentation, software development tools, etc.) can be made on this page by both users and developers. Detailed descriptions will best help us to understand and address requests.

Slicer3's vision statement (for biomedical and other users without a computer science background) notes the following features planned in Slicer 3.0:

• New 2D GUI widgets with potential for automated testing of GUI functionality, plus high level widgets to support advanced imaging capabilities (e.g., transfer function editor)
• New 3D interaction widgets for direct manipulation and measurement of data
• Lowering the effort to add functionality
• New way to integrate external programs (execution model) as Slicer modules, including ITK
• Improved modularization and plug-in architecture
• Rearchitecture of the data and scene description
• Rearchitecture of the coordinate system structure
• Upwards compatible for the core functionality with Slicer 2.6 from a user perspective
• Easy porting of slicer 2.6 code
• Support Undo/Redo facility for interactive editing
• Improved rendering capability including GPU support
• Usability guidelines to promote software consistency

For users of Slicer 2.6:

• Slicer 3.0 will maintain the core functionality of previous versions, but with a cleaner and more integrated user interface.
• Slicer 3.0 will import scenes from previous versions of Slicer.
• NA-MIC will provide updated tutorials and documentation to help people use Slicer 3.0.
• The Slicer team will be available to help with the transition.

User Feedback & Feature requests

Slicer 3.4 Usability

• linking slice views and reformat widget should work for cardiac application
• Names of volumes in the slice views should take up all available space
• In the save module, there should be a way to
  • change the node name and
  • to link node name and file name
  • to show that node name and file name are editable (in contrast to Node status and type)
  • We should review the defaults for different node types (options panel)?
• Slices module needs a major usability overhaul
• volumes/Display
  • Window Level interface: additional feature to spread the visible part of the histogram to be able to fine tune w/l: range spreader like in the transfer function in the volume rendering module
  • Need lookup table for PET
• Loading data
  • consolidated loader needed: add volume, data, load scene add scene should all go into one consolidated panel
  • Dicom: expand to parse directory tree, not just single directory
  • Dicom: use window level in dicom to set intial w/l
  • Tree display to control visibility of images
  • How to handle organizing and loading DCE and variations (e.g. lung perfusion)
  • Consolidate all the load functionality to a single tabbed window with a Source button interface at the top (like the destination one for save).
  • Retain the configuration customizations
  • Tabs would be: Scenes, Volumes, Models, Other
    • -Scenes would invoke the current load scene panel and add a prominent "Add/Replace" toggle
    • -Volume would invoke the current add volume interface. We need to be able to customize the size of the windows on the right and be able to parse an entire directory tree, not just a single directory
    • -Models would use the current load from the models module
    • -Other would be used to load transforms, LUT's, Transfer Functions, EM parameter sets and such

Notes: NAMIC Summer project week list of interface fixes and feature requests

Preliminary notes about bugs and feature requests -- these will be reported to Mantis.

• ModelGUI: Request to add a wireframe option to the ModelGUI's display panel which toggles wireframe rendering for the selected model (or for all models).
• ModelGUI: Fix the way "Visibility" is exposed in the model hierarchy display. Right now, rightclicking on any child in the hierarchy raises a menu of options that includes a "Visibility" checkbutton. That button acts as a display of state as well as a control for the model's visibility in the Viewer. right-clicking any parent in the hierarchy displays the same menu. However, a parent's children may have different visibility in the scene. So the state of this checkbutton is undefined. This should be exposed in a better way.
• When Slicer is loading and displaying its splashscreen, the entire desktop is frozen and unaccessible on Linux (ubuntu)
• VolumesGUI: Range widget: hard to know when you've grabbed the "range center" so that mouse moves will shift the range rather than expand/contract it. TumorGrowth module needs coarse and fine control.
• Range widget: important to have the ability to control range expansion/contraction by a fixed increment, as a "fine-tuning" option.
• ApplicationGUI: We should publish the workaround for the screen update problem on Linux (System->Preferences->Appearance Set "Visual Effects" to none).
• ApplicationGUI: The control in the main Slicer window that allows expanding collapsing of the two viewer frames sometimes causes a bad display of viewer widgets depending on how they are packed. For instance, Selecting a "3D only" layout and expanding the bottom frame causes the slice viewers to be displayed badly. Recommend getting rid of the expand/collapse widget.
• ApplicationGUI: Slice Plane Reformat Widget: need to develop a visual language that's consistent among all 3D Widgets that can clearly display several widget states, including: "grab-able" and "is grabbed".
• ApplicationGUI: Sometimes the main window becomes fixed and unmovable on the screen (along with tkcon).
• Model display: When model clipping is turned on, backface culling should be off by default.
• DataGUI: In the Display and Modify Scene Panel, "MRML Tree" is probably not the best title for users who may know nothing of MRML. Current State? Scene Data? Scene Tree?
• DataGUI: MRML Node Inspector should probably be called something else (Object inspector?)...
• DataGUI: would be nice to allow the "Display and Modify Scene Panel" to optionally float free and be resized, to maximize its real estate when appropriate.
• SaveDataWidget: Save Data widget strongly needs a design treatment for usability. It's a complicated widget with lots of functionality, but much of it is poorly exposed. Here too, we need the ability to expand the vertical size of the multicolumn list. Currently, if the top-level widget is expanded, the multi-column remains the same size.
• ModelGUI's Hierarch & Display panel: The vtkkWTreeWithScrollbar allows you to grab and drag a model and move to another place in the hierarchy. If the hierarchy is long enough to require scrolling, the mouse has to hover over a very small scroll area in order to invoke the scrolling. This 'scroll area' should be bigger.
• ModelGUI's Hierarchy & Display panel might include options for visibility and color for each model. (Slicer2's GUI is a good reference for this.)
• ModelGUI's Hierarchy panel should have an option to make it into a toplevel, to maximize the size available to display large hierarchies. Difficult to work in this small space.
• ModelGUI's "Model Display" panel should be tidied up -- checkbuttons and their labels are not grouped together, and the widget alignment is really disorganized.
• FiducialsGUI's Symbol Scale is too small in extent to use.
• FiducialsGUI could use more careful packing
• ApplicationGUI: Need ability to Load transforms from File menu.
• ApplicationGUI: SaveDataWidget -- may not have saved some image data (clarify with Ron)
• Cache and Remote Data I/O Manager needs some attention: cancel a data transfer is not hookedup. Feedback should be given if loading from cache rather than remote site. Sometimes the first data transfer doesn't populate the GUI panel properly until loading is done.
• ApplicationGUI: Clarify the difference between "Load" and "Import" scene.
• ApplicationGUI: Expose simpler API for progress feedback and status bar text.
• VolumesGUI: Compact the "Load Volume" panel and make clearer that the "Active Volume" node selector applies to the "Display" "Info" "Diffusion Editor" and "Save" panels.
• VolumesGUI: Save Panel -- this allows a volume to be saved in another format. This functionality should not be hidden here, but should be centralized -- it be part of the save data widget?
• TransformsGUI: node selector should display "Create New Transform" if there are none already in the scene
• TransformsGUI: the word "Node" in the selector label is a term from the data model -- but not necessarily a term that will be intuitive for users.
• TransformsGUI: the mapping of Translation sliders (and entry widgets) to the matrix widget is intuitive, but the rotation sliders and entries are a little less. Should think about how to tighten up this display of translation and rotation represented in any transform matrix.
• TransformsGUI: Layout of controls at bottom could be presented better, and these widgets need some balloon help.
• FiducialsGUI: presentation should be packaged in cleaner way.

Notes: Nice features from other packages

• Persistent GUI toolbar for common functions (for Slicer: open scene, save scene, view configuration...)
• Active cursor in 3D view (elements that will respond to mouse actions highlight as the cursor passes over them). See sketchup for a nice example. The cursor shape can change, and there is text highlighting of the result.
• "Undo command beyond one action" for editing.
• Cortical drawing tool (3D drawing tool): In order to make drawing significantly faster, particularly for ROI which are complicated, it would be very helpful to be able to draw ROI on the 3D cortical surface where they are often clearest.
• Propagation Tool: Ability to propagate a drawn line (e.g. drawn on a 3D surface) medially to the gray/white interface. The result would be a surface that separates different regions of the cortex. These surfaces, the cortex surface and the interface between white and gray matter would outline an ROI. In a matter of moments, then, you could have outlined and rendered an entire ROI for one side (less UI more a module request)
• Function to measure length of a curvature line (specifically, measure length of curvature lines drawn along specific sulci) (less UI more a module request)

General GUI usability issues

• Collapsible module frames currently use an 'up' and 'down' arrows to represent that the panel can be collapsed or expanded, respectively. These icons are confusing to some. Replace with more conventional set of symbols.
• Checkboxes and radiobuttons: the default images that indicate state on these widgets appear to have the opposite meaning on different platforms (windows versus linux, for instance). Need to generate a SlicerWidget that uses a standard set of images for checked and unchecked, consistent across platforms, back propagate this into existing code, and include requirement to use this icon in the human interface and style guidelines.
• Menus: dropdown menus on windows display scroll icons at the top and bottom if the number of menu items to be displayed is too numerous to fit on the screen. On other platforms (linux) the Tk widget doesn't have these scroll icons and some menu items become inaccessible. Right now menus are given column breaks, but this is not a scalable solution. A KW fix? Modify menubuttons to use listbox with scrollbars instead of menu?
• Some infrastructure for pop-up in-depth help would be useful to use across modules.
• Mouse modes: currently, the unselected mouse-modes read as being disabled widgets.

General application feature requests

• Look and Feel should leverage training provided to end users by the different office packages.
• Interaction should maximize skill transfer from slicer2 where reasonable.
• Better navigation among modules ( if for instance several (more than two) modules are being used, it would be nice to easily move forward and backward among them according to their use-history.
• Ability to organize modules in tree-structure using GUI (like bookmarks in a web browser)
• Add ability to turn off/on modules to be loaded using GUI.
• Provide more extensive help menus for general slicer commands and modules.
• Some more intuitive interpretation of mouse events in the 3D View: when is the view being manipulated, and when is a "pick" or a "pick and manipulate" happening? Maybe some kind of mouse-mode switches can be available in the icon toolbar.
• Ability to set default parameters like add a default file format parameter so that we can always set it to NRRD. Other options may be "interpolation mode" (off) or default view.
• Possibility to load multiple volumes of the same type at once (for example select the 10 labelmaps at the same time, then click "apply").
• Ability to deal with volumes (ie DICOM CT volumes) where slice spacing is not uniform.

Slice windows

• More than just 2 layers (FG and BG) in the Slice windows, if desired. Analogous to Layers in Photoshop, it would be nice to create an arbitrary number of layers and choose the manner in which each is composited. Should still be simple to use only FG and BG if those are the only two layers needed.
• Fiducials: Ability to see the selected fiducials in the 2d slices. (at the current slicer26 setup, once a fiducial is selected it's only visible in the 3D view)
• Slice toolbar that goes in each panel in the 4x512 view: change from one that shows up when you mouseover (as in slicer26) to one that you click to activate or even to a floating toolbar kind of like the "Volumes" levels and thresholds toolbar.
• Cine: Slice viewer control to cine through a stack

Editor module

• cross-reference can be turned on and off
• different styles for the cross-reference: how to not distract from the central voxel
• split functionality into tool box and module
• access to toolbox is persistent in the GUI
• creation of label set automatic without user interaction for default setting
• different erasers and paint tools (kww in 3D?)
• assumes existence of integrated volume rendering, does things like connectivity, morphologic operations, potential for scripting down the road.
• Possibility to draw a label in multiple slices at once.
• Option to save a labelmap but keep the former version in the MRML tree

Save module

• list with checkboxes for what to save
• display of what is already saved
• option of specifying relative or absolute path
• default organization into directories with MRML file in top level
• save as allows to save the entire "tree" into a new target location
• remove "save with options"

DTI module

• Better integration of eddy current correction (Deft from Gordon Kindlmann) in Linux. i.e. ease of use from command line or GUI. Current use requires full path input to use Deft from slicer.
• Output of results of eddy current correction during processing. Some type of progress bar, step list, etc. would be very helpful to gauge the progress of the program.
• Integrate a segmenting tool for frequently used ROIs
• Replace 3D tubes with single lines in order to get a faster and bug-free application of tracography
• Need fewer steps between growing and drawing in tractography
• Need a user-friendly way to save and load prior used ROIs
• (PS-Great work done on improvement of saving, changing colors and filters!)

fMRIEngine module

• Add help text describing how to interpret the brain activation color map
• Generating design matrix for the first time takes too long right now; implemented in Tcl -- move to VTK/C++.
• In Ising Priors tab, the GUI asks us to load a label map, but is expecting a mrml file (and then should be clear about whether we are selecting a label map or mrml file in the slice window pull-down menus).
• Priors: may want to use a larger range of label values to label grey matter, instead of a single label ( for instance to indicate partial voluming).
• Priors: change the range of the number of iterations to approximately 50, rather than the large range provided, and a better default might be 10 iterations.
• Priors: can we volume render the p-value activation volumes?
• Priors: finish implementing the help text.
• When translating to Slicer3 environment and extending this module, think about this module's value to three key groups of users -- neurosurgeons (who may principally want a binary result -- voxel active or not?); neuroscientists (who may be principally interested in running many analyses with the same configuration, performing group comparisons, and deriving numerical and visualization output to support publication); and image analysis researchers (who will want a flexible, extensible activation detection and analysis environment).
• Facilitate group comparisons: warping individual analysis results into atlas space?
• Priors: may add a slider to adjust the strength of neighboring voxel influence
• Save & Load: Essential to provide ability to save configuration, data and results within a directory tree that reflects an organized study (MRML representation)
• Methods for cluster signficance may be useful as inference engines in addition to Priors.

Fiducials module

• Fiducial selection: possibility to click on a voxel and automatically set the fiducial at the middle of this voxel.
• Fiducials visibility in slice windows: Ability to see all the selected fiducials in the 2d slices. (at the current setup, once a fiducial is selected it's only visible in the 3D view)
• Fiducial visibility: need to save and restore fiducial visibility state in a MRML scene.
• Want to be able to turn fiducial visibility on and off globally, and also just in the 3D viewer, and just in slice viewer?

EMSegment module

Please also see the list of future work at the primary EMSegment wiki page.

Model maker

• "model editor": update the model automatically when the corrsponding labels change. In order to create smooth models for publishing, currently the user has to change the labels, then create the model, then change the labels again and so on.

Screen shots

• make sure we can save screen shots of the 3D viewer at a specified size and dpi resolution for presentations, publications. Can this be done with off-screen rendering, since images for print may be very large?

Systems Interface

• The "Xenios¹ Challenge": can slicer3 have a web server interface?
  • Ability to view the current scene in a web browser
  • Ability to download data from the scene
  • Ability to upload data to the scene
  • Ability to invoke modules and other analyses
  • Full web services interface?

¹: Named for Xenios Papademetris of Yale who suggested that this should be a standard feature of software.

Slicer3 convention requests

Discussion of Slicer3 Mouse and Keyboard behaviors has been moved to Slicer3:EventBindings.

Toolbar

The current mouse mode will always be visible in a toolbar in the slicer display. There will also be hot keys to select specify mouse modes.

Resources requests

Developers: what kinds of resources do you need to make module development easier? Slicer users: what kind of resources outside of software features (i.e. documentation, tutorials) do you need to make Slicer3 easier to use?

Return to Slicer3 Interface Design and Usability