I have created a Slicer PR with some changes that puts Segment Editor effects into categories to improve usability so that users have a better understanding of the types of segment editors effects. This is implementing a brainstormed idea by @Umesh_Persad and @lassoan in Based on Segment Editor User Interface Improvements. This PR currently doesn’t address all improvements to Segment Editor layout as mentioned in that previous discourse thread, but address a single enhancement of placing segment editor effects into categories. I forsee a new category being “Automatic” that is more AI based. What do you all think?
There is obviously more vertical space being used with different categories on their own row, however it is in the name of usability/understanding. A long list of effects as it is now is often intimidating about knowing which one to use. It frequently requires using them all to understand what they do, but I know some people that take the approach of not trying things out because they are afraid of messing something up. They want to know more about an effect before they commit to clicking it.
The “Uncategorized” effects are to represent what non-Slicer core effects might look like if they don’t have a category defined for them yet. These are currently those from the “SegmentEditorExtraEffects” extension.
If categorization is desired:
Do we limit the number of categories to a few + an other/uncategorized? Or could an extension define 5 new effects that add 5 new categories? I currently have provided the category in a hardcoded manner in the PR, but could define the category in the effect file instead.
With this row-wise organization, where would be the current masking/editable field? For example if I click Threshold, would it popup right below the threshold and above Global row? If not, I don’t think this would be very usable arrangement.
Couple other comments (not for this specifically, in general). Our effect buttons are too big. That’s mostly because of the the names are also included in the button (look at the size of Fill Between Slices, Logical Operations). If we think icon only buttons do not easily explain what the function is, let’s remove the icons and only have the labels as multi line. For non-english localizations this will require creating the buttons in the native language, but probably that’s not a big thing.
If this is not viable, can we remove the text from the buttons, and only show up when it is hovered over?
Plus, the wide buttons causing the width of the module panel to increase automatically, which is I find it a very disturbing behavior.
If we make buttons smaller, I think this will open up a way to create a reasonably sized toolbar that will have most of the functionality of Segment Editor contained (similar to what @smrolfe is doing for markups).
I think in most cases you mean that the effect buttons can be too large at times (not the icon). This being because the text in the button makes it larger rather than the icon.
I do think the icons do provide some information about what the effect does, but not all the necessary information and neither does the name. The effect buttons already shows a hover tooltip that is the segment effect name, so if we want to enforce equal size segment editor effect buttons by way of equal size icons with no text shown below, then that could be possible. Other applications with various tools for image annotating, usually use an icon only, with the hover tooltip detailing both the name of the effect and also a short description of the tool. The addition of a short description in the tooltip could help if the text was removed from the segment effect button.
Note that this actually happens not due to the effect button size, but rather the effect options. A specific effect options can be larger in width than others which causes the module panel to increase when it is selected. I’m not addressing that in this PR, but that is another issue that was brought up for general segment editor improvements.
Currently the positions within Segment Editor are all still the same. This PR is changing positions of effects within the current location of the segment effects.
If you want masking options moved below say “Threshold” effect button, then that would also mean that masking options would now be above the effect options. Currently all effects are in a stacked widget with the appropriate page selected based on the selected effect.
If both of those opened directly below the effect, then I would have further to travel if I wanted to go the “Watershed” effect next as all other categories and effects below would get pushed below the effect options and masking.
Yes, but they would be in a place that would link the user actions to the effect.
I still think the major improvement will come from reorganizing the buttons to take up much less space, so that we can develop a toolbar where the effects and a segmens are shown, and these tool specific settings are displayed in the module bar.
I actually would be against development towards more actions in the toolbar and rather implement functionality into a ribbon interface. A toolbar is putting functionality on one row, but I don’t think segment editor can be put into such limited space.
is ribbon interface a possibility with QT? If so, I agree it makes sense…
The toolbar I envision is unlikely to have the full functionality of the module, but helps to reduce the clutter within the module view so that we don’t have to scroll up and down in the module panel.
@Umesh_Persad did prototype a ribbon based interface. Ribbon based interface essentially uses a QTabWidget.
As it relates to this topic of organizing segment editor effects into categories, do you think that is helpful for improving understanding about the type of effects? Is the increase in number of rows for each category a deal breaker for you because the effect options for say the “Manual” category of effects are now farther away than they are currently?
I am just not sure if category adds a meaningful level of understanding of effects. These are all standard image operation effects (with slight difference such as islands vs connected components). Anybody who has used a 3D image processing software before will know what they do. Anybody who is starting anew, will have to experiment on each of those tools.
Also when I read global, I may interpret that the outcome of that operation will overwrite all other existing segments (which is true by default, but not so much if allow overlap is selected).
I appreciate the effort, and hopefully will be useful, but I am concerned this will make the segment editor module panel vertically too long. It is already too long, and we are proposing to add more rows.
This is an interesting approach, what about using tabs to save space?
I think the categories may confuse the user more that they help.
I am working with Pixinsight a lot, an astronomical image processing software, and I very much like it´s functionality to choose effect windows from a menu, see all the effect options in an big and well tooltiped options window, “throw” the effect onto a astro image or “draw” the effect option window as icon onto the Pixisight desktop. A geat way to define your workflow by ordering and moving around the icons, opening the effects on demand and throwing them onto the image.
I appreciate the attempt to simplify. However, I also agree that it is not clear that grouping into categories will be very helpful. It takes effort to understand exactly what each effect is and how it works, as well as things like how each effect interacts with masking settings and what options there are within each effect. For me, access to the complexities of all of these options is one of the reasons I find Slicer to be the best tool I work with. Grouping the effects into a few categories would not help me. For new users, I also think general categories like the ones listed might be more confusing than not. “Threshold” seems like a “Global” effect, more so than “Margin”, for example.
To save space, what if the segment table and effects areas were (separately) collapsible, and when collapsed, showed the currently selected segment and currently selected effect? When one wanted to change effects or change selected segment one would expand the section and select.
On another topic that has been discussed here, I like having the text labels on the effect buttons. It is much easier for me to remember the tool by the name than by the icon. If the text label was gone, I would likely need to hover over icons to remember what they were, which would be a much more tedious process than glancing through the labels.
I agree that it is currently hard to locate effects and it would be great to improve this. Large size of the Segment editor module GUI is a problem, too, because it forces the user to scroll a lot. We would need layout improvements that address both issues.
Introducing rows and large category labels would help with finding effects, but it would uses much more space, so we would need to scroll a lot more.
I quite like the vertical toolbar shown here. We could probably have two columns, if needed. It would be a regular toolbar - no flow layout, button labels hidden by default (very easy show/hide, just a flag).
is ribbon interface a possibility with QT? If so, I agree it makes sense…
Not really. We could use similar high-level layout as ribbon controls, but tabbed widgets and groupboxes are just a very small part of the whole ribbon concept. I like the ribbon interface and it would give Slicer a modern look, but it would require a lot of work to be implement and it should be then used for the whole GUI, not just for Segment Editor.
Thanks to all the efforts of @jamesobutler, the new Segment Editor layout is now ready - see more information (and provide any feedback and suggestions) in this topic:
