ROI: folders vs containers

[sbesson]

Our existing blog post mentions the introduction of ROI folders concept. In parallel, scoping work has defined the similar concept as ROI containers. What is the rationale for each naming scheme and should we agree on a unified naming scheme or is it okay to have the same concept codified in different ways?

[gusferguson]

My choice would be "ROI Containers".

[hflynn]

I definitely vote for picking one term and then using it everywhere, the sooner the better. I don't have a preference between the two though and think changing to containers at this stage is fine as long as we do it asap and I can make clear which term we have settled on in the next blog post.

[mtbc]

This was last discussed in https://www.openmicroscopy.org/site/community/minutes/conference-calls/2015/2015-11-10-tuesday-team-meeting -- @ximenesuk raised the point that "containers" is already used more generally in much of the code base. What's the problem with folders? The current view of them fits that concept quite well, I'd have thought.

[mtbc]

@gusferguson: not just "ROI", the decision (at least back then) was that one folder/container can contain multiple kinds of model object. (At least from the point of view of the backend.)

[ximenesuk]

Yes, in OME parlance container is used to as a generic term for Project, Dataset and Screen.

[hflynn]

Actually, containers does give a heap of search results relating to the above, which may confuse the issue. The results for folders seem to be more clearly in the context of uploading and storing data, rather than referring to the Model and the API.

[mtbc]

FAOD: By "current view" I mostly meant the meeting minutes',

Folders are in no more than one other Folder (tree structure)

but of course this is all a draft at present to see how well it works for us.

[manics]

Yes, in OME parlance container is used to as a generic term for Project, Dataset and Screen.

Eventually they could be special instances of Containers:

• Project = Dataset Container
• Dataset = Image Container
• Screen = Plate Container

[ximenesuk]

They could equally and eventually be special instances of Folder which would have the added benefit of not reusing the word container in the period when they are not.

$ git grep Container | wc
    2455   14159  561805

though some of these uses are unrelated such as ImportContainer

[hflynn]

So far I'm seeing two arguments for keeping Folder:

• we already termed them that way in a public facing document
• and more importantly, reusing container is potentially confusing at the moment (altho may be less so in the future)

And the only argument for changing to Container:

• Gus prefers it

Would you like to explain why you prefer Container @gusferguson ?

[gusferguson]

Container is not a term used anywhere in the OMERO UI - it is purely a developer term. Folder is an overloaded term with respect to UIs as it is used in the desktop metaphor for storage of files.

The user mental model of ROIs is shapes - because that is what you draw in the UI. Shapes are not stored in folders in any common metaphor - the only thing that is done with them is they are grouped in graphics apps. If we are introducing a new "item" that allows grouping of ROIs - and later other objects - then it seems better to me to use a term in the UI that is not overloaded for the users. We will certainly not be using folder icons for these groupings so why call them folders?

It all depends on whether you want to do user-centred design - from the user mental model back to the implementation - or just expect that somehow the UI will be able to package the implementation in such a way that it does not violate user mental models.

[joshmoore]

A few first comments from the road:

Container is not a term used anywhere in the OMERO UI

But it tends to be a term that is used naturally for project/dataset, no?

it is purely a developer term

Regardless of which term we choose, looking at how the MapAnnotation work ended-up, I'd very much urge that we include all our users, including developers, since this is also part of a standard used to talke about things.

Shapes are not stored in folders in any common metaphor

The concept of ROIs (even without folders/containers) is going to grow -- masks, meshes, points in tables -- so we should be careful of limiting ourselves to what is currently common. We need structures that will hold up to a longer test of time. If we're moving more to a file-based metaphor (with OME-Files) and ROIs can come from individual files, then the metaphor of a folder may well hold.

We will certainly not be using folder icons for these groupings so why call them folders?

Why not? If we are still having this discussion, could we not also decide to show them as folders.

On additional point from my side, in the container -> folder spectrum, where do links fall?

[manics]

On additional point from my side, in the container -> folder spectrum, where do links fall?

Most people think of objects as only belonging to one folder, that's why Gmail calls them "labels" instead.

[gusferguson]

On additional point from my side, in the container -> folder spectrum, where do links fall?

Links are also a developer construct - users attach tags, files and K-V Pairs, add comments, draw ROIs and make copies of images. The fact that all these are represented by links is by-the-by.

We introduced "link" into some of the menu like "Cut Link" to try and mitigate the confusion surrounding these actions because of the way the implementation did not match the user mental model - not because that is what the users think they are doing.

[joshmoore]

Links are also a developer construct...

Sorry, I might have been unclear. I'm talking about "Image A was produced by processing Image B", i.e. image-image links

[mtbc]

Containers probably bring up so many project/dataset search results because they're part of the public API even for people writing client-side scripts, e.g., http://downloads.openmicroscopy.org/omero/5.2.0/api/slice2html/omero/api/IContainer.html, so we'd have a fair bit of reeducation to do.

Most people think of objects as only belonging to one folder, that's why Gmail calls them "labels" instead.

TBH I run in horror from Google's apparent determination to make their various services increasingly confusing and unusable :smiley: but of course implicit is that files these days typically can be in multiple folders even on Windows: that feature is quite useful for organizing one's files. (Of course when we mount squig we often find the same image in multiple folders in our data repository: those are the same files, not copies.)

Sometimes user mental models should be violated because the gain outweighs the pain -- for instance, maybe someday we'd help them understand what's going on when they do find the same file in multiple folders on their computer (maybe they imported with --transfer=ln) -- so I wouldn't always count the preexisting models as sacrosanct. This may not be one of those cases though, especially if a better word is available.

Is it really any more intuitive that the same object may be in multiple uncontained "containers"? When I think of containers, I'm thinking of Tupperware or whatever, for which the model still doesn't work. If the need is to find a word for folders where it is more obvious to users that multiple folders may contain the same objects, perhaps a third suggestion is needed. Gmail's "labels"? But they're hierarchical ... now I'm back to tags and tagsets! I wonder if there's some real-world object that behaves in a similar way, but I don't think containers are it. Synonyms of groups, perhaps? It's a pity we also already use groups for something else, and in any case they don't suggest the tree-like structure that folders might.

[pwalczysko]

@joshmoore

Sorry, I might have been unclear. I'm talking about "Image A was produced by processing Image B", i.e. image-image links

Still not sure I understand here, do you want to store such links in folders (or containers) ????

[joshmoore]

Still not sure I understand here, do you want to store such links in folders (or containers) ????

There has been some discussion of using the container/folder as a way of "linking", e.g., 2 images.

[gusferguson]

Maybe we should specify all the expected uses of the "folders" clearly - possibly based on a summary of Mark's Trello card description plus any other functionality that may be anticipated.

[will-moore]

Every time a user has contacted us about Projects, Datasets etc, they always refer to them as "folders", and we've used folder-like icons for them in the client trees. I certainly prefer "Folders" over "Containers" from a developer perspective (for all the reasons above), but how are we going to distinguish "folders" from P/D in our clients? Either we need to use different icons for Projects, Datasets & Screens, or we need to think of a different term like Buckets, Collections, Sets, Bunches, Packs, Pools or even Categories! UPDATE: Could use "Labels" too.

[mtbc]

I think there's long-term hope that folders may someday supersede projects, datasets, tags, tagsets, etc., though with what likelihood I don't know.

[joshmoore]

NB: Talking to @sbesson about this earlier, the word "nestedness" got used to describe probably the most critical aspect of what makes up these things we're shooting for (as opposed to other things we have). I found myself saying, "If they aren't nested then they aren't folders, they're just ..." where my instinct was to say "containers". This is probably a large part of where my preference for "folder" (or even "tree" though that's much less user friendly) comes from. I'll upload my doodles to the IDR requirement (gh-7) which are mostly about embracing the concept throughout the project (UIs, XML, and the filesystem).

[gusferguson]

Are doing to bite the bullet and make a definite decision on the name - folders seems to have become the defacto standard - and has been used in the blog - so should I go ahead and change all the issue titles to "folders"?

[sbesson]

Certainly no objection from me. As we also linked this repository from the blog post (which got promoted via the mailing lists), having a unified semantics for the new model concept might also help people who want to follow our progress.

[pwalczysko]

No objection from me.

[gusferguson]

Done mine @joshmoore will have to do #10

[sbesson]

Thanks all. Closing this issue.