Improve grid stride GUI

haesleinhuepf commented 1 year ago

🚀 Feature

I propose to update the Grid view dialog.

Motivation

The small dialog for modifying the Grid view is not user-friendly / self-explanatory. It is not obivous that changing stride from -1 to 1 changes the view order of images in the grid view.

Pitch

I propose to implement a pull-down where users can configure Top down and Buttom up to change the view order (grid stride).

Alternatives

Additional context

I'm working with napari 0.4.17

brisvag commented 1 year ago

Stride allows for much more than just "bottom up" and "top down", though. How do you suggest to still allow stride of 2, for example?

haesleinhuepf commented 1 year ago

I don't understand what grid_stride=2 does. Can you give an example where this appears useful?

grid_stride=-1:

grid_stride=1:

grid_stride=2:

psobolewskiPhD commented 1 year ago

@haesleinhuepf stride is step-size; it's from walking: people with a longer stride take longer steps and walk faster (and can be annoying in groups). stride 1 means one by one, stride 2 means you step over 1 to the next, so every other one—imagine walking on a chessboard—etc. Plus or minus indicates direction/order. This can be seen in your screenshots. Is this more clear? Is this maybe a documentation issue?

haesleinhuepf commented 1 year ago

Is this maybe a documentation issue?

I think the user interface needs to be improved.

psobolewskiPhD commented 1 year ago

I guess I'm not clear where the issue lies and what we should change. I think grid width and grid length are clear, right? So then, the issue is with the stride parameter? Given my explanation of stride above, does that help make it clear? I get this can be tricky simply due to the nuance of the english language, so I just want to be clear on what the actual issue is. Can we change the text provided by the ? to make it more clear what the effect of the parameters is? Or is it that you'd prefer a different effect all together. Edit: Just in case, here is what I see (not super elegant, I admit) for the ? for grid stride:

The screenshot is small, so here's what the text says: Number of lavers to place in each grid square before moving on to the next square. The default ordering is to place the most visible laver in the top left corner of the grid. A negative stride will cause the order in which the lavers are placed in the grid to be reversed. O is not a valid entry.

haesleinhuepf commented 1 year ago

I guess I'm not clear where the issue lies and what we should change

I propose to have a pulldown where the user can choose the layer view direction "top-down" versus "bottom-up".
Furthermore, one could add a "group n layers" numeric field (where I don't see a real use-case for).
Last but not least, also "width=-1" is nonsense from a UX point of view. I propose to add an "autosize" checkbox that disables the width numeric field if activated.

If a GUI is complicated to explain, you can explain it in the documentation, which makes it even more complicated to use. Or you simplify the interface. Think of how a new user sees that panel. How would it need to appear so that a newbie immediately knows what it does? Let's focus our discussion on this aspect.

Czaki commented 1 year ago

After reading the discussion I see the problem, but still do not have an idea for a better UI. It will be nice to have a draft (image) of the interface.

brisvag commented 1 year ago

I agree that unless you already know what it doesn't it's not immediately intutive what the controls do. My remark was simply: we should not sacrifice behaviour for that.

Furthermore, one could add a "group n layers" numeric field (where I don't see a real use-case for).

There are several people who use it; for example, if you have a bunch of images each with their 2 own annotation layers, you can have them 3 by 3 in the layerlist and set a stride of 3, and you're good to go. A "group n layers" field could definitely work!

Last but not least, also "width=-1" is nonsense from a UX point of view. I propose to add an "autosize" checkbox that disables the width numeric field if activated.

So in the end yo'd have something like:

ordering dropdown: top-down/bottom-up
width field which can be disabled and set to autosize with a checkbox
same for height field
group [n] layers field

Seems reasonable to me!

By the way, @melonora and I are working on a redesign of the grid canvas over at #5348; please take a look at that @haesleinhuepf and let us know what you think! This is definitely the time to consider this kind of improvement as well.

psobolewskiPhD commented 1 year ago

I think in the short term the tooltips could be made nicer and maybe clarified.

melonora commented 1 year ago

Regarding reversing the order would adding a checkbox reverse order help be better and relatively easy to implement for the short term? In that case, we wouldn't allow stride to be -1 anymore. Might be more effort than it is worth but would bring more clarity without a tooltip.

I agree that a group [n] layers field would be more semantically correct than stride, which is taking a step of size n instead of grouping multiple layers together in the convolutional neural network lingo. For stride in the sense of taking a step of size n, I do not see a use case.

Regarding the use of group [n] layers, I think it would be good to consider whether this should have a value of type int or whether we would allow users to give a sequence of integers equal to the number of grid tiles. For example when showing 6 grid tiles and the user providing the sequence 2 4 1 5 5 6 the first tile would hold the first 2 image layers, the next tile the following 4 image layers, and so on. A use case would be to display a marker set corresponding to a particular cell type in one grid tile.

brisvag commented 1 year ago

Regarding the use of group [n] layers, I think it would be good to consider whether this should have a value of type int or whether we would allow users to give a sequence of integers equal to the number of grid tiles. For example when showing 6 grid tiles and the user providing the sequence 2 4 1 5 5 6 the first tile would hold the first 2 image layers, the next tile the following 4 image layers, and so on. A use case would be to display a marker set corresponding to a particular cell type in one grid tile.

This is neat, but I think they are different enough that maybe we should consider splitting them in two mutually-exclusive options. Let's add it to the todo for the new grid mode :P

napari / napari