ROI: Folders - Mockups - Measuring Tool - Step 3

[gusferguson]

This issue follows on from https://github.com/openmicroscopy/design/issues/9 and contains mockups and comments relating to UI functionality that will be implemented as third or subsequent steps.

ROI Folders managed via right-click menu

Two choices:

• Add to Folder...
  • if folder selected - allows nesting of folders
  • if ROI - to one or more folders
  • uses modified tag dialog
• Rename Folder...

Add to Folder...

Gives dialog:

Rename Folder...

Gives simple rename dialog:

In response to Comments:

Adding "breadcrumbs" to show any folder hierarchy to the inspector pane should not be much of an issue:

Showing hierarchy in other views much more problematic. If decision is to go for just one level in measurement tool for first step then suggest tooltip to show any hierarchy as that would show they exist but not be much of an implementation overhead. - e.g.:

Comments carried over from Step 1 https://github.com/openmicroscopy/design/issues/9

Josh:

If we are focusing on a single level of hierarchy here (**) Inspector Tab for ROIs is likely the place it'd be best to have some notion of the full hierarchy in the early days (breadcrumb style?).

Rename Folder... might be a second location since it's effectively a "move". Add to Folder... is another.

(**) my understanding of how the implementation of this first mockup (#9) would work is that someone will choose some hierarchy context in the full viewer and then click on the measurement tool to say, "show me the ROIs" at this level.

Gus:

Rename Folder... might be a second location since it's effectively a "move". Add to Folder... is another.

Rename should not be a move - literally rename - e.g. if there was a spelling error or you wanted to broaden the name from "oval cells" to "irregular cells" etc.

Moving ROIs/folders from one folder to another is a totally different UI concept, and is covered in these interactions by removing them from one folder and adding them to another. Less than elegant albeit.

I would greatly favour a proper ROI and folder management UI element - but I have been banging on about one for tags and tag sets for ages and no-one else likes the idea.

Josh:

Rename should not be a move - literally rename - e.g. if there was a spelling error or you wanted to broaden the name from "oval cells" to "irregular cells" etc.

Agreed if it's ok to have a second location, but even for the rename, having the parent context could well be useful (for example if you're trying to find a typo from a new ontology version).

I would greatly favour a proper ROI and folder management UI element

I'm intrigued. Is there anything I can read on the tags/sets version for later discussions?

Gus:

I'm intrigued. Is there anything I can read on the tags/sets version for later discussions?

No it never got as far as a mockup unfortunately.

The mockups here do not allow for creation of nested folders either - so if we extend to cover hierarchies then we need to add that in (somehow :-/).

Petr:

Maybe a trifle, but could the context menu when applied on ROI folders not have the Duplicate, Propagate items which I suppose come from the present context menu on ROIs and cannto be transferred to the ROI folder functionalities ? Also, will we allow the other actions in the context menu, like Merge for ROI folders ? If not, this would be nice not to have there.

@sbesson : Synthetic images in what sense ? Fake images ? It would be the best to have the most demonstrative images which would show the features and usefulnesses imho...

Michael suggested the mitotic image from Jason's homepage as a good example, as well as images curated/deltavision/michael/mtools/HeLa.dv are good candidates for his case.

Sébastien:

A couple of points raised as part of yesterday's meeting:

• in a case where hybrid ROIs (i.e. ROIs organized into folders + "orphaned" ROIs), there would be no artificial "Orphaned ROIs" folder but ROIs would be listed at the bottom of the list (like datasets not in projects)
• what should be the expected viewer behavior when selecting a folder?

Gus:

Also:

• ROI Folders should expand to show ROIs when ROI selected in Full Viewer.

[will-moore]

It seems that we are basically trying to do what Photoshop does, so it may be useful to see how they handle multiple levels of Folders (they call them "Groups"). They have a very simple "New Group" button, then all the renaming and grouping happens in the tree itself by drag-and-drop etc.

[will-moore]

To make the "create folder" functionality more prominent, a "Folder" button could be added to the toolbar. I don't know how hard it is to do drag-and-drop, but I imagine that's what users will want for organising the folder hierarchy.

[gusferguson]

Comment from @pwalczysko

When selecting a ROI which is included in 2 folders, this is being selected twice in the ROI Manager. As a result, such ROI cannot be propagated, because the UI will answer can propagate just one ROI at a time.

This will need to be addressed.

Gus: This may best be addressed at the same time as the Insight model change needed for the above point.

[gusferguson]

Comment from @pwalczysko

Another comment for follow-up work: Visibility of ROIs which are contained in more than one folder:

• have 2 ROIs in a folder (r0 and r1 in f1)
• have 2 ROIs in another folder (r0 and r2 in f2)
• this means that ROI r0 is contained in both folders
• ROIs r1 and r2 are specific (for folders f1 and f2 respectively)
• start with all ROIs and folders visible (f1, f2 as well as r0, r1 and r2 are all ticked visible)
• now deselect folder f1 -> observe that the r0 region became invisible, although it is still contained in the other folder f2, which is still visible
• my suggestion would be: if the ROI is contained in some other, visible folder, then leave it visible, even as the folder f1 (which contains the ROI as well) is invisible

[gusferguson]

Comment from @dominikl

That's because in the current implementation the "Visible" status of the ROI folder is determined by the Visible status of its ROIs, and the change of the Visible status of the ROI folder is propagated to all its ROIs.

But as discussed with @pwalczysko , it has to be the other way round. The Visible status of the ROI has to take the Visible status of all it's parent Folders into account.

Yes, I'd suggest to tackle this in the next follow up PR.

[pwalczysko]

There are some existing actions on ROIs like Propagate - do you want to include them here or will that be integrated in later stages ?

[gusferguson]

@pwalczysko - not at this stage - all existing functionality will remain as is.

[dominikl]

Looks good. Yes, I'll try to add drag&drop support asap, that'd be the most intuitive way to move Rois and Roi folders around. The question then just is, what a d&d action actually means, cut/paste or copy?

[gusferguson]

@dominikl - thanks. Yes there will be plenty of semantic issues to try and iron out.

[jburel]

for D&D, we will need to keep the same behaviour that the one we have in the tree for dataset/image for example (when it works ;-)) Major point is to keep both in synch. If we change the behaviour, some extra work will be required for PDI

[dominikl]

Just thinking about the "Add to Folder" and "Remove from Folder" action. What about a combined action "Add/Remove", which pops up a Dialog with a list of checkboxes where you can check/uncheck the folders the ROI is part of?

[gusferguson]

@dominikl - sounds good - working on mockups now - will do one of that.

[dominikl]

I'll go for the separate action for now. My previous suggestion won't work with multi-selection of Rois in different folders.

[gusferguson]

Looking at this at the moment:

[gusferguson]

Possible warning dialogs - not sure if they are really necessary, but probably safer.

Removing ROIs from a folder (orphaning)

Deleting a Folder

• ignore differences in right-click menu with above mockups - focus on dialogs
• confirmatory dialog necessary for non-revresable delete action

[will-moore]

@gusferguson Looking at all the options in https://github.com/openmicroscopy/design/issues/11#issuecomment-179852505 Is this the sum total of functionality (right-click menus, toolbar buttons etc). I can see many of the same issue's we've had with the P/D/I tree "Aaaaahhh!!". E.g. if I select a ROI or Folder, then I click "New Folder" button on toolbar, does the selected ROI or Folder get placed in the new folder? Is the behaviour different for right-click menu vv toolbar button? Does "Orphan Folder" mean "make this folder into an Orphan"? Is that the same as "Remove" (cut)?

[gusferguson]

@will-moore - thanks - you are right this is very tangled up - I will see what I can sort out.

[gusferguson]

Issues arising from #4458 testing - open question is the conceptual issue of visibility of high level folders #4458 (comment) https://github.com/openmicroscopy/openmicroscopy/pull/4458#issuecomment-181814076.

Gus: Note the following:

uncheck Visible for Folder: elliptical [2] - uncheck Folder: right [2] - ROI ID 375 is not displayed (screenshot 1) check visible for Folder: right [2] - ROI ID 375 becomes visible and Visible is checked for ROIs and Folder: right [2] but remains unchecked for Folder: elliptical 2 This is actually correct behaviour as there could be other ROIs in that folder that you want to remain visible - it just looks a little odd when there are no other invisible ROIs in folder. So no action needed.

Petr: Re: Visibility when Folder checked or unchecked - fully agree with the lowest-level folder visibility test and anyalysis by @gusferguson . What about the higher and highest folder level though ? Atm there is no action at all if you uncheck the visibility of e.g. Folder: by (id 245). All inside this folder will remain visible. I do not mean now that I have a ready solution for this one, but shouldn't we think of this ? (also, can a higher level folder contain ROIs as well as folders ? How do we adjust the behaviour then ?)

Need to deal with this.

[dominikl]

With respect to the visibility flag on folders there are only two options. Either the visibility of an ROI is determined by its folders visibility (this means all ROIs can be visible although the folder is not set to visible, if the ROIs are also part of other, visible folders), or the visibility of an ROI folder is propagated to its ROIs (that means ROIs can be set to not visible across folders, although other folders containing the ROI are set to visible). What does the user expect, the bottom-up or the top-down approach? We can't mix them up.

[dominikl]

That was a misunderstanding of mine, sorry... discussed with @pwalczysko . The question is, what should happen with subfolders if their parent folder is set to visible (or not visible). I'd suggest that this change should get propagated to the subfolders.

[pwalczysko]

@dominikl : @gusferguson : Thanks for clarifying this. We also discussed the case content of the folder are subfolders as well as ROIs. We agreed that this case (which is apparently not allowed in the present Insight model, but it is allowed in the OMERO model) is far too tricky and we would not allow it and would not solve it in very near future.

[will-moore]

Just tried playing with this in Photoshop. Although they don't allow an ROI/layer to be in more than one folder, you can toggle the visibility of individual ROIs and folders. An ROI is only shown IF the ROI itself is visible AND all it's parent folders are visible. If I turn ON the visibility of an ROI, this automatically makes all it's parents visible too (so it is actually displayed).

In our case, if an ROI is in multiple folders and any one of them is visible then the ROI can be visible too.

[will-moore]

You can see from the screenshot that each ROI or folder can have 3 states:

• Not visible (no eye icon)
• Visible but not displayed because parent is not visible (grey eye)
• Visible (black eye - ouch!)

[gusferguson]

Because of the number of mockups this issue is becoming very cumbersome. Have opened two additional issues for new mockups.

ROI: Folders - Mockups - Measuring Tool - Step 4 - Part 1 - Folder and ROI interactions Issue: https://github.com/openmicroscopy/design/issues/14

ROI: Folders - Mockups - Measuring Tool - Step 4 - Part 2 - Folder and ROI interactions - Part 2 Issue: https://github.com/openmicroscopy/design/issues/15

Once it is decided what will be done in step 3 these will all be tidied up and rationalised.

[mtbc]

I can imagine it's okay not to show the whole hierarchy in all views so long as there is some selection synchronization between those views and the full folder tree wherever it is shown.

[dominikl]

Just to sum up what I'm going to do next:

• Fix the visibility issue, i. e. change of folder's visibility will be propagated down to its subfolders (not ROIs!)
• Add basic add/remove ROIs to/from folder action (right click popup menu on selected ROIs)
• Add basic create, edit (i. e. change name/description) and delete folder action

This will go into PR https://github.com/openmicroscopy/openmicroscopy/pull/4471

After that I'll try to add drag and drop support for managing the hierarchies and moving ROIs around. To keep the steps in a manageable size, I'd suggest a separate step/PR for that. The more complex dialogs of step which is now called 3.1 will come later.

[dominikl]

I'm currently trying to implement the "Create new Folder" action (which should be available in the popup/context menu), with the intention, that if you triggered the context menu by right clicking on a folder, the newly created folder will be a subfolder of this folder. For that use case actually all available folders should be listed in the table. Currently only folders which contain ROIs (or their parent folders) will be displayed. Would it make sense to add a checkbox, e. g. next to "Show comment" checkbox, for toggling between "show all folders" and "show only roi folders"?

[dominikl]

As discussed with @pwalczysko , I'll implement for now the "show all folders" concept, otherwise empty folders, e.g. newly created folders, won't show up and therefore you can't do anything with them. We just have to be aware of that, when in future folders are used for different purposes other than ROIs.

[will-moore]

I don't think that most users would understand why you'd want to "Show all folders". This may be a large list and completely swamp the UI. I think that you'd want to have an "Add Folder" button that allows you to choose a new or existing folder (by browsing folder hierarchy) and then that folder would show up in the Manager, allowing you to drag and drop (or right-click > Move) ROIs into it. The only gotcha is if the user never added an ROI to this folder, then it wouldn't be shown in the Manager for that image next time, but I think that's OK. This is kinda like "Show selected folder" rather than "Show all folders".

[pwalczysko]

@will-moore : Why to imagine that the list would be that large ? Do we somehow prevent the user from seeing all Datasets and Projects ? In your suggestion, there would be a workflow: Create a new folder -> immediately loose it from sight and usage (because no ROIs are in it) -> be forced to use Add Folder button -> after addition of the newly created folder you can start working with it.... Not very nice.

[dominikl]

I agree with @pwalczysko , we need to show all roi folders, otherwise it's too confusing. At the moment all folders are roi folders. If they are used in a different context later, we have to be able to somehow specify the purpose of a folder (namespace, etc.).

[mtbc]

There could, e.g., be a folder for every term in the Gene Ontology, a folder for every track for every cell in every multi-t image, etc.; hence my earlier interest in at least being able to type to filter.

[gusferguson]

@dominikl @pwalczysko vs @mtbc - are you guys all talking about in the measurement tool or are you cross-wiring between the "Measurement Tool" and "Add To Folder" windows?

[dominikl]

I meant the table of the measurement tool as well as the "add to folder" dialog; imho the folders displayed should be the same in both cases.

[gusferguson]

Reopened after editing.

[will-moore]

@pwalczysko Every list gets large eventually (as @mtbc suggests). I imagine that adding a folder to the measurement tool would be analogous to adding a Group / User to the P/D/I tree - you can pick the Group & User to add instead of always adding all of them. I wouldn't suggest that you make a user "Create a folder" then "Add" the same folder. Simply by creating it you'd add it to the view.

[pwalczysko]

Simply by creating it you'd add it to the view.

@will-moore : Yes, but I understood that @dominikl says there are some technical difficulties to implement this.

[gusferguson]

For reference: As discussed - mockups of possible Display Folders drop-down and Filter boxes here: ROI: Folders - Mockups - Measuring Tool - Display Folders + Filter Folders #21 Note: Not for this step.

[dominikl]

For my understanding, what is still left to do for this step:

• Show folder path in Inspector tab
• Show folder path as tool tip? This step still assumes flat hierarchy, now we have the full hierarchy displayed. Does it still make sense to show the full path as tooltip? I don't think so. I'd prefer to not use any tooltip in the ROI table, as it doesn't work properly anyway.
• Warning dialog for orphaning ROIs. Is this really necessary? In the dialog as well as DnD (DnD to empty space), the user deliberatly chooses to orphan the ROIs, so why an additional warning?
• Warning dialog for deleting folders. What should happen there? Delete folder, keep contents (Make subfolders toplevel folders? Orphan ROIs?), delete contents, let user choose (either delete or keep, or even specifically which contents to delete and which to keep (ROIs and/or folders)?

[sbesson]

Assuming this was all covered by OMERO 5.3.0-m2, closing this issue.