Confusion when a child work (or any filesets) is not public in a public work

[hackartisan]

Broadening this to apply to "non-public" things in general on a public work: Child works as well as ordinary fileset images; when they are the 'representative' image or just an ordinary member (this one is the hardest); on both show page and viewer.

Probable solution: Either they need to not show up at all (for a non-logged in user who can not actually see them), or they need a more legible placeholder.

The thumbnail appears in the list as a default image, with 'chf' in the top corner. Pretty confusing for a user. Maybe a different thumbnail? and/or a different message

[jrochkind]

and/or consider it maybe not showing up at all to those who don't have access to see it. Although sounds like there were reasons that wouldn't work, worth putting in as another possible option in the ticket I think.

[jrochkind]

@MDiMeo @catlu @archivistsarah

If a not logged in user is viewing a show page, should non-public members just not show up at all? That makes sense to me, I think?

[archivistsarah]

yeah, that makes the most sense to me. unless there's an alternative I'm missing?

[jrochkind]

I guess the alternative I can think of would be showing placeholders for those images like currently, but having a better UI for when you try to actually look at them, saying "no, you can't look at this cause it's not public" or something. I think not showing them at all is probably sensible.

[jrochkind]

@hackmastera actually, can you clarify what you were pointing to here? Can you find or make an example on staging? Actually looking at current behavior, i start to get confused.

Is it specifically when a non-public fileset is listed as 'representative' on an otherwise public work, when viewed by a not logged in user?

[jrochkind]

Sorry, I started talking about a different case above, then realized there were at least a couple different cases going on here.

[hackartisan]

@jrochkind I created this during a team meeting. I think we were discussing the fact that there was a default thumbnail with the 'chf' flag, and there was nothing about that display that indicated the file was not actually viewable to the general user. If I recall, people in the room weren't sure about removing them altogether, because they worried users would notice / ask for the missing page. I think someone suggested some text like "coming soon" or "in process"? assuming it's still in cataloging. Could be a shaded box with brief text and no default thumbnail.

[jrochkind]

OK, I guess I'll wait for more discussion before working on this further.

Lots of things can be done, with varying levels of how long it will take to do, and varying levels of fighting with the stack.

It's not clear to me what should be done. I'd like to hear what the use cases are for a public work with non-public members.

[archivistsarah]

We have a work where the public files are cropped and rotated to mimic reading order & orientation. The original, full-page shot (in which some text is upside-down) are part of the work, but private: https://digital.chemheritage.org/concern/generic_works/6395w716v

decided to do that before we had a viewer that could rotate images, though, so we likely won't do it again.

[archivistsarah]

also I could see Oral Histories wanting the ability to ingest but not provide open access to everything

[jrochkind]

Thanks. For those cases, it does seem better to me to not show the non-logged-in-user that the private image exists at all, there doesn't seem to be any utility to telling them "There's an image here but we can't show it to you"

[hackartisan]

and there's an option in not-cataloged-yet use case to keep the parent work private until it's entirely ready

[MDiMeo]

Of all the use cases, the one I find most convincing is the workflow issue whereby she is waiting for a single image to be reshot or to have metadata created by another curator. Let's revisit this with @catlu at Monday's meeting and make a decision then.

[MDiMeo]

At today's meeting we decided to hide private files from the public instead of telling them that there is a private work that exists within that public work that they can't see. This is because most of our use cases had to do with workflow or legacy issues and not the collections data itself. We felt that the message could be confusing to the end user, and there is no blanket statement that we can issue since the missing objects exist for a variety of reasons. @catlu will deal with workflow related issues. Those works will be just be hidden until they are ready.

Hypothetically, we could potentially have an archival child work that we want digitized for digital preservation but cannot put online due to rights restrictions. In this case, we might want the user to know the item has been digitized so that they can request it. If this use case comes up in the future, we agree to deal with it then and possibly revise our current decision. But for now, based on the data available, we will hide them until they're ready for publication.