[UXPROD-4276] Replace Location Details accordion with solution to support discovery integration Created: 02/Nov/21  Updated: 08/Feb/24

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: None

Type: New Feature Priority: TBD
Reporter: Erin Nettifee Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: discovery, enettifee-reviewed, locations
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2021-11-02-10-07-22-107.png    
PO Rank: 0

 Description   

Current situation or problem:
Currently, Locations has an accordion for 'Location details' that serves no workflow function. See screenshot in attachments.

It was added early on in FOLIO with the intention of eventually supporting more complex circulation rules based on locations, but that development did not occur. And because it does not have any current functionality, it is confusing for new adopters.

What we'd like to do evaluate the use cases for an approach that will integrate well with discovery needs. It may be that the existing solution can be used as it is and we should just document the intention of it so that new adopters know that it can be used that way. But it may be that we actually need a different solution (like something with controlled vocabularies).

In scope

  • TBD

Out of scope

  • Permissions changes - if you can edit a location, you can edit whatever is in location details, they do not need to be permissioned separately.
  • TBD

Use case(s)

  • Big Library keeps special items for their President's Office in Location Y. Because these items are high-profile, they want to send requests for those items to an external email form so be reviewed by staff in the President's Office before the request is filled. They add a special flag or notation to Location Y in the Location details tab such that when the discovery layer shows items in Location Y, it knows that the patron request workflow should send patrons to an email form instead of trying to request the item in FOLIO.
  • Main Library has a shared print collection held in a consortial warehouse that many libraries in the area use. Main Library split the cost of this collection with four other libraries in the consortia. The records for that collection are maintained by Rival Library, not by Main Library, but Main Library still wants the Shared print collection to look like a Main library collection in their discovery layer. They add a special flag or notation to the shared print locations such that when the discovery layer shows items in that location, it knows that the request button needs to send them to ILLiad rather than trying to place a FOLIO request.

Proposed solution/stories

  • Tags could be leveraged here but only once the additional features outlined in UXPROD-775 Analysis Complete have been completed. Given that 775 has not been prioritized for development, and these discovery layer needs are being brought up by libraries in production, I'm not sure it makes sense to wait for tags central management to happen.
  • The current key/value pair could work here, except it doesn't have controlled vocabulary, and it's not multiselect. It seems like both of those options would be desired.

Links to additional info

Questions



 Comments   
Comment by Erin Nettifee [ 02/Nov/21 ]

Per Slack convo, created jira and assigning to Khalilah Gambrell

Comment by Cornelia Awenius [ 04/Nov/22 ]

Erin Nettifee Khalilah Gambrell Please suspend this. The hebis network (Germany) is looking into possible ways to use location details.

cc Uwe Reh 

Comment by Erin Nettifee [ 04/Nov/22 ]

Cornelia Awenius can you tell me more about the use case for Hebis? f it doesn't fit naturally into that area, I'd rather explore another potential feature like implementing the notes plugin to meet feature needs.

Comment by Cornelia Awenius [ 07/Nov/22 ]

Erin Nettifee  The idea is about storing additional location information that is needed for the discovery layer. We don't have anything detailed yet, just thinking in various directions.

Comment by Erin Nettifee [ 07/Nov/22 ]

Cornelia Awenius thanks for the response — I'd really like to be able to chat about those specific needs when you all are done with your thought process, because I'm not convinced that continuing to offer Location details in the way it was built/displayed is the right thing for the project to do, and I wouldn't want Hebis to start it using it in a way that was not something that would then be documented and supported in future releases.

Comment by Thomas Trutt [ 04/May/23 ]

I was looking at this field for a use case. We have a few locations at Cornell that require a different request workflows via our discovery layer  (ILS, LibForms, etc). Currently these flows are hardcode into the OPAC's business logic, but i would like to move these to FOLIO. My idea was to use the location fields to store a key value pair that could be used by the OPAC to trigger these special request flows. it would allow staff to set up locations without requiring code change to our opac. 

I am just looking into this as a possibility, and im open to discussing a better way to do this. I think part of the issue is that this data is very unstructured. If instead the data was like the custom data fields in users it may be more useful and flexible. One concern i had was, if a key was missing, spelled incorrectly or incorrectly camel cased, it would case issue. With a custom field approach those key names would a constant.  As well as adding guidelines as to the data expected for a given field. It would also give an upgrade path if anyone started to use these fields.

Comment by Uwe Reh [ 26/May/23 ]

As Cornelia mentioned, we at the 'hebis' consortium will need the location details for non standard lending options in our libraries.

E.g.

  • The items at this location are not covered by FOLIO's circulation module. Their circulation is still manged by local lists in the department. 
  • Generally, items cannot be borrowed at this location. However, it may be possible to borrow items for a weekend against a deposit.
  • This location is only accessible on demand. Please call ...
  •  ...

Our plan is to get the location detail via RTAC passed as hints to our discovery system.

Comment by Uwe Reh [ 02/Jun/23 ]

More in relation to the question.

In this case key/value seems to be sufficient to me.

A locally controlled vocabulary like the note types would help to avoid typos and is probably more self describing. But i doubt if it's worth the effort.

Since the use cases are heterogeneous I would vote totally against specialized fields or a fixed vocabulary.

 

 

Comment by Erin Nettifee [ 15/Jun/23 ]

A locally controlled vocabulary like the note types would help to avoid typos and is probably more self describing. But i doubt if it's worth the effort.

Sure, I understand that Uwe Reh. I guess my thought process would be that if this is being codified as part of the location record, it is worth it to make it more robust at this point by supporting controlled vocabularies and multi-select. It's unlikely that it would be improved later on.

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