Where was VitroLib deployed and/or used?

• Cornell Hip Hop collection

• As part of ARM workshop

• An ArtFrame-specific instance for Columbia

Sources of user-feedback and evaluations

• In-person discussions

• Separate meetings with catalogers at Cornell and at Stanford

• Three rounds of usability testing using task-based think alouds

• Round 1 - Feb 28, 2017. 2 participants. Summary of results.
  

• Round 2 - March 31, 2017. 4 participants.  Summary of results. 
  

• Round 3 - June 28 - July 11, 2017. 7 participants (4 institutions). Summary of results.
  

• Feedback from Princeton

• Cornell Hip Hop Cataloging Experiments. Consolidated feedback
  

• ARM workshop

Background: Catalogers and current systems

As background, it is important to understand how catalogers interact with their MARC-based editors.  In their current editing environments, catalogers can exercise control over which fields are displayed for entry through the use of templates and macros, and they then are able to quickly edit the information on the page and then scan at completion to confirm they have entered all the information they needed to capture.  Given MARC standards and the field and spreadsheet-like display and entry mechanisms, catalogers can quickly add new fields add multiple values for the same field.

Summary of themes, observations, and discussions

• Original does not mean starting from scratch

• Although original cataloging is considered distinct from copy cataloging on a conceptual level and as a workflow, catalogers search for existing works or related content even with original cataloging.  The notion that original cataloging starts in a vacuum has not held up in the interviews and usability testing.

• Keyboarding vs. GUI

• Command Line Interface/CLI or keyboarding solutions should be created for a production editor.  A reason for pursuing a keyboarding interface include the prevalence of carpal tunnel syndrome. Discussions also seem to indicate keyboarding solutions enable faster data entry than mouse clicks.

• Suggestions for reducing typing and reusing information

• Highlighting commonly used values in dropdowns, preventing users from having to scroll through long lists (such as for languages).  

• Default values for certain contexts, such as default values for a particular collection being cataloged where the values are likely to remain the same for multiple properties or fields for many items in the collection.

• Templates/macros for specifying which fields are used most often for particular types of content or to serve as a starting point for cataloging

• Lookups

• Usability testing revealed the need to modify interactions with lookups and highlighted the need for results to be returned more quickly for search results.

• We began preliminary review of what context to retrieve for particular lookups. In general, catalogers appreciated the additional context, but we still need to design and evaluate how to provide context for different vocabularies (as each vocabulary will have different requirements for providing information).  We have a preliminary set of contextual components with which we can begin this process.

• Cataloger feedback and results from usability tests showed how the relevance rankings of the results needed to be modified to better suit their expectations.  For example, catalogers provided feedback that Genre Form lookups should rely on an exact match with the search query. The search algorithm that adds results that match some of the query terms was not deemed appropriate for the expected search behavior for this  vocabulary.

• Getting to the authority records/authorized information from the search results is still important.  

• Editing vs display

• Catalogers had feedback regarding Vitro’s default design which shows information on the entity page (e.g. Work) and allows users to add a property at a time by taking the user to a separate page where they can enter information for that property.  In discussions, catalogers identified how they wished to see all the information they had entered (and only that information) in a way where they could quickly scan and confirm what they had entered.

• The ability to enter multiple values for a property on the same screen (without navigating to a different screen every time) was suggested as useful. For instance, on the initial work/instance/item creation page, the user can enter just one activity/role and just one subject heading.  The desired behavior is to be able to add multiple activities/roles (e.g. authors or performers) on the same page and multiple subject headings on the same page.
  

• Vitro’s entity and property-based display of information and related editing was not always easy to understand.  For example, when clicking on the edit button, from questions and cataloger feedback, it became clear that it wasn’t always obvious whether the interface was allowing them to edit the relationship between the subject and the displayed object or editing the object itself.  

• One suggestion was to reduce the empty screen space on the Vitro display to enable more information to be displayed on a single screen.  

Interface changes and underlying model changes

Interface design aims, in part, to make the interface usable by providing as much support as possible for users to complete their tasks.  We ask end users how they currently perform their tasks to clarify not just how they do their work but what they are trying to accomplish and how certain design decisions in their current systems help or hinder them in their goals.  

Discussions with and feedback from our expert and seasoned cataloger user base show how their work goes beyond data entry to a thorough understanding of how concepts and bibliographic materials can be classified, how people can be identified, and how they all relate to each other; where to find this information through a review of the item in hand and  through the use of vocabularies, authorities, and external vetted or trusted sources of information; and how to connect or integrate this information back into their ILS systems.   In our cataloging experiments, we were providing not just a new interface to catalogers but basing that interface on a changed model that redistributes and modifies how and where information needs to be captured. Precisely what and how to clearly explain about this changed model in an updated interface, without relying on training as a means of taking away the need for usable interfaces, is a balance the library community, technologists, and catalogers will need to explore in any linked data cataloging editor they design and implement.  

The outcomes of this project are thus necessary context for understanding catalogers' tasks and how they accomplish these tasks.  Project outcomes also include evaluations of certain designs through more informal feedback, formal usability evaluations, and hands-on experiments with VitroLib.  Much that has been researched and understood can be carried over to the design and evaluation of any future linked data editing tools.