Page tree
Skip to end of metadata
Go to start of metadata
Title (Goal)DSpace should allow end users to search for items
Primary ActorEnd user
Scope
Level
Story (A paragraph or two describing what happens)

An end user, Sally, is searching for a specific, known item by title. Sally is on DSpace’s home page and noticed a search box in the side navigation accompanied by a button which reads “Search”. Below the search box and button, a link is shown which reads “Advanced Search”. Sally enters the title into a search box on the front page, hits return, and is presented with a list of results.

The list of items which are shown in the search results show the following information for each item: title, authors, type of item, whether the item has a publicly accessible full-text associated with it. Sally also notices that the way the search results are rendered is similar to the way they are rendered on the browse-by pages.

The item Sally was searching for appears at the top of the list because the title matches the search. Sally clicks on the item title and is presented with the item page.

An end user, Sally, is searching to see what graduate work has been done at the university on a specific subject, propeller aerodynamics. Within the thesis and dissertation collection, she searches for "propellor aerodynamics" and is presented with a list of titles. These titles are ranked according to their relevance (if the term appears in the metadata, the item appears higher in the ranking), but she can sort by title, date of publication, and author if she wishes. She then decides she wants to add a qualifier to the search "post stall aerodynamics" and is presented with a smaller set of results.

Sally wants to find an item where she remembers only part of the title. When she does this search, she finds that the word is very common and the results are in the hundreds. She remembers the year the item was published, so she goes to the advanced search screen and limits her search to title and year. The item she is looking for is in the top results.

For each of the search queries which Sally performs, only items are shown for which Sally has read permissions.

6 Comments

  1. + Respecting permissions

  2. - faceting as a way to apply search filters, if this is not covered in another use case

    Direct link to advanced search

    Needs more specification on what our requirements are for the listing of search results

  3. Allow for customizable output of search & browse results to highlight the aspects relevant for a particular repository. E.g. show (or not) which items have open vs restricted access, metadata only vs full text, etc.

  4. A list of examples to fuel discussion on particular questions

    Unified presentation of result lists for search and browse

    In the 15/02 meeting we agreed that consistent listings for browse and search features are desirable. There were no counter arguments.

    Example of a repository that already made browse and search results more consistent by showing the same fields:

    https://bibliotecadigital.ipb.pt/browse?type=author&value=Pais%2C+Clarisse

    https://bibliotecadigital.ipb.pt/simple-search?query=rcaap

    A single listing style for the entire repository VS allowing variations on community/collection level

    We also briefly discussed whether there should be different listing styles across the repository or not. There was a voice to keep all list styles consistent. However, there are use cases of repositories with mixed content, that may want a more visual / gallery type of listing for collections of images ( http://pandektis.ekt.gr/pandektis/handle/10442/14056/browse?type=title&submit_browse=Title&sort_by=1 ) and video thumbnails. Or geographical/map based listing for geograpical content ( http://pandektis.ekt.gr/pandektis/handle/10442/1 )

    Idea/proposal : Apply a single list across the repository, but allow for collection/community specific listings.

    Displaying rights information

    Lock icon/overlay on top of thumbnails to convey embargo information

    https://www.repository.cam.ac.uk/

    Displaying item type




    Result lists: Display whether or not a file is attached

    Only relevant for repositories that allow metadata-only items. To be avoided: user finds a result that he or she likes, clicks on the link and finds out that the content isn't accessible.

    Thumbnails vs no thumbnails

    Are thumbnails really essential/desired for all repositories to make the content more vivid? Should we also cater out of the box for people who want listings without thumbnails?

    Case against thumbnails: Google doesn't do thumbnails for their research repository

    Examples in favor of thumbnails:

    https://openknowledge.worldbank.org/

    https://opendocs.ids.ac.uk/opendocs/

    Giving direct access to the file from search results

    May only work well in cases where there's only a single bitstream. Google does it

    Intuitive and easy sorting of search results

    The sorting should be adaptable very quickly. Users currently expect that they can click the column header to modify sorting.

  5. Examples from outside the DSpace community we can learn / lend from

    CKAN

    https://data.gov.uk/data/search?q=

    Faceted search similar to current XMLUI

    No advanced search?

    Dropdown option for sorting

    Title, publisher and abbreviated description

    Zenodo

    https://zenodo.org/search?page=1&size=20&q=data

    Nice tagging example for publication date, article type and access information

    Title, authors and description

    At the bottom of a listing they also show the uploaded date. Not convinced that this is relevant enough for the search listings.

    The separate view button also makes no sense to me, since the title, authors and description are all clickable.

    The sorting options menu is worse than what DSpace already has today.

    Paging at the top of the page doesn't make sense to me: you only want to use paging after you discover that the current page doesn't have the results you are looking for.

    Faceting possible.