Status: Open (View Workflow)
Background: Back at the end of 2019, a couple of things happened that influenced our thinking on the design of the item record:
- We introduced the concept of "effective call number" and "effective call number string"
- effective call number - each element of the call number (type, prefix, call number and suffix) now has inheritance logic which is used to calculate the "effective" call number type, prefix, call number and call number suffix. If nothing is specified for these elements in the item record, the effective call number uses what has been specified in the holdings record. This is similar to effective location.
- effective call number string - this strings together various call number elements along with volume, enumeration and chronology. This string is displayed at the top of the item record and throughout FOLIO where call number info is needed (e.g. Requests, Loans etc)
- We wanted to introduce call number accordion on the item record similar to the one we have for location. The data in this accordion would provide insight into how the effective call number string has been calculated by showing the call number data coming from the holdings, anything that has been specified at the item record etc. While we never got around to implementing this accordion, we did put together a design and reviewed it with both the RA and MM SIGs. Adding a call number accordion required a small overhaul of the item record design because it pulled together elements that previously lived in other accordions. You can see the latest mockup based on these discussions here: https://drive.google.com/drive/folders/1LZjHKqoxQkNL4BYh_gOyrsSX1vTU9ZWX
- We did a card sort survey. This helped inform how we ordered the data in the mock-up above. Our focus at that time was really on the order of the data, not the layout and readability. That said, you can see that people had lots of thoughts on the layout and readability, as well. See results of the survey here: https://docs.google.com/presentation/d/1YtmDfWgiaB4TeYTRVHGkSpikabta8kzQ7bvlFVXc3gw/edit#slide=id.p1
Where we are now: We are now at a point where we have some available front-end development capacity and we'd like to finally implement this call number accordion. Since it has been so long since the mockups were reviewed, we feel it is worth revisiting them with the SMEs first. Also, rather than focusing only on the order of the data, we might as well take this opportunity to improve the readability of the item record. Please keep in mind that the item record and the holdings record share some data and folks generally like UX for the two records to be fairly consistent. So, if we make changes to the item record, we need to think about whether corresponding changes need to be made to the holdings record, as well.
Needed from UX:
- Review latest mockup of the item view pageas well as the results of the card sort survey to create an updated mock-up. I read the results of the card sort survey and it seems like lots of people find the location and call number accordion to be difficult to read. I remembered that your original mocks actually called for a different layout for the location accordion (not sure why it wasn't implemented this way). We might use this old design as inspiration for an update: https://drive.google.com/drive/folders/11gY11q1aShMNojNGYC1eFRqKaASBvlH- Please note, though, that the SMEs did say they preferred to have the "Effective location" at the top of the accordion, not the bottom. Also, "inherit from holding" as a menu option doesn't really work because the logic is more complicated than that.
- Create a mockup for the create/edit view of the item record to correspond with the proposal for the view
- Review the holdings (and maybe even instance record) to ensure consistency - these might need new mock-ups too
- Charlotte Whitt can help you get feedback on the new mocks from the MM SIG. We should also collect feedback from the RA SIG, as well.
- Please remember that we are trying to keep the changes to ui-only changes that will require front-end development only. If we get feedback that suggests we need backend changes, as well, we should create separate features and stories for that work because it's less likely to be prioritized
Please let me or Charlotte know if you have any questions!