Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scoping of Well-Field Grid View - Round 3 #52

Open
gusferguson opened this issue Aug 18, 2016 · 9 comments
Open

Scoping of Well-Field Grid View - Round 3 #52

gusferguson opened this issue Aug 18, 2016 · 9 comments

Comments

@gusferguson
Copy link

gusferguson commented Aug 18, 2016

Following feedback and discussion on the first round of mockups: Scoping of Well-Field Grid View - Round 2 - #51

Note: For convenience mockups show OMERO.insight only - exactly the same will be done in OMERO.web.

Comments addressed:

From @jburel

  • for spatial view you will need axis and units so people have an idea where fields are physically
  • red grid will be useful when we cannot view the full plate. We will probably need a way to minimize it, similar to bird-eye view
  • spatial view likely to be too large to be practically shown in LHP
  • layout of fields in spatial view usually scattered - not a neat grid
  • we could display in LHP if the grid is very small and the "thumbnail/black dots" indicate where the fields are. "Thumbnails" cannot be used for visualisation. The position needs to be indicated in tooltip.

Grid in spatial view

  • tooltip shows Field # and position

wellgridview-spatial-view-bottom-grid-tooltip

From @bramalingam

Using abstracted well for position grid in LHP

  • tooltip shows Field # and position

46 Fields in Well

wellgridview-grid-spatialbe-tooltip-small

Larger squares in LHP position grid

wellgridview-grid-spatialbe-tooltip

13 Fields in Well

wellgridviewgrid-bottom-spatial-be

To follow:

From @will-moore - need to show whether focus on Well vs Field

  • highlight top sub-pane when Well selected
  • highlight bottom sub-pane when Field selected
@bramalingam
Copy link
Member

The spatial view with the grid layout in the background in the LHP looks the best.
Another small issue to think about, what happens to this view when multiple wells are selected.

There can be wells with different number of fields and the spatial view might break down in that case.
(in a multi-select scenario) : May be show the combined set of fields for all selected wells in the spatial view (just to highlight the coverage within the well)?

And also are we synchronising the selections on spatial view (LHP) to the fields selected on the RHP?

@will-moore
Copy link
Member

will-moore commented Aug 19, 2016

Looking good. Spatial view with little squares in LHP works well.
@bramalingam Good point about multiple Well selection - I guess we just show the sum of all the fields in the spatial view.
Do we always show the spatial view if we have spatial info? OR show it by default and allow it to be hidden? OR not show it by default and allow it to be shown? I guess the cost of loading the spatial data is pretty low, since we are already loading all the WellSamples for the selected Well(s), so maybe nice to show it by default.
@bramalingam I'm assuming we're sync'ing the selections and you can use the spatial view squares OR the Image Thumbnails to change the selection.

@bramalingam
Copy link
Member

bramalingam commented Aug 19, 2016

Am very keen on viewing the spatial info. I've often been asked about the position of the Well/Field for QC purposes. Just thought I'd highlight the multi-selection point. Yes sum of all fields looks like the most straight-forward approach.

And I like the smaller squares (in the spatial view with the grid), larger and overlapping squares gives one the feeling, that the fields are overlapping, which might not be the case in most situations.

Syncing the spatial view with the fields might be tricky in multi-select cases , do we show just the selected field alone in the column data for the fields? (sounds like the obvious thing to do)
when F1 is selected in a the LHP:

Field view can look like :

        F1
W1
W2
W3

when the default view(without any selections on the spatial view) looks like :

      F1   F2   F3
W1
W2
W3

@gusferguson
Copy link
Author

gusferguson commented Aug 19, 2016

Additional mockups:

  • multiple Wells selected
  • no field selected
  • focus on Well in RHP
  • highlighted Plate portion of centre panel
  • spatial "bird's eye" in LHP - shows multiple wells
  • LHP "bird's eye" tooltip has Well row-column and Field # in it

wellgridview-multi-well-select-no-field-spatial-be

  • multiple Wells selected
  • field selected
  • focus on Field in RHP
  • highlighted Fields portion of centre panel
  • spatial "bird's eye" in LHP - shows multiple wells
  • LHP "bird's eye" tooltip has Well row-column and Field # in it

wellgridview-multi-well-field-select-spatial-be

@bramalingam

show just the selected field alone in the column data for the fields?

Not sure this is viable as it adds yet another permutation to the displays - risk of user confusion is increased.

Note:

I think that in the spatial view in centre pane - zoom should zoom whole pane - grid and all, not just fields as currently done.

@dsudar
Copy link

dsudar commented Aug 20, 2016

Sorry for coming late into this discussion. Probably means I'm missing lots of earlier considerations.

  • these mockups are all in Insight, correct to assume that the Web version will look the same? I.e. will Web also get a "red grid" or "bird's eye" in LHP? One small issue: mockups for red grid show a round well; what if square-well plates or rectangular-well plates are used? I don't think that shape and size of wells is even recordable in OME-XML data model, is it? To avoid all that maybe better not to show an implied well border at all.
  • spatial view in centre pane (and in LHP red grid) is indeed very useful but assumes that the fields have usable coordinates. What would the default behaviour be if coordinates are missing (e.g. the plate was assembled from a dataset of images with a new Dataset_to_Plate script that generates multi-field wells) or if coordinates don't make sense. And how would you detect the latter?
  • non-spatial view (grid view?) will simply show the images in a regular grid, right? By default how many per row? One thought: can a reasonable guess be deduced from the spatial information (even when not displaying in spatial view)? And when a user selects a preferred "No. in Row", any thought how to make that "sticky" so the user doesn't have to keep setting it back to the preferred amount?
  • I agree with @bramalingam on the preference for the little squares in red grid.

@jburel
Copy link
Member

jburel commented Aug 21, 2016

@dsudar: Thanks for the feedback, very useful. "grid view" is the non-spatial view (display as row/column)
The mockups are done using insight solely for convenience. The change will be applied to Web too

@gusferguson
Copy link
Author

@dsudar - thanks very much for the feedback and comments

assumes that the fields have usable coordinates. What would the default behaviour be if coordinates are missing

Perhaps the best thing to do would be to only activate the spatial view option if the coordinate data were there.
? if this is possible/too much overhead?

One thought: can a reasonable guess be deduced from the spatial information (even when not displaying in spatial view)?

Would the guess not be better based on the width of the centre pane? i.e just wrap them

And when a user selects a preferred "No. in Row", any thought how to make that "sticky" so the user doesn't have to keep setting it back to the preferred amount?

I should think this could be done.

Removing circle in LHP birds-eye spatial view.

wellgridview-multi-well-field-select-spatial-be-rect-grid

@will-moore
Copy link
Member

@chris-allan As I'm starting to implement this in web, it would be good to know what implications these changes would have on Glencoe. E.g. having plate Wells be square & zoomable instead of using the config opt.width & opt.height with default of 64x48. (I'm still using size 96 for the actual thumbnails, so no change there).

@gusferguson
Copy link
Author

gusferguson commented Nov 15, 2016

Suggestion moved to #58

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants