Feature #5171

Improve level of detail included in the AtoM search result stubs

Added by Dan Gillean almost 9 years ago. Updated over 6 years ago.

Status:NewStart date:06/03/2013
Priority:HighDue date:
Assignee:-% Done:

100%

Category:-Estimated time:3.00 hours
Target version:-
Sponsored:No Tested version:2.0.0, 2.0.1, 2.1

Description

To enhance browsing and search result page usability, details about the record should be included in the results, as was the case with search results in 1.x

To include, at minimum:
  • Reference code
  • Date(s)
  • Creator(s)
  • Institution/Repository

See attached screenshot from 1.x as a guide.

SearchBrowseResults.png - Search results from 1.x, showing details included for added context and usability. (9.86 KB) Dan Gillean, 06/03/2013 12:55 PM


Related issues

Related to Access to Memory (AtoM) - Feature #5165: Replace table with horizontal search results in actor/browse Verified 06/02/2013
Related to Access to Memory (AtoM) - Bug #5863: reference code displaying inconsistently in brief view (a... Verified 10/23/2013
Related to Access to Memory (AtoM) - Feature #7651: Include "Part of" information with hyperlink to top-level... Verified 12/03/2014

History

#1 Updated by Jesús García Crespo almost 9 years ago

  • Status changed from New to QA/Review
  • % Done changed from 0 to 100

Applied in changeset atom|commit:1e98f34f3a4be6829d104f4be37efc4ad23ee1f6.

#2 Updated by Dan Gillean almost 9 years ago

  • Status changed from QA/Review to Feedback

Results do not include creator names some instances where they are present in the record (To reproduce: search for "Navy" and look at "Royal Canadian Navy Estimates and Construction Projects") or alternately, dates of creation (look at most other results on the page when searching for "Navy"). Part of this is due to an ISAD import template bug, which separates the name of the creator and the date into 2 different fields - and it is clear that for these results, only the first entry is being grabbed, so if the name and the date are split, one gets dropped.

I wonder if we can pull the name from where it appears under the Archival description area (Name of creator), to try to avoid this issue until the ISAD template import behaviour is addressed?

Otherwise: name of repository is not present. In a large, multi-repository environment such as this, i think that this kind of detail is important. Especially considering that not all institutions are available in the Institution sort facet; only the top 10 or so.

I would also argue that for end users, who may be unfamiliar with archival terminology and access interfaces, having at least some of the labels present would probably help a lot, as found in 1.3 (see PNG image originally attached to issue).

I have attached a proposed layout for managing results, that aims to strike a middle ground between the current implementation (following Ralf's wireframes), and the 1.3 implementation:

NOTES on this proposal:

  1. Level of description is more important information to an end user than the reference code. Consequently, I have switched the colors, and bolded the level of description
  2. Repository has been included just below, with a line separating it from the scope and content excerpt. This is taken from the 1.3 results, and I think helps orient the eye. Also, if in the future we ever implement some JavaScript that allows the details to be hidden/revealed (either by the Admin, or directly in-page by the end user - see [[http://search.canadiana.ca/search?q=banjo&field=&df=&dt= Canadiana]] for an example) this would give us a clean layout line on which to show/hide results when a user hits a button
  3. Dates include (context of date), as in the 1.4 version. multiple dates can be included separated by a semicolon, and if too many are present, the results would truncate after 1 line
  4. Creators are included in bullet point and hyperlink format, exactly as in 1.3 - this can be a useful way for a user to move through the collection. Also displaying all creators in the results is better than making arbitrary decisions to select only the first entered
  5. labels have been included for the creators and dates for visual clarity and context - the level, repository, and reference code information does not include labels, as I think their role can be more readily discerned at a glance

This is just one proposal, and if necessary, it can get bumped to 2.0 for consideration and further review. Ideally though, repository information can be included, and a workaround could be found for what happens when names and dates have been separated on import.

#3 Updated by Jesús García Crespo almost 9 years ago

  • Target version changed from Release 2.0 - interim 1 to Release 2.0.0

#4 Updated by Jesús García Crespo almost 9 years ago

  • Estimated time set to 3.00

#5 Updated by Jesús García Crespo over 8 years ago

  • Target version changed from Release 2.0.0 to Release 2.1.0

#6 Updated by Creighton Barrett over 8 years ago

Just going through some of the issues to see what's going on. Given that the 2.x browse results now show all information objects (rather than top-level records), it would also be useful to have a "Part of" note for lower levels of description. In browsing archival descriptions in 2.0, I've found that some records are hard to discern, especially those with basic titles and no scope notes. Bread crumb links like those that appear in the object view (nice touch btw!) or a simple link to the top-level description would help clarify the results.

#7 Updated by Dan Gillean over 8 years ago

  • Status changed from Feedback to New

Agreed, part of would be very useful. Thanks for the feedback, Creighton!

Changing this issue to "New" so we address it for next major release.

#8 Updated by Dan Gillean almost 8 years ago

  • Priority changed from Medium to High

#9 Updated by Dan Gillean almost 8 years ago

  • Target version deleted (Release 2.1.0)
  • Tested version 2.0.0, 2.0.1, 2.1 added

#10 Updated by Dan Gillean over 7 years ago

  • Related to Feature #7651: Include "Part of" information with hyperlink to top-level parent description in search and browse results added

#11 Updated by David Juhasz over 6 years ago

  • Tracker changed from Bug to Feature

I'm changing this from a bug to a feature request. The amount of data and layout of the search results doesn't materially affect the functioning of the software, and is subject to personal preference.

#12 Updated by Dan Gillean over 6 years ago

  • Project changed from Access to Memory (AtoM) to AtoM Wishlist
  • Subject changed from Search and Browse results for Archival descriptions should include details to Improve level of detail included in the AtoM search result stubs
  • Category deleted (Search / Browse)
  • Assignee deleted (Jesús García Crespo)

In that case, re-titling, and moving to the AtoM Wishlist

Also available in: Atom PDF