2020-06-08

Agenda

  • Housekeeping: halfway mark, password for Zoom calls
  • Wireframes: Check In, Inventory, Settings (configuration of Needed for, Process), Notes

Minutes 

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  > (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
  • might give more space and complexity vs current design, but some say 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

  1. generic note available for any use case ~ librarians are going to manage processes in different ways
    or
  2. a specific note

Consensus was #2, a specific note

Use case for a Needed for note, i.e. marking something missing vs. preservation 

  • 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

Who is responsible for clearing the note?

  • what's the process
  • 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
  • item state history would provide a history in the event notes are cleared accidentally
  • comments about levels of detail necessary 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. 


Check-In

  • 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? 
    • 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 if patron wants to check out a requested item?
    • would patron requests show up in this same modal

Summary:  make UI solution clear to frontline / public facing staff

Minutes submitted by Susan Ponischil

Attendees:

  • David Bottorff
  • Erin Nettifee
  • Susan Ponischil
  • Martina Schildt
  • Natalie Sommerville
  • Christie Thomas

Recording

Zoom recording

Action items

  • Zoom calls will require password moving forward.  Emma will include info in email.