[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: |
|
| PO Rank: | 0 |
| Description |
|
Current situation or problem: 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
Out of scope
Use case(s)
Proposed solution/stories
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.
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 ] |
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. |