Page Comparison

Date

22 Oct 2018

Attendees

• Andrea Loigman

• William Weare

• Cate Boerema (Deactivated)

• Cheryl Malmborg
• David Bottorff
• Joanne Leary
• Deb Lamb
• Emma Boettcher
• Kai Sprenger
• Kimie Kester
• Rameka Barnes
• sthomas (Deactivated)
• Anya
• Darcy Branchini
• Mark Canney
• Jana Freytag

Discussion tems

...

Notes

Notice logic - follow-up (Darcy)

• Darcy framed the conversation by noting that there were currently two different approaches to considering how to configure patron notices:
  • 1) To consolidate patron notice types together into bundled notice policies (e.g., fee/fine, overdue, etc. consolidated into notice policy A, which covers both)
  • 2) To split them out into separate notice policies (e.g., fee/fine notice policies separate from overdue notice policies) and call each separately through the circulation rules editor
• She walked the group through a spreadsheet (LINK) containing some use-cases for the consolidation approach.  The spreadsheet contained columns for Template|Event Trigger|Notes|Caveats/Gotchas
  • She also noted that the Fee/fine tab contained alternate scenarios (e.g., fee/fine notices triggered by periodic scan)
• David noted that, in his case, he didn't want to have to repeat the effort to encode the same recall notice logic into each individual 'bundled' policy (e.g., I might have many loan policy types, but only one fee/fine notice policy that would apply to all).  Darcy noted that this might be able to be accomplished in the Circulation Rules Editor by having a single 'fall-back' policy defined that would apply to all encoded circulation rules without having to duplicate effort.
• Andrea...

<Sean - I need to review the recording again to complete the notes>

Requests - Check-in modals for in-transit requests (UICHKIN-49) (Cate)

• Cate presented the modal and noted that it still needed a UX review to ensure it's using the appropriate conventions.
• She also noted that the routing indicated on the modal needed to be for the Service Point name, not the library name
• The group approved the mock-up

Requests - Check-in modal for item that is awaiting pickup (UICHKIN-50) (Cate)

• Cate presented the modal and noted that it still needed a UX review to ensure it's using the appropriate conventions.
• The group approved the information displayed in the modal
• The group noted that they would like the default (print=Y or print=N) to be configurable for:
  • 1) Different types of slips (i.e., hold, transit) AND
  • 2) Different service points
  • And noted that the ability to override the default from within the modal should be allowed
• The group agreed that these would be appropriate to configure in the service point record
  • Hold slip printing (default=Y|N)
  • Transfer slip printing (default=Y|N)
• Cate will mock these additions up and bring back to the group to review

Requests - Paging Requests (Cate)

• Asked whether there were formatting options for the slips themselves, Cate noted that there were different tokens to choose from to display on the slips.  Request from the group to add 'Pick-up service point' as an optional token to display on Hold Slips (FOLIO>Settings>Circulation>Staff slips>Hold.  Darcy agreed to add a story for this.
• Cate continued with the review of Tania's Item States - Use Cases spreadsheet, and reviewed the use-case for 'Paging request - Can be filled at pickup location' (Line 15 in the current spreadsheet).
  
  • Asked whether 'available' was the only starting item state allowable for paging requests
    • Group noted that you probably want to be able to define these separately, rather than hard-code them into the application
      • An example - In addition to 'Available', 'Recently returned' might be another starting item state that would be allowable for paging requests at a particular institution
    • Asked whether we could limit the initial implementation to those that have already been defined and add custom configuration later
      • David pressed on the need for customization - e.g., In process, on order - what states are these?  Also, you may not know what 'state' an item is in (e.g., items in storage)
    • Cate asked whether this same need would apply to other use-cases in the spreadsheet as well (e.g., Recalls and Holds)
      • Yes
    • Cate will talk to the developers about this to define which states you can create these
  • Asked whether 'available' as the ending item state was okay - the group agreed.
  • Asked whether 'requests' and 'checkouts' were the only states allowable 'In the new state'
    • David - again, customization is needed - e.g., what happens to trumped paging requests - do the original requests automatically turn into holds? - will want different configurations.
    • Mark noted that it seemed logical, in this case, for the original page to be cancelled, but agreed that it should be configurable to decide whether to auto-contact the patron.
    • The group noted that they needed to spend some time to think these workflows through.
    • Cate added updates directly to the spreadsheet to reflect the discussion points (G15 in the current spreadsheet)
  • Cate asked whether local request rules had been shared in the requests subgroup.  It was noted that this was challenging as these were stored in different places, but that they could gather these and do a walkthrough in ta future meeting.