Repositories: Add an extra "layer" to reflect organizational hierarchies

[anarchivist]

For example, Campus -> Unit -> Collections/departments

• IU needs to reflect different campuses, with their own repositories. Each repository has a finding aid "collection."
• Stanford: assess how this impacts branding needs of Hoover and other coordinates

[ggeisler]

Adding design needed label because if we enable implementers to use an additional layer of the organizational hierarchy, we need to figure out how we will display that additional layer in the UI.

[jvine]

It's difficult to suggest a cohesive design here without a better understanding of the possible structures and use cases. What follows are some notes and ideas for further consideration.

How is the additional layer meant to support the user?

• communicate the organizational structure of the repositories? (In what context does the researcher need to know this? Do they need to interact with / filter the structure?)
• support discovery, by allowing the researcher to focus on or disregard materials by broad location (beyond an individual repository).
• facilitate access by clearly exposing the location of the repository.
• ???

Some ideas around grouping/faceting repositories and results

1. Allow the user to group/filter the Repositories list by the "layer" values.

Possibly with a drop-down list

Or a button list, depending on the number of values.

2. If the user filters the repositories list, limit the search to that set of repositories

with the added value dynamically added to the <select>, or with a default placeholder like "this collection". (This may need further analysis in terms of how it interacts with facet values selected later in the search results vs. from the repositories list.)

3. Allow the user to facet search results by the same set of values

Either by adding a separate facet, or expressing the hierarchy in the Repository facet itself.

Expanding the breadcrumbs to expose additional layers

I am concerned adding more content to the front of the collection in the breadcrumb begins to interfere with its usefulness in providing context to the specific component or result. In fact, I'd like to see shorter Repository names overall, excluding the name of the owning institution or other organizational content.

In the search results breadcrumb, adding layers pushed the collection name deep into the block of text. User needs to read a long way in and keep track of the meaning of levels to get to meaningful content.

In the component breadcrumb, additional layers create add levels of indentation in a context where we want to minimize it.

I don't think either of this is a good solution, but the pattern is there. The added layer(s) would be linked to the filtered Repositories page (e.g. showing the repos for the selected campus).

I think it might make more sense to separate the collection context from the access component of the breadcrumb, and express the institution / organization / location separately from the collection and its children.

1. Retain the current repository + collection breadcrumb, and display the additional layer elsewhere - possibly as a label or badge that could have visual consistency on the repository card, in a search result, and on the Access tab of the component page (not shown).

2. Start the current breadcrumb at the collection, and express the organization + repo layers in a separate element. This would require further analysis and some rework in several areas of the application; not attempted here.

---

Nothing here is ready for development, but it might serve as a starting point for discussion and clarification of the goals and use cases. Examples and suggestions are welcome.