Difference between revisions of "Slicer3:EditorUsabilitySessions"
From NAMIC Wiki
| Line 5: | Line 5: | ||
=== Slicer application interface === | === Slicer application interface === | ||
| − | ''' | + | '''General:''' |
| − | + | * In Slicer2 workflow, “apply” is currently being used as a “preview” and “undo” is used to back out of an unsatisfactory operation. In Slicer3, instead of “apply” and “undo”, we should consistently implement “preview”, and “apply”. Though these may be implement the same operations programmatically, the concept of preview has less implicit stress for the user, who won’t worry that their original data may become unrecoverable. | |
| − | * | + | * Visual cue: Should we assign a reserved color or visual appearance for ‘Editor preview’ so that in complicated visualizations, it will be clear which regions are being affected by the operation in preview? |
| − | * | + | * Provide multiple undo and redo as well. |
| − | * | + | * Inside editor module, users agree that having the hidden slice controller (which reappears on mouse-over) is very useful. However, sometimes while scrolling thru slices using the slice controller’s scale, the mouse travels off the controller bringing focus back to the slice window by mistake, and resulting in unintended drawing in that slice. This is very frustrating and requires time to clean up. We need to consider a workaround that |
| − | * | + | * Editing is done in all orientations, but the original acquisition plane is used, when possible, to make challenging decisions. Feature request: Might be good to visually indicate which of the slice viewers is displaying slices in the plane of acquisition. |
| − | + | * Nobody we spoke to is using the Draw2 module, though having a simple spline tool in addition to points, lines and polygons to draw regions would be nice. | |
| − | + | * Within the editor, it would be nice to have a single location in which a user can: ask for a statistics/metrics report (including intensity min, max, mean, std.dev., and volume) for a single region or for all defined regions, and to have the option to save this information out to a text-file. Currently, MeasureVol module will give volume measurements for all labels (user can’t select a single one) and writes a text file; and Editor->Details Drawmode has the intensity statistics, no volume measurements, and no ability to write the text file. | |
| − | + | * Existing hot-keys: Strong recommendation not to remap. Very efficient keyboard operations are used by everyone we spoke with: left hand using index and ring fingers on right and left arrows to move between slices, middle finger on up arrow to apply a point, and on shift key to view in all slice planes simultaneously; right hand moves the mouse to specify point location. Remapping the up and down arrows to also move between slices would strongly impact what has become very natural and efficient keyboard drawing. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | * | ||
| − | * | ||
| − | * | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | * | ||
| − | |||
Revision as of 05:57, 10 January 2007
Home < Slicer3:EditorUsabilitySessions<< Back to 3DSlicer Usability page
User feedback for design of the Editor Module
Slicer application interface
General:
- In Slicer2 workflow, “apply” is currently being used as a “preview” and “undo” is used to back out of an unsatisfactory operation. In Slicer3, instead of “apply” and “undo”, we should consistently implement “preview”, and “apply”. Though these may be implement the same operations programmatically, the concept of preview has less implicit stress for the user, who won’t worry that their original data may become unrecoverable.
- Visual cue: Should we assign a reserved color or visual appearance for ‘Editor preview’ so that in complicated visualizations, it will be clear which regions are being affected by the operation in preview?
- Provide multiple undo and redo as well.
- Inside editor module, users agree that having the hidden slice controller (which reappears on mouse-over) is very useful. However, sometimes while scrolling thru slices using the slice controller’s scale, the mouse travels off the controller bringing focus back to the slice window by mistake, and resulting in unintended drawing in that slice. This is very frustrating and requires time to clean up. We need to consider a workaround that
- Editing is done in all orientations, but the original acquisition plane is used, when possible, to make challenging decisions. Feature request: Might be good to visually indicate which of the slice viewers is displaying slices in the plane of acquisition.
- Nobody we spoke to is using the Draw2 module, though having a simple spline tool in addition to points, lines and polygons to draw regions would be nice.
- Within the editor, it would be nice to have a single location in which a user can: ask for a statistics/metrics report (including intensity min, max, mean, std.dev., and volume) for a single region or for all defined regions, and to have the option to save this information out to a text-file. Currently, MeasureVol module will give volume measurements for all labels (user can’t select a single one) and writes a text file; and Editor->Details Drawmode has the intensity statistics, no volume measurements, and no ability to write the text file.
- Existing hot-keys: Strong recommendation not to remap. Very efficient keyboard operations are used by everyone we spoke with: left hand using index and ring fingers on right and left arrows to move between slices, middle finger on up arrow to apply a point, and on shift key to view in all slice planes simultaneously; right hand moves the mouse to specify point location. Remapping the up and down arrows to also move between slices would strongly impact what has become very natural and efficient keyboard drawing.
