In the last decade, we’ve used Slicer for probably over a hundred different projects. We’ve found that projects go through several phases and current Slicer capabilities are generally satisfy needs for each phase:
- Engineering prototyping
Use Slicer as is, to find a suitable workflow. In this phase, we experiment with a large number of modules, use it in various combinations. We certainly switch between many modules while using Slicer this way. Module selector controls (previous, next, history) and search (hit Ctrl+F, type part of module name, then hit Enter) can make switches relatively painless.
- Clinical prototyping
Once a clinically acceptable workflow is determined, we develop scripted module, which sets up the scene (create transforms, set default visualization options, etc.) and provides a user interface that makes all necessary features available in one place. These prototypes are still mostly used by researchers or engineers because you can still get lost among the many features and options available, but the software can be used quite efficiently (number of clicks to achieve a certain operation is already minimized).
- Clinical use
Once a prototypes proves to be clinically useful, you can create a custom application (slicelet) from your module by disabling/hiding all unnecessary features, customizing branding (replace Slicer logo, etc. with your own company logo), further optimizing your custom module. in this phase, you also need to produce a fair amount of documentation, test results, etc. for obtaining regulatory approval. In this stage, the software is simple enough so that it can be operated by clinicians who are not experienced Slicer users.
Showing multiple module user interfaces at once:
- might slightly help in some cases in engineering prototyping phase, but usability is not really a focus of this phase anyway. In this phase, you spend your time with figuring out what modules to use, with what settings, with what combination of other modules.
- is not a usable approach for clinical prototyping (or later) phase, as you would need to do a lot of manual work (setting up the scene, arranging module user interfaces, paying attention to use modules in the correct order, etc).
Since this feature would have narrow use case and could potentially make the user interface very complicated, there is very little incentive to implement it.