Agenda
- Housekeeping: halfway mark, password for Zoom calls
- Wireframes: Check In, Inventory, Settings (configuration of Needed for, Process), Notes
Housekeeping
- 2 month mark we've settled a few things, may change when moves on to developers. Original meeting commitment through July remains.
- Zoom calls will require password moving forward. Emma will include info in email.
Wireframes:
Needed For
- list of values must be present in the system
- helpful to see the UUID or ability to query by name
- Should Needed For in Process be on the same screen? YES
How often would you expect to have a value for these fields to be a Process but not a Needed for and vice versa?
Process
- previously discussed tenant can say 'tenant of * value' - user is alerted
- catalogers - would want a user alert
- screen real estate is a consideration/issue
- if editing a category, once in category is that where the user alert appears rather than seeing all at a glance - unfortunately no tables in settings that work that way
- pop up live at Needed for and Process level? YES > put it here (not tenant level at this stage - see what happens, see if tenant is compromised)
- question about plans to prioritize different Needed for's - answer was we don't know
- makes sense for these to be put together and treated as entity of cataloging Needed For process
- manual defines things might give more space and complexity vs current design, but Erin doesn't prefer - not a good UI model
Consensus was to proceed with Needed for and Process wireframes with modifications discussed
Wireframe
item state note added to wireframe
Should it be
- generic note available for any use case ~ librarians are going to manage processes in different ways
or - a specific note
- Consensus was #2, a specific note
- ADD who created note and when note was created
- item status date displayed > Repeat for Process and Needed for > ADD process and user info
- granularity of note and tying them to item state is important - availability and in process - needed for would need more info to track
- having user data is helpful (although laws in Germany may prevent this)
- note in Needed For should be archived in the system but not visible to user
Another use case for Needed For note, i.e. marking something missing vs. preservation
Erin: librarians will manage processes in different ways hence comment about open
granular notes for each of 3 states -
will note go away once or remain on each Needed For added
how are changes to various states logged in the system - we haven't discussed yet
change process from cataloging to something else does that change the note or is the user responsible for clearing that
process state vs. availability state -
Needed For should include option to manually set a null value - if item in cataloging process completed note should go away
clearing note - if process is selected accidentally note is lost - how important would that be - it would be in the item state history
Comments about levels of detail necessary and info should be available at point of need.
Summary: Item State Wireframe - add when and who added the note, retain Needed For notes and locate at point of need.
________
Modals for checking in items
Item needed for staff
view both pre and post scan
suggestion to change 'Cancel' to 'Close'
how would it interact with other modals
Confirm check in
should cancel / confirm have use cases other than Preservation and Reserves
fee fines here? never adding manual fees for sale items not overdue items. - not necessarily worth development time
Summary: pop ups only need to happen at checkin-checkout
what happens if patron wants to check out item with request on it - let librarians on user end decide
would patron requests show up in this same modal - make CLEAR UI solution if so make it clear to frontline circ staff that there is a patron request
Summary: make UI solution clear to frontline circ staff