2020-06-15
- Emma Boettcher
- Natalie Sommerville
Owned by Emma Boettcher
Agenda
- Review revised wireframes for item state on item record and checking in items
- Status history wireframe
Notes
- We talked about the whether the Needed for element displays in the top of the record in the item record.
- Is there a use case for putting a Needed for on an item that has a Status of Available; you might be assigning the Needed for while the process was still Available, but then checking it in or out.
- If the state is In process, there might be value in seeing where it is in process .
- For circulation staff, there is value in seeing more information about the item state in the item list.
- We discussed having the availability and process displayed at the top of the item record screen. A middle ground would be to have the top of the item record display that an item is in process and to the Process accordion would provide more detailed information. The consensus was that this works. Scenario: A staff member sees from the item list that an item is in process, selects that item record, and scrolls to the process segment of the item record.
- Ideally, we would be able to configure by user what is most prominently displayed.
- The group discussed where Requests information should be displayed. The guiding principle should be that resource access staff should not have to drill down to see this information.
- Can something be in a process without having the availability of In process? Scenario: could have an availability of Missing and a process that enables replacement, etc.
- The group reviewed the revised wireframes for item state on item record and checking in items. We looked at model wire frames for an item that has Needed for and patron requests. Resource Access members agreed that notification of a patron request should take precedence over Needed for information since fulfilling the patron request will be first in 90% of cases. "Fulfill" will be an element in this screen, but patron request should be the default and any other action will require override. An option would be to make the screen look like the request fulfillment screen, but there was concern that it would be too easy to override without considering the Needed for state. Emma will consult with a UI designer.
- The group discussed a status history wireframe based on last week's conversation about the need to see information about changes to the item state elements. How far back would you be looking for this information? SMEs at Duke have said as far back as it can go. Maybe a proposal would be that for circulation information is retained for the past 90-days in the UI an, with earlier circulation data in the LDP. All item state information is needed in the UI. Maybe a service point filter could be useful so that libraries have the option of scoping down item state information. What other filters might be needed, particularly from the metadata management perspective? Exporting the metadata to Excel might be a useful tool for scoping and evaluation. Is location for the item something that should be tracked as it changes? We should understand the functionality of the Change Tracker app better so that we don't develop overlapping functionality. Has Metadata Management been discussing the Change Tracker? Not recently, but Laura has been looking at bibliographic and item metadata that needs to be tracked. Chicago also been discussing this, particularly for tracking work statistics.