I fully agree. But at the same time we want to keep Slicer a swiss army knife because it’s so versatile that advanced users and “smart” people (who can find things in the wiki and discourse answers) can do almost anything they might want to do with their medical data.
What I was thinking about for example is to have a slicelet just for segmentation. So we wouldn’t have simple mode and advanced mode (which I think would open a can of worms and would be very hard to maintain and also we’d need to re-train existing users), but there would be simple custom apps for the most typical use cases.
This statement is not true as it is. There is a way to control volume rendering from SH, but it’s hard to find (right-click the eye icon and another kind of context menu shows up).
I know that SH could be and should be simpler. However, there are mechanisms in Slicer that prevent this currently. For example the fact that 2D volume display works in a completely different way from any other show/hide. Along the same line, regular show/hide of “3D” data (i.e. anything other than volumes) shows/hides it in 3D (DisplayNode::SetVisibility), and there is a quite de-coupled mechanism for 2D visibility for these data objects (SetSliceIntersectionVisibility). This second issue I tried to address by calling both when you click the eye in SH. But I haven’t figured out a good way for volumes. If somebody has a good idea to unify these concepts, it would be great.
Showing the volume in 3D by default might be a good idea, but the problem with that one is that usually a “raw” volume rendering shows up as a gray cube, and it would do more harm than good in my opinion. Maybe if we had a really stable automatic volume property setter…