Revamp collection modal

[ggeisler]

This addresses the problem in #3235 but I'm creating a new ticket because it is also makes a more general proposal to significantly revamp the collection modal. (@robcast this includes your suggestion for list filtering)

This is an overview of the proposal. As discussed with @mejackreed I will, as necessary, add details to individual tickets for different parts of the proposal when I'm able to, but in case the team has the opportunity to get started on this in the meantime, I wanted to convey the general idea.

Related tickets:

• #3273 - Considerations for the collection modal when in the elastic workspace
• #3274 - Responsive adjustments to the modal when in the xs viewport/window width

Support initializing Mirador with collection-only manifests

To address the problem noted in #3235, the proposal is to support collection-only manifests by creating a variation of our standard object window, which I'll call a placeholder window. If Mirador is initialized with a manifest that only specifies a collection, we load a placeholder window and display the collection modal above it, as shown below. The placeholder window omits all the usual window affordances except for the title (from the collection manifest), the fullscreen icon (in case the user needs more real estate to work with the modal), and the close window button (in case the user doesn't care about this collection).

---

Notes on aspects of the revamped modal arrangement and content:

• Modal header identifies the current level of the collection navigation
• Left sidebar should follow the pattern of the window sidebar (same about and index icons, width, etc.)
• Collection contents shows the count of whatever is in the manifest list; n collections or n items or both as in the mockup above. (Use "items" instead of "manifests" as we do in the current modal.)
• The filter input is for narrowing the list, similar to the feature in the Mirador 2 catalog. We might only display this if there are a minimum number of items in the list, such as 10.
• The Collections and Items checkboxes filter the list based on manifest type. They only need to be displayed if the list includes both types of manifests. Otherwise, omit both checkboxes.
• Thumbnails are 44x44 px placeholders. Whenever we can get thumbnails from the manifest (https://iiif.io/api/presentation/3.0/#51-collection) or from previously loaded manifests, they should be displayed proportionally, with 44px on the long side.

About view

The mockup above displays the index view, which should be the default view. There is also the about view, which displays the collection metadata:

---

As discussed with @mejackreed, the "Related" section isn't part of the manifest, but we want to make sure the user can access the collection manifest if it isn't part of the metadata. So the "Related" section is appended to the collection metadata to show a link to the current collection manifest.

Second-level collection example

In the mockup below, the user has selected the second item in the list shown in the first mockup. This is a collection, not an object, so the modal is refreshed to show the title, about metadata, and index for the second-level collection. Because the user can also navigate back up one level, we show a link to the parent collection. Otherwise the list is the same as in the first mockup (this mockup doesn't show the filter input, but since there are 38 items in the list, we should show it. But we wouldn't display the collections and items checkboxes in this modal, because the list contains only one type of manifest.)

Navigating to an object

Assume the user selected the third item from the mockup above. This is an object manifest so we close the modal and load the object as usual:

---

If the user selected the "Show collection" button in the window sidebar, we redisplay the modal, which is the same as in the "Second-level collection example" above, except now, because we've loaded the third item's manifest, we have its thumbnail to display. It's also currently active in the window, so we can display the current item indicator, similar to the catalog window:

---

Similarly, if the user uses the modal to navigate back up to the parent collection, because we have an object context (object loaded in the window, rather than a placeholder window), we can show the current item indicator for the collection that contains the current object:

Closing the modal without selecting an object

Because the user can close the modal when no object has yet been loaded into the placeholder window (as in the first mockup above; which we want to allow because that enables the user to close or fullscreen the window), we need to make sure they can relaunch the modal. The placeholder window should thus contain a message No item selected and a Show collection button to trigger the modal:

[robcast]

Thanks, @ggeisler I really like the proposal :-)

Some small corrections:

• in the third paragraph you wrote "If Mirador is initialized with a manifest that only specifies a manifest, we load a placeholder window and display the collection modal above it, as shown below. " Did you mean "... a manifest that only specifies a collection ..."?
• in the list in the fourth paragraph you have the item "Thumbnails are 44x44 px placeholders. When we do have a thumbnail from the manifest, it should be displayed proportionally, with 44px on the long side." I would like to add thumbnails for items in the collection (as in https://iiif.io/api/presentation/3.0/#51-collection), or was this included by "manifest"?

[ggeisler]

@robcast Thanks for reading the details and the corrections. I updated the third section to say what I really meant (exactly what you suggested) and updated the part about thumbnails to basically say that whenever we can get a thumbnail for a collection/item in the current list, we should use it instead of the placeholder.

[regisrob]

I also like the proposal, thanks @ggeisler.

A few questions or observations that came to my mind while reading it:

• as it appears in the mockups, the scrollable part of the modal seems to include everything but the header, which means that if a user scrolls down the list he will not see the filter input nor the checkboxes anymore, and thus cannot know which type of "item" he is going to click (is it an object or a collection?). So maybe the scrollable part should start below the filter input and checkboxes to let the user filter the list even if he is at the bottom (unless we want a label or icon for each item in the list to "self-advertise" its type?)

• what happens if you initialize Mirador with a mix of manifest(s) and collection(s)? Is the placeholder window for the collection listed in the Catalog alongside the manifest items?

• if you navigate to an object from the collection modal (mockup #4) and then close that window (say you are not interested in this object and do not notice the "Show collection" button in the left panel), is the placeholder window for the collection still present in the Catalog? (to let the user reopen the collection window and browse it again)

[ggeisler]

Great questions @regisrob. I'll address your last two here, since they're related, and then your first question in separate comment.

what happens if you initialize Mirador with a mix of manifest(s) and collection(s)? Is the placeholder window for the collection listed in the Catalog alongside the manifest items?

Yes, I think so. The difference from other objects listed in the catalog is just that, when selected, the collection-only window opens as a placeholder window with the modal exposed, rather than a normal window with an image loaded on the canvas.

if you navigate to an object from the collection modal (mockup #4) and then close that window (say you are not interested in this object and do not notice the "Show collection" button in the left panel), is the placeholder window for the collection still present in the Catalog? (to let the user reopen the collection window and browse it again)

Again, yes, I think we want to do this.

Below are some mockups to work through the scenarios and see if you or others have thoughts or suggestions.

Example initialized state

Mirador initialized with two windows, one a manifest, the other a collection with no manifest specified:

Catalog view of this initialized state

The manifest object and the collection object are both represented in the catalog. Both have the blue vertical border at the left to indicate they are open windows:

Modified state: collection window closed

The user has closed the modal in the collection-only placeholder window and then the window itself, without ever loading an object in it. As in the previous view of the catalog, the initialized objects in both windows are still represented, but only the Bodleian object has the blue current window indicator:

Modified state: object selected from collection window

From the same initial state, let's say the user has selected a manifest object from the modal in the collection-only placeholder window, and maintains that object in the window, along with the initialized Bodleian object in the other window, and visits the catalog. Again, the initialized collection and Bodleian objects are represented but we also display the current object in the initialized collection window, since it is the active object in the window:

Modified state: collection window closed after opening an object in it

As in your question, the user has selected a manifest object from the modal, at some point decides it's not of interest, and then closes the window. As in the previous view of the catalog, the initialized objects are both still represented, but only the Bodleian object has the blue current window indicator. In addition, since the user has opened an object in the collection, it is also represented in the catalog (this is consistent with current catalog behavior, though I wonder if we need to think about that more, since a scenario where a user explores many objects within a collection will produce an increasingly long catalog list):

[ggeisler]

@regisrob:

as it appears in the mockups, the scrollable part of the modal seems to include everything but the header, which means that if a user scrolls down the list he will not see the filter input nor the checkboxes anymore, and thus cannot know which type of "item" he is going to click (is it an object or a collection?). So maybe the scrollable part should start below the filter input and checkboxes to let the user filter the list even if he is at the bottom (unless we want a label or icon for each item in the list to "self-advertise" its type?)

Below are mockups that I think represent your two potential options for this problem.

Fixed filter input/checkbox row

Below left is the starting state, on the right is after the user has scrolled down to the bottom of the list.

Pros

• User can always use the filter input or checkboxes to further narrow the list, even after scrolling down in a long list

Cons

• After the user starts scrolling this list, we're reducing the vertical space available for displaying the list. I'm concerned this could be even more dramatic if 1) the list is within a nested collection, meaning we probably also should pin the parent collection info shown in the third and fifth mockups in my original description, and 2) the modal window width is reduced (narrow viewport or a 2-up workspace that makes the window width more narrow) and the checkboxes need to reflow below the filter input.
• The checkboxes are only relevant (and only displayed, if following my original recommendation) when the list is mixed (both object manifests and collection manifests in the list). So when the list is all of one type or the other we'd still reserve space for the filter input (or not include the filter input in the pinned row, I suppose).
• Even with the checkboxes always available and viewing a mixed list, the user would still need to uncheck one or the other to see which items in the list are collections or manifests.
• It seems like a more challenging technical implementation, since the scrollbars need to be handled a bit different than a normal modal with a fixed header and footer.

Showing a collection label

As @regisrob noted, we could stick with the current arrangement and add a label or icon for each item to indicate its type. Here I've done that, but only for the collections, since that matches how we handle this in the catalog:

Pros

• Retains maximum vertical space for the list
• Uses an existing pattern for labeling collections
• Doesn't raise any additional implementation concerns

Cons

• The collection label uses vertical space within the collection title area, which would force longer titles to either be truncated earlier or take more vertical space for multi-line collection items
• Raises the question, Do we display the collection label, even with the con noted above, when the list is all collections? I'd lean towards Yes, for consistency sake, even though strictly speaking the collection label isn't necessary when we've labeled the list as "N collections" (and the user could've forgotten or not noticed that the list was labeled as only collections)

It's probably clear from my pros and cons list that I'm leaning towards the collection label option but I'd welcome other thoughts or options I haven't thought of.

[mejackreed]

@ggeisler One unfortunate problem I foresee here is that our modal as currently implemented in MaterialUI will take the entire browser window by design. See: https://mirador-dev.netlify.app/tests/integration/mirador/embedding.html

I'm not sure if we have much choice about this.

[ggeisler]

@mejackreed Yeah, that is unfortunate. Do you want to say for certain we can't limit a modal to an individual window? Just want to be 100% sure because that limitation might require part of this design to be revised significantly. The redesign of the window contents itself should still be good, but how we handle the situation where a Mirador instance is initialized with a collection-only manifest might not work at all.

We potentially could force the user to deal with the collection-only modal before being able to interact with the workspace at all (including not being able to deal with the other window in a 2-up configuration) but how would we handle an initialized instance with two collection-only manifests configured? We'd have two modals that need to be displayed when the workspace is loaded. I can think about that more, but I guess I'd want you to confirm that doing a window-specific modal is definitely not feasible before I rethink things.

[mejackreed]

Ok, I've double checked and we can restrict the modal to the window so sorry for the false alarm.