2023-09-07 Resource Access Meeting Notes

Date

07 Sep 2023

Recordings

Find all recordings here: https://recordings.openlibraryfoundation.org/folio/resource-access-sig/ (pw: folio-lsp)

Zoom

https://zoom.us/j/337279319 (pw: folio-lsp)

Attendees

Brooks Travis; Cheryl Malmborg; Claire Hoag (she/her); Julie Bickle; Moentnish, Shirley J; sjkimball; Tara Barnett; Thomas Trutt; Tobi Hines; and others

Discussion Items:

Meeting Notes

• (05:57) Julie asks for any additional topics or announcements. There are none.
• (06:40) We look at the document being assembled by the group interested in Call Number Sorting for Page Slips
• (07:22) Tara summarizes the discussion thus far. Claire at CU Boulder had asked about Call Number Sorting for Page Slips–sorting a great number of slips by hand is very painful for CU Boulder, and using the excel sheet does not work for their context. We discussed this a little bit already, and there are some small variations in how this could be performed that need to be discussed further, but overall the task seems simple: sort the slips in call number order, rather than the current sort order (order of request). What we are seeking is further discussion of the feature's requirements, as well as a better understanding of the steps that would move this forward.
• (08:50) Claire describes the problem at CU Boulder. There are between 100 and 200 requests every morning, and this is very time consuming to sort. Sierra, their previous system, sorted by location and call number order. Several student workers pull books at one time. Claire reviews some of the locations at CU Boulder.
  • Susan (10:10) asks for clarification–are all the locations at the same service point? Claire confirms that this is the case, and expands on the branches, Law library, and off campus storage structure. Off campus sorts by barcode, but we determined later in the meeting that this is out of scope. Susan notes that this is similar to the situation at 5 Colleges.
• (11:10) Julie asks how call number slips are currently sorted in FOLIO. We believe it's first in last out, or the reverse.
• (11:37) Thomas says that everything that we want to sort on has to be on the request object. Sortable call number field is not on the request object. Thomas notes that this initial request for functionality has expanded to some configuration. The sorting fields are back end work, but selecting how it is sorted includes front end work. Thomas asks if we want to go down this path now? (13:24) Tara asks if there is another default, in reality?
• (13:42) Julie breaks this down for us: 1) The use case is how we want staff slips to be sorted. 2) Do we add other criteria by which they could be sorted? 3) If there are options, are those options are configurable? and 4) When should this selection of the configuration take place? So, are these individual features? As described, this would be quite a big thing, potentially spanning releases. (16:00) In chat, we (Brooks?) note that performance might be affected by some methods.
• (16:45) Susan argues that the first pass should cover location and call number, and having it hard coded as a first level feature would solve much pain. Susan also notes that if it's configurable, it should be configured in settings, not at the point of printing.
• (17:50) Julie notes that we're using these slips to go find items, and in most cases, that will mean a call number. We address again the question of configuration or hard-coding the sort. In general, if we want to configure this, where should that configuration take place? And if we do not want to configure it, ok to change the global logic of page slip sorting?
• (20:14) We hammer out the "to configure or not to configure" question for this discussion. We are happy to isolate a non-configurable solution as Susan described, which seems like the lowest bar, as long as that doesn't make life worse for anyone currently on FOLIO. Susan adds that this may in fact make possible the work that might come later. We are not cutting off future development.
• (22:40) Julie notes that she will need to check if this strategy will make anyone's life worse, by reaching out on slack and directly to live users. Would changing the sort order break anyone's current workflows? How do most users feel about the current functionality?
• (23:40) Cheryl describes the process at UChicago. Chicago creates their own pull lists taking into account sources other than FOLIO. They sort not only by call number but also by floor. The proposed plan does not affect Chicago's process. Cheryl also notes that sorting first by effective location and then by call number would be best.
  • (24:45) Thomas explains one situation in which sorting by Shelving Location would throw off a workflow–in Cornell's A/V collection, items have different locations to reflect who owns the item, but the items are shelved together. Tara offers a similar example from Reserves, where it is common to add something like loan type to the location. Both of these are very narrow examples, and in both cases, the libraries are no worse off than they are with the current system, and arguably the call number helps them as well.
• (27:45) While Julie will follow up on slack about this question, the room's consensus is clear: no one in the room actually sorts by the current sort order in FOLIO. Julie reminds us that we need to consider others outside this room.
• (28:45) Julie asks what order of effective location and call number should be used? We discuss briefly–NOT UUID!!!–but in general, because locations have no inherent sort order, we believe they should sort in alphabetical order. Susan adds that because you can only print for one service point, the slips are already grouped that way. Julie points out that "alphabetical A-Z" includes special characters, numbers, etc. For later on, we will need to define "A-Z" for transparency. What technically does alphabetical mean in FOLIO?
• (31:50) We ask whether or not there are multi-page staff slips actually being used in a live library? No one has an example. Susan discusses how slips are scaled and set up for printing. (34:47) Thomas notes that LOC might have a need for multiple pages, for their secure requests. Julie says that for this feature, it appears we do not need to do anything to change current behavior.
• (36:12) Julie says that the current button for generating slips would also not change.
• ...and, we have somehow managed to define expected outcomes! The way the pick slips are generated does not change, the PDF and tokens do not change, what changes is that when the PDF is generated for X number of requests, the order of requests is to be first sorted by effective location and second sorted by effective call number, and in both cases sorted alphabetically.
  • BUT WAIT!
  • (37:44) Thomas notes that we all keep saying "effective call number" but in fact the field that would result in the call number slips being sorted is "effective sort call number" or Shelving Order. The Shelving Order is normalized.
    • From the documentation: Shelving order. A system-generated normalization of the call number that allows for call number sorting in reports and in search results.
    • From the API guide: the field is called "effectiveShelvingOrder" and is defined as "A system generated normalization of the call number that allows for call number sorting in reports and search results."
    • Julie asks why this is, and what the difference is. Thomas explains that LC Call Numbers do not sort in a database–they have to be normalized to do so. The Shelving Order field can be sorted, and effective call number cannot.
    • We have some questions about what exactly is sortable in FOLIO currently. Does this include Dewey? Books shelved by author? How is the sort built? We think it's based on Tod Olson's code, but we're not sure.
  • (41:48) So, in fact, what we need added to the record object is the effectiveShelvingOrder.
• (42:16) Thomas wonders how Title Level Requests (TLR) would affect this as well. Titles may have different item-level call numbers. Brooks notes that as currently implemented, any TLR request that is ready to be paged has an item attached. There is some desire to change this functionality in the future, but that is a future problem to be solved another time. Julie asks if we would want to wait until TLR is further along? We agree that we can move forward, and also that perhaps it's possible to have any item that falls through the cracks (no location, or no shelving order) filed at the end, sorted by title. That way there's a catch at the end.
• (45:40) We start to wrap up and look at what needs to happen next. We've established what results we want to see and our needs, so next we need to phrase what we've discussed in the format of the Jira feature template. The PO will also need to write the back end stories, and may ask for assistance from the dev team who can spec this out technically. Thomas is already working to fill in the feature template on our existing word document. Tara's going to do the notes from our discussion to make sure nothing gets missed. Susan and Claire will look things over to make sure their needs are represented. Julie will do all the magic.
  • Useful trivia: the word for wolverine in German is "Vielfraß" which means "that which eats a lot." Bonus content for anyone who read this far: this is likely due to a false etymology.
• (49:37-end) Thank you Julie! Yay everyone! Go team!