Revise displayed search result item attributes

[ggeisler]

In #161 I suggested (in "Option B" of that ticket) that we display several item attributes as part of the search result item display. We sort of implemented this in #178 but not exactly or completely. It's not clear to me from the comments there whether the desired display is technically infeasible or it just wasn't something that could easily be done at that point in the project and so our current display is just a first-draft that could be improved with a little more work.

So this is just to record what I think would be better than we currently have, if and when we have time to improve it.

Current - Parent containers

The attributes we display are:

• Item count of this container item's children
• Label of this item's parent container

Current - Items

The attributes we display are:

• Item identifier
• Label of this item's parent container

In both cases, the first attribute we display is great and we should keep them. However, I don't think the label of the item's parent container is as useful as other item attributes would be. One reason is I doubt it's clear to the user what that label refers to. Perhaps after they select it for a couple of items and analyze what changed they might, but that seems like more work than we should force the user to do (plus right now selecting that attribute value doesn't appear to do anything other than refresh the current view -- see #462).

Desired - Parent containers

Okay as is.

Desired - Items

Below is a revised list of attributes I think would be more helpful to the user in evaluating potential relevance of search result items. It's a bit different from my original suggestion in #161 because now that I see the actual values items have for Document type (now called "Resource type") I'm worried that a few of them are rather long strings and wouldn't fit so well in a compact display of item attributes.

• Identifier - Current implementation is fine
• Date - When an item also has a time portion, I'd leave that out and just display the date
• Extent - Ideally just the pages/duration part of the extent, but if that's really not possible, the 1 item - 67 pages value would be okay (not ideal, though, since that eats up horizontal space with info that adds no value (all item components are "1 item(s)" I believe). Appending "pages" (text and images) or "duration" (audio and moving image) would be useful.
• Media type - Instead of my previous proposal of "Document/Resource type" because there are only four possible values for Media type and the strings are relatively short, and knowing whether something is a "Text" versus a "Moving image" has value.
• Language - comma-separated when there are multiple languages associated with an item

Here's a mockup of what that would look like, using a text and audio item as examples:

---

The linked attributes (all except Identifier and Extent) would result in facet searches for those values, using the Date, Media type, and Language facets.

[thatbudakguy]

one small question on language — is it intended that for items that have e.g. "German, English, French, and Russian" that there is a single link covering all this text, which links to a search with all of those facets active (i.e. only items with all four of those languages)?

[ggeisler]

@thatbudakguy Good question. I think my mockup is deceiving there. I think ideally we'd just link each language individually. That's probably more often useful than wanting to see documents in multiple languages (guessing at that, though, without any user data yet that we can draw on).

So the commas and the "and" wouldn't be linked.