Tabular view of components

[anarchivist]

Acceptance criteria

Presuming a component has children with no further children below them(?):

• Display a table with rows for each component
• Columns should include:
  • Container information (Display container information for a given component (when available) #20), with labels from the type attribute (note: container information may be broken out into multiple <container/> elements)
  • Title and date as one line, with a link to the component show view
  • Date as separate column
  • Bookmark links/buttons/checkboxes
• By default, the components should display in the order they appear in the finding aid

Out of scope

• Sorting the components list Sort tabular view of components #292
• Displaying thumbnails for digital objects

Mockup

[gordonleacock]

ggeisler [6:45 PM]
@gordonl @anarchivist: Yes, in these contexts:

1. Collection inventory
2. Potentially a component detail page, if the component being examined is a container or item in a container (example: p. 10 of mockups). If however, you are looking at the component detail page for a higher-level component, such as a sub-series or series, then I don’t think the tabular view is relevant because aren’t showing children of the component in focus in the context section..

[mejackreed]

The tabular view has a few issues here in my opinion:

• We can't reliably know if all children are terminal nodes without looking at all child nodes (performance / practicality issue)
• Its my understanding that all terminal child nodes may not have container information

The first issue is likely the biggest problem. My solution:

Display in tabular view things that have containers and no children. This would interleave parents and terminal nodes and not allow for the ability to sort the table. Hopefully CTRL+F can be a replacement?

[anarchivist]

As I noted on the call today, I'm not confident that the strategy expected in the acceptance criteria necessarily the best way to determine whether to switch to the tabular view. I'd be happy to join another conversation about this.

[ggeisler]

@anarchivist: @jvine and I discussed this at length earlier today, looking at inventory hierarchy of several collections in detail. Our conclusion is that there is no way to do a tabular view that we think would have utility and a good UX given the current inventory structure.

We discussed some styling improvements we can make to the inventory hierarchy to make it easier to scan and address known issues, like making the fact that component titles are links more clear. I can work on that in the near-term.

Longer-term we think it would be useful to have a discussion with you about the hierarchy and determine whether it would be worth investing more effort in a future work cycle to figure out a way to parse and/or index the inventory in a way that would support a presentation that is closer to our original mockups. We think it would be (especially since the current hierarchy has accessibility issues: every component has the same heading level so the hierarchical representation is lost to a screen reader), but that obviously needs more discussion.

So our recommendation is to close or icebox this ticket for now, but plan on having a more in-depth conversation about it at some point after the MVP work cycle is completed.

[anarchivist]

Sounds good. Thanks @ggeisler and @jvine!

[seanaery]

Resolving this issue as part of a review of arclight 1.0.x. Component show pages do now have a tabular display of child components with title, container, online indicator, and bookmark. It doesn't 100% match the mockups in this ticket but should be considered close enough.