Numbers of folders vs ROI numbers

[pwalczysko]

During testing of https://github.com/openmicroscopy/openmicroscopy/pull/4497#issuecomment-194844671. The numbers in brackets behind the Folder names in Measurement Tool show at the moment just the number of ROIs contained inside this folder (or its subfolders).

• this is not expected from the point of view of common Fileviewers, as well as the tree in OMERO clients, which always show the number of enclosed folders
• on the other hand, we need to indicate to the user clearly which folders contain ROIs and which not

[pwalczysko]

cc @gusferguson @sbesson @dominikl @mtbc

[dominikl]

What do you think about a different folder icon for folders (respectively for "branches") which contain ROIs (the concrete number of ROIs actually might not be of interest anyway)?

[mtbc]

I don't know the best approach here but I'm happy to provide Java gateway methods to get the counts (or any/none) you need conveniently.

[pwalczysko]

different folder icon for folders (respectively for "branches") which contain ROIs (the concrete number of ROIs actually might not be of interest anyway)?

I think this is a good idea.

[joshmoore]

This may be slightly beyond the ROI dialog's needs but see e.g. tagexport.py in which multiple counts are of importance. As we move toward folders containing more each of count of subfolders, count of ROIs, count of annotations, etc. will become important.

[gusferguson]

I am concerned that:

1. a different type of folder icon for "leaf containing" folders will be very confusing. I know of no other UI tree where this is done, so we have no mental model of it in our users.
2. having folder and ROI counts next to a folder implies that there are that many folders and ROIs at the next level - and you end up having to open the folders down the tree to find where the ROIs are anyway.

I would advocate very strongly that we are better just sticking to child count, no matter what the children are.

[pwalczysko]

@gusferguson Re https://github.com/openmicroscopy/design/issues/25#issuecomment-196362061 - I see logic in that -> but then we need some sort of filtering for folders containing ROIs. I think users will be desperate to get this info.

[gusferguson]

Let us not forget that when using the MT to work with ROIs and ROI folders the user will know about the structure of the tree and where the ROIs will be. Our structure is artificially obtuse and difficult to understand. E.g. an ontology has it's own logic and if it is a user-created hierarchy it is unlikely to contain duplications and so on.

I think we should bear in mind that we are still at first steps and not pretending to try and meet all use cases and requirements. If in doubt we should just keep it simple and only cater for simple use cases.

[pwalczysko]

I was rather thinking about our known experience with ROIs on images. Does this image have ROIs ? (and the resulting ROI count line in the right-hand pane). The users did the ROIs themselves, but still, they forgot where they were....

[gusferguson]

I don't think we should get hung up on this now.

[pwalczysko]

Okay

[will-moore]

I think that we should strive not to show empty ROI folders in this main measurement tool dialog at-all. That would be the simplest solution to this issue. I still don't see the need to show all ROI folders at once. In many cases this number will be so large as to cause lots of usability problems (scrolling, searching etc).

[sbesson]

After discussion, we are currently sticking to displaying the total count of children as implemented in https://github.com/openmicroscopy/openmicroscopy/pull/4524.