Locations and Service Points (UXPROD-771)

[UXPROD-3056] FE: Effective location property on the holdings record Created: 30/Apr/21  Updated: 21/Mar/23  Resolved: 01/Feb/23

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Orchid (R1 2023)
Parent: Locations and Service Points

Type: New Feature Priority: P3
Reporter: Charlotte Whitt Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: round_iv, ui-only
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Skärmavbild 2021-01-25 kl. 17.48.19.png    
Issue links:
Defines
is defined by UIIN-1520 Display Effective Location to Invento... Closed
Gantt End to Start
has to be done after UXPROD-2321 BE: Effective location property on th... Closed
Release: Orchid (R1 2023)
Epic Link: Locations and Service Points
Front-End Confidence factor: Low
Development Team: Prokopovych
Cap Plan Fix Version (DO NOT CHANGE): R2 2021
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: GBV (MVP Sum 2020): R4
Rank: hbz (TBD): R4
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

The back end work has been done for Iris (R1 2021) to accommodate the OAI-PMH work, UXPROD-2321 Closed . This feature is about implementation the UI display of the Effective location property in the top of the holdings record

The purpose of this feature is to display the Holdings Effective Location, in the top of the holdings record, according to a similar algorithm as defined for the Item Effective Location.

The primary use case is to assure that a computed location is available for holdings that do not have items.

But, given that items may be moved off and on holdings during tech services workflows, having a value that only exists in certain use cases may lead to inconsistent search / UI / data behavior. The strong preference from the SME group was to have the holdings effective location value always be present, even if items are on the record.

Use cases where a holdings effective location would be used include:

  • special collection materials
    • sometimes item records may be added later (when cataloging is complete) but the holdings record should be visible in discovery before that point
    • sometimes item information is maintained in another system of record, like AEON or ArchiveSpace, and not in the ILS;
  • electronic items (eBooks, journals, databases)
    • these items don't circulate and don't really have physical equivalents, so many libraries don't create item records since the work doesn't seem to be needed;
    • if libraries plan to rely on FOLIO for a discovery layer extract, they want electronic holdings to be in Inventory;
    • if libraries want those electronic holdings to be discoverable in a discovery layer with a location facet (e.g., location = "Online"), then the holding record needs location information
  • other materials
    • microfilm - since patrons generally don't have microfilm readers at home, microfilm usually doesn't circulate, so many libraries did not create item records for them
    • periodicals (single and bound) - because libraries don't want journals to leave the building because they are expensive and can be hard to replace, they usually do not circulate, and so don't have item records.
    • government documents - similarly, because they don't generally leave the building, they don't circulate, and so may not have item records.

Requirements:

  • Create an attribute that is on the holdings record for the Holdings Effective Location that is a computed value, based on the values in the holdings permanent location and/or holdings temporary location, as follows.
Holdings Permanent Location Holdings Temporary Location Holdings Effective Location
A   A
Holdings Permanent Location Holdings Temporary Location Holdings Effective Location
A B B  

Other notes

The holdings effective location will not be used in any circulation workflows, since circulation requires an item record, and those workflows are already reliant on the item effective location which has already been built. That means no changes are needed to the circulation rules system.

Search / filter needs in Inventory

In Inventory, library staff will want to be able to filter to find all the things in a given location. The MM SIG (in consultation with other SIGs) will need to decide how holdings location search should behave with the addition of the holdings effective location attribute.

Right now (Honeysuckle and Iris), the location search options (as separate filters) in the holdings pane are

  • Effective Location (items)
  • Holdings Permanent Location

In discussion with the SMEs who have helped flesh this out in asynchronous discussion, they were comfortable with two possibilities for changing to search on the Holdings pane, including:

  • Option 1
    • Effective Location (holdings)
    • Holdings Permanent Location
  • Option 2
    • Effective Location (item)
    • Effective Location (holdings)
      So both scenarios would add a search for effective location (holdings), but may end up removing the option on the Holdings pane to search Effective location (items).

Additional functionality that will be needed (added in additional features)

  • Support for OAI-PMH for institutions that will rely on that functionality to support discovery layer integration (see comments from TAMU, MSU)
  • In reports, filters to find all the things in a given location

Further questions

Is there something on a holdings record that automatically tells you if the holdings record has associated items? Is that what holdingsItems is?

Discussed in MM SIG meeting on 2020-03-12
Follow-up discussion on location filtering from 2020-03-19: https://folio-org.atlassian.net/wiki/display/MM/2020-03-19+Metadata+Management+Meeting+notes

Discussed January 2021 in temporary Slack channel #holdings-without-items
Discussed January 2021 in RA SIG channel (sharing for input)



 Comments   
Comment by Charlotte Whitt [ 30/Apr/21 ]

Erin Nettifee - when you discussed the work on UXPROD-2321 Closed with the RA and other SMEs for the purpose of doing the Back End work needed for OAI-PMH, did you then have UX/UI mock ups made? Or would we need to do these from scratch, before writing up the UI stories?

Comment by Ann-Marie Breaux (Inactive) [ 30/Apr/21 ]

Hi Charlotte Whitt The effective location is always calculated by the system, and never assigned manually. Is that correct? If so, then I don't think we'll need to make any corresponding UI changes in Data Import. We fixed the BE schema changes that the previous BE work necessitated for Data Import as part of the Iris release.

Comment by Charlotte Whitt [ 30/Apr/21 ]

Hi Ann-Marie Breaux - yes that's correct. Exactly as the Item Effective Location is following an algorithm, and then is populated on the Item record, not editable data.

Comment by Ann-Marie Breaux (Inactive) [ 30/Apr/21 ]

Perfect - thank you Charlotte Whitt! I'm so glad not to have another to do on my list!

Comment by Erin Nettifee [ 30/Apr/21 ]

Charlotte Whitt I did not have any UX/UI mockups made - MM was super busy and we were trying to get the feature in without having to go to the big group for more work.

Comment by Erin Nettifee [ 03/May/21 ]

I will say I think it's not just adding the effective holdings location to the top of the holdings record, but also evaluating the filters for holdings and determining if they should change to search effective holdings location instead of or in addition to searching the effective item location.

Comment by Charlotte Whitt [ 03/May/21 ]

Erin Nettifee Yes, that's a good point. I'd like to loop in the UI working group (Result list, UI improvements, and more) with RA, RM, and MM representatives on that question re. whether replacing Effective Location (Item) with the Effective Location (Holdings) - or keep both, when searching in the Holdings segment.

See list of participants here - https://folio-org.atlassian.net/wiki/pages/viewpage.action?pageId=4662244

Generated at Fri Feb 09 00:28:59 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.