For an archive like ours, where there are multiple similar names/titles in different hierarchies, this would avoid the need for the archivist/users to have to click into the data to see which items are the relevant ones.
It would be nice if this was configurable. The user could choose from a set of properties that would apply to staff interface search results:
Level of description
Component unique identifier
Relationship to parent record group/series/subseries
I'm not sure whether the PUI already does this.
Fix lumped in with
Though I agree that identifying which Archival Object record for titles like "Correspondence" is extremely challenging, I think with the addition of the Identifier column this request for a hierarchy display/column is less relevant/necessary.
My issue (alright, it's really a complaint) is that the new result context column as currently implemented is only relevant for Archival Objects, i.e. everything else has "Top level record". This will be very confusing for all other record types and add unnecessary clutter. For example on my screen the Resource type column is now smooshed so that the word Resource is now on two lines.
Remove the column BUT have the identifier show in the Identifier column. (Currently this column is blank)
When doing an unfiltered search the result list does not contain this column HOWEVER when the user filters to Archival Object, the result context window is added to the result display (I think the identifier should move to the Identifier column but leaving it in would be fine)
If you have to keep this column, put the identifier in the Identifier column and just have the series titles in the result context window (Though I'd really prefer this column went away in favor of one of the two suggestions above)
One more suggestion: Could the "Context" breadcrumb path be presented just below the 'Title' (i.e. in the same cell)? That is, similar to the presentation of the linked resources and accessions in the Assessment browse screen? http://test.archivesspace.org/staff/assessments
In terms of labels, re-using "Found in" rather than "Result context" might help bridge the staff and public sides of the site.
We're going to include this in the 2.4.0 release, and create another ticket for further enhancements.