Discuss child work as representative image

[catlu]

I just noticed that when a child work is acting as a representative image on a parent work, the only way to get to the record/metadata is through the image viewer. Is this a problem?

Here's an example: https://digital.chemheritage.org/concern/generic_works/h128nd97r

[jrochkind]

Hm, yeah, that seems non-ideal. I guess I see how that happened, because I eliminated display of the child selected as 'representative' twice, when it used to be displayed twice. And the actual "representative" area does not let you get through, yeah.

Should we fix it?

[jrochkind]

I'm gonna take some developer perogative and move this into something I'll fix soon, if it ends up fairly easy anyway, I think it's too annoying for admins not to be able to access that. @MDiMeo @catlu

[jrochkind]

@catlu I can no longer reproduce this issue. I think maybe my derivatives redo accidentally fixed it, just cause I straightened things up? Can you confirm?

[jrochkind]

The particular example you mention above seems to no longer have a child work acting as a representative image? But I'm not sure if this is still an issue anywhere, or if it's gone?

[jrochkind]

Nevermind, I see now. It gives you access to the fileset, not the intervening child work.

Ugh, this gets crazy, indeed.

[jrochkind]

Okay, this gets convoluted. @catlu

So, let's ignore the 'representative image' at the top for the moment, and just consider the list of 'members', which consists of both direct 'fileset' images, and child works.

For direct fileset images, admins get the admin menu, and everyone gets download links.

For 'child works', you only get an 'info' button taking you to the child work page -- no admin menu, no download links for anyone.

This is basically how it worked in stock sufia, and also how it works in our current app, although we've changed the UI a bit, the features provided in each situation are the same. I don't know if it's ideal, it's just how it worked in sufia, without a lot of customization on our part.

So what about the big 'representative' image? One thing we did to customize is that if the representative member is the first ordered member, it is not repeated in the listing. Because I thought it would look weird and be more stuff on page if needed in some situations -- imagine a work with only one image, that had the big representative image, and then the same thing repeated below as only one image in a 'list' of one. Seems not right. Also seems not quite right if there are like 3 images total, and the first one is repeated in the big 'representative' as well as the list -- although not as weird as the one image case.

But the 'representative' image area, which may be the only place that 'member' shows up, if it's the first -- is not treated quite the same as the others. While ordinarily if a member is a 'child work' it only gets an 'info' button, if the 'representative' is a child work, it ends up displayed as if it were the fileset, falling through the representative fileset of the child work. (Don't forget the child work may have multiple images itself!). This is partially because it's how sufia just ended up working without customization, and partially because it seemed like having the 'download' link for the big representative was actually important.

I'm not quite sure what to do to change it -- thinking through how to deal with 'child works' and all the ways we use them and how to deal with them, and then making it so, gets complex.

One thing that would be fairly easy to change would be making the 'representative' slot be treated just like the member list. If it's a 'child work', you just get an 'info' button, no admin menu, no download links. I'm not sure if that would confuse users, not seeing download links there. Figuring out the UI for this work-contains-works (which can contain other works!) stuff is difficult.

Or we could imagine more complex ways to handle it, that might require more complex coding. But I'm not quite sure what is 'right' even apart from complexity of code.

Any thoughts @catlu or anyone else?

[catlu]

Oof, sorry that this is so messy @jrochkind. I agree that not repeating the listing makes sense, particularly for records with much smaller numbers of files (which are pretty common in our collections).

Would adding an 'info' button to the representative work (or perhaps, even replacing the 'view' button) if the member is a child work fall into complex approaches? I guess it would require the representative image area to recognize whether the member is a child work or a fileset--not sure if that's a possibility at all.

[jrochkind]

It's possible, just requires some coding.

I think it would probably be a UI problem not to have the "view" button for the representative though -- that's how we expect most people to get into the viewer.

If we want to have view button, download button, and info button, I think we run out of space -- at least for end-users. Staff can handle a more cramped display though.

I think we gotta start by figuring out if the current behavior is even right for users or not. Do you think it is? Does the user need a 'download' button and a 'view' button for the fileset, even though it's not really a fileset it's a child work. I think maybe.

Maybe for staff, we just want the 'info' button instead of the admin menu for the ultimate 'fileset' that's there now. That just requires me to add a bunch more branches to my code, rather than trying to re-using the same code that's used in the listing below.

[jrochkind]

If all child works had only one image, they were really just images with extra metadata -- it would be more straightforward. It's having to handle the case where the child work itself has multiple images (and maybe more child works of it's own?), that makes it hard to figure out what it should be, to me. That case is why we have the 'info' button for end-users in the first place, so they can get to those possibly multiple images in the child work, along with the child work metadata etc.

While sufia supports this child work stuff, and we're using it intentionally -- the sufia UI wasn't really quite thought out for it, and it's probably different optimal UI depending on what you want to use this generic 'child work' concept for, and we use it for a couple things just ourselves!

[catlu]

If we replaced the 'admin' menu with the 'info' button for staff, would that be the case only when the representative was a child member? Or also when it was a fileset? I don't have an issue with this, just looking for clarification.

As to whether an end user needs both a 'download' and a 'view' button for the fileset when it's actually a child work--I would say yes definitely for the 'download' button and perhaps not necessarily for the 'view' button. The issue is that the 'view' button was added to the representative specifically to address comments that came up in user testing.

Probably another concern is really just that child works in the representative image area will be confusing to end users regardless. They might click through to info/images, not realize why the description has suddenly changed, and also wonder why the rest of the images are all different even despite the 'part of' parent/child trail.

[jrochkind]

I was thinking replace 'admin' menu with 'info' button only for representative image, only when it's a child work -- so with regard to admin functions, it's the same for 'representative' as it is for other members in the normal listing. Filesets get admin menu, child works get info button.

For non-staff users, it would remain the same, no info button (so no way to get to representative child work for non-staff users, same as now, for better or worse), download and view buttons.

I think we always do need the 'view' button on representative, for users.

I think you are right that a representative as child work is gonna be confusing for end-users no matter what. Really, I think currently child works are probably confusing to end-users no matter what, but extra-confusing when it's a representative.

I don't know if it's realistic to just say "don't use a child work as represnetative." We currently have at least some works that are ALL child works, so it would be impossible to follow that, child works is all you got.

I think this is pointing out some problems with our current display, but I'm not really sure of solutions. Maybe we need to figure out the ideal solution regardless of how much coding work it would take, and then just do the work. That's still not obvious to me, but not worrying about how much code it will take makes it easier to focus maybe.

[catlu]

Those solutions all make sense to me @jrochkind. I agree that an even more ideal display that really features parent-child works intuitively is out there somewhere--but maybe for revisiting later!

[jrochkind]

okay i'll see what i can do.