This topic is forked from the meeting minutes of weekly hangout on 2018-Dec-11.
We discussed how the UI and UX could be improved. Here is a very short list, we should probably create a poll or conduct a user study …
These are great ideas to discuss. It would be important to make simple things as simple as possible to do in Slicer.
If we get to know any specific issue then we can address that. But addressing usability in general is really hard.
I’m not a believer of having a “simple mode” for powerful applications, mostly because all the attempts that I have seen have mostly failed: in applications that I did not know, they did not make learning any easier; in applications that I knew already, it just made things harder to access. But we can certainly evaluate this option for Slicer, maybe we can do better.
Predefined workspaces/perspectives optimized for certain tasks seem to be a good idea, too, but based on my experience with various software, they do not help much; and flexible layouts make the software more difficult to learn because my screen always looks completely different than those shown in examples and tutorials. Experts don’t use predefined workspaces much either, because they rather set up their highly optimized workspace; but ability to customize layout and save/restore it is a useful feature for experts.
@jcfr mentioned the issue with users not understanding the ‘eye’ icon in the volume rendering as an example of something that’s obvious once you know it but hard to learn. This struck me as a specific usability thing we might address. One option, noted above, would be to have newly loaded volumes show in 3D like the do in 2D (probably with a preference option to turn off this behavior).
I suspect there are many other similar features we could (carefully) consider and introduce to help both novice and advanced users while still keeping unified interface for documentation and tutorial purposes.
The challenge is, it is hard to measure whether there are consistently painful issues across different user domains and whether it makes sense to commit dev time to fix them. But if you are looking usability issues, I offer one observation below:
One frustrating point that I consistently observe when I train new users is that the existing default 4 up view and modules tab is not linked very well. Your segmentation might be a completely different then the volume you might be looking at the slice view or in volume rendering window. I am not sure what the solution might be, but perhaps the ‘simple mode’ would restrict the user to load only one ‘master’ volume at a time, and visibility icons (whether they are in the modules tab or in slice views) are linked, and every other dataset would be stuff derived from this ‘master’ volume.
Hi Steve,
I like this idea a lot.
Best
Ron
For me, I’ve noticed that users frequently struggle with the fact that you can be modifying/manipulating data from the module GUI, but not actually viewing what you are manipulating in the main layout. This leads to frustrations that nothing appears to be happening.
In the custom application that I work on, we try to make it simple enough to users that might not even be super proficient with computers in general. We have kept one volume shown in red, yellow, green slices instead of allowing a volume shown in red and then maybe a different one in yellow.
The fact that Slicer can do so many things is great, but also extremely overwhelming. It’s almost like using Adobe Premiere Pro to edit video for the first time. I guess there’s a reason why there is an iMovie and why there is a Final Cut Pro. Maybe trying to appeal to the casual image technologist could broaden the user base in a manner that could bring in more funding for Slicer development to support new functionality for advanced power users. Also, hopefully new developers with the rise of python programming.
We noticed this issue a couple of years ago and developed Subject hierarchy module to address this. Now Subject hierarchy is available as the first tab in Data module.
Subject hierarchy shows all displayable data in the scene and you can perform all basic operations (show/hide in all views, delete, rename, apply transform, etc.) without switching modules. Novice users don’t even need to know about any other modules.
When you want to edit properties of a node, you can right-click on it and select Edit properties. This takes you to the module appropriate for editing the selected node and it also selects that node as active node in the GUI. The user does not need to know which module is for editing a particular node type or select the active node manually.
I think what we miss is better promotion of the Subject hierarchy. We should advertise it much more in tutorials and make it easier to find when using the application. For example, when after the first data set is loaded (but at least when DICOM loading is completed), we should automatically switch to Data module.
Yes, I agree. I think the Data Module should be default opening tab instead of Welcome. That’s what I do when I train new users; the first thing I show them is how to make the Data module as the default one.
While subject hierarchy is an improvement, it still doesn’t resolve the some of the issues. E.g., I can’t control the volume rendering from subject hierarchy. When I click the eye icon, it simply removes it from the slice view, whereas my expectation as a novice would have been to disable/enable the 3D rendering as well. Or at least in my version of subject hierarchy (r27534), there is nothing indicating an option for volume rendering.
That’s what mean in the ‘simple mode’ (or whatever we want to call) everything needs to be tied together much more cohesively.
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.
Exactly.
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…
@cpinter. Thanks for the pointer. I never knew it existed! Making that more prominent would be more helpful.
I don’t think volume rendering coming like a box is necessarily a bad thing. At least it shows people that they are making progress. The challenge I have seen with the new users is that they can’t find the place to modify the transfer function (because Scalar Opacity Mapping tab is collapsed by default).
Yes we have ideas for that but none as good that we’d just go for it. The best idea so far is that we separate 2D and 3D visibility into two columns. Wouldn’t be hard to do either. But in general a consensus would be necessary. Unfortunately I cannot go to Las Palmas this time, but continuing this discussion there (including the rest of it, about simple mode and slicelets etc.) and reaching a decision would be really great.
Unfortunately I can’t make the PW either.
I like two columns idea. I also would suggest making icons a bit bigger. On 4K screens (27") they look tiny and sometimes hard to tell what they show.
Two columns might help, but we should think about other solutions, too, because two columns would mean that we need to click twice each time we want to show/hide a node. Also, if we add separate columns for 2D and 3D views, we may also need to add separate columns for table, plot, etc. views for consistency (table could be shown in a table and/or plot view). Another issue is that you cannot always easily toggle 3D visibility: if you turn off a model’s visibility then both 2D and 3D views will be affected. Maybe it would be better to keep a main visibility icon and adjust additional visualization options similarly as it is done now?
ParaView allows highlighting a view (by clicking in it) and then show/hide applies to that view. We could consider this approach.
In some other applications users drag a node to a view to display it in that view.
My point of view as a user : it is simple enough.
This a very powerful application with a modular design to do tens of kinds of jobs. It is for users who want to invest time and effort to master it. They are not expected to master everything; I don’t master everything in Slicer for instance. But most users I know have the Windows-borne expectations : the application must know what they want to do before they move the mouse.
My opinion is that you would waste much developer’s time trying to accomodate such expectations. You’ll next find users who will still want it to be, not simpler, but as they wish it to be some day, and another way some other day.
Just my 2 cents.
Cheers.
I respectfully disagree.
It is not really so much about what users want now and they would want something else tomorrow. It is about identifying common issues that frustrate novice users who give Slicer a try before moving into something else.
Blender has always been like that to me. I always thought making a model spin around freely and capture its animation shouldn’t be this hard. That’s all I want to do in it. But because it is so hard, I never saw value in spending that much time investing on a single simple task. Have I done that, I would probably be using Blender for quite a bit of interesting scientific animations.
Slicer has been that way to me (and the people I train). I might be wrong but, I wouldn’t be surprised if 95% of the people is using 1% of the functionality of Slicer. The challenge is identifying that 1%, and making it easier so that we retain users, who see value in investing more time in more complex things. To me that basis has always been the core visualization and segmentation capabilities. Fixing common pitfalls for new users seems like a valuable use of time and a good way to keep project funded.
I actually agree with both of you. I agree with @chir.set because I don’t think we need a “SimpleSlicer” and a regular Slicer to keep novice users happy, but it can be achieved with reasonable time investment. And I agree with you that we should strive to simplify the most trodden paths in Slicer even if the whole thing is extremely complex.
- Create two different applications ? Or have theme like Blender ? Simple vs Advanced
I am with the theme idea. Many radiologists used to use tools similar to Horos. It would be nice if we have a theme that creates a similar navigation functionality.
I am new here. but I was fascinated by 3Dslicer. I am eager to learn how to use it, but there are few videos to learn this powerful tool. nice to see you.
I’ll copy below posts from another topic that ended up discussing simple Slicer user interface.
You can start Slicer with a script that hides all user interface elements that you don’t need. Maybe it could be then considered as a “simple DICOM viewer”. You can also run it in a docker container and make it available in a web browser (you then don’t even need to install anything).
@ihnorton How difficult would it be to make VNC access available for Slicer running using binder? Slicer could then work pretty well as a web-based DICOM viewer.