[OPEN-ILS-DEV] Curbside pickup in Evergreen

Tue Jun 9 16:09:33 EDT 2020

How do you do, fellow kids^Wdevelopers!

We have nominally completed the first round of development for
curbside delivery functionality, and want to get more eyes on it ASAP.
We've set up a concerto test server, recorded a short video demo, and
are putting together documentation for configuration and use.  All of
that is detailed in a google doc at:
https://docs.google.com/document/d/13DmNCqasfTTPud4Hl5i91UPf_7NGda0bgtimJWc21Vw

There are currently 68 commits on the branch linked from
https://bugs.launchpad.net/evergreen/+bug/1879983 but we anticipate
creating a new, easier to follow branch in the next couple days that
will squash most of those down to just a few.  We'll follow up here
again when that's complete.  In the meantime, please poke at the test
server, and the extant branch if you want to see how it's working
under the covers.

We have already collected several ideas for enhancement including:
 * Allowing patrons to signal the desire for curbside delivery at hold
placement time
 * Triggering print and email receipts at delivery time
 * Allowing "claiming" by staff of a to-be-staged appointment, for coordination
 * Restrictions on scheduling pickup times based on shelf expiration
 * Interface location scoping (for management / oversight)

These will come later, if they do, but what is there now should be
useful and we would greatly appreciate testing and feedback.  We know
this week is not ideal for testing because of the conference, but
**gestures broadly**...

Thanks in advance, all!

--
Mike Rylander
 | Research and Development Manager
 | Equinox Open Library Initiative
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at equinoxinitiative.org
 | web:  http://equinoxinitiative.org

On Thu, May 21, 2020 at 1:49 PM Mike Rylander <mrylander at gmail.com> wrote:
>
> Hi all,
>
> This is a followup to LP bug
> https://bugs.launchpad.net/evergreen/+bug/1879983 to give a bit more
> technical information on our plans for curbside-facilitating
> interfaces in Evergreen.
>
> First, the main goals are to get something out that the most libraries
> possible can use, does not impose any extra work which does not
> facilitate curbside pickup, is invisible to libraries that do not
> provide curbside pickup, and has a very low risk of data-impacting
> bugs.  To that end, we are designing this so that it does not shove
> itself into existing workflows or require existing data structures to
> be made aware of it.
>
> The initial implementation consists of a single new database table and
> a set of business logic that will help staff organize their physical
> work around the expected arrival times of patrons.  A new
> Action/Trigger reactor and example event definition for use on the
> "hold.available" hook will be available to begin the curbside process
> when the first hold at a location becomes available for pickup for
> each patron.  A new hook, "hold.offer_curbside", will be available to
> prompt patrons to choose an appointment time per pickup library,
> though where appropriate the existing hold.available notification can
> serve this purpose as well.  A second new hook,
> "hold.confirm_curbside", and example definition will confirm the
> appointment via email or SMS, or both with multiple event definitions,
> and can provide a "check in" link or other "check in" instructions to
> the patron.  Both self-check-in and staff-check-in ("call the library
> when you arrive," etc) will be supported.
>
> Staff will be able to decide the size of each appointment window
> (default is every 15 minutes) and the number of appointments that
> should be allowed in each window (default is 10).
>
> Code will be available to allow patrons to request an appointment for
> themselves, but a staff interface will also exist to allow
> appointments to be scheduled for patrons that cannot or do not want to
> do it themselves.  From there, a set of interfaces will assist staff
> with each step in the curbside process, starting at the point that a
> patron has requested an appointment.
>
>  * Create appointment for patron: the aforementioned staff interface
> that can be used to create an appointment for a patron, rather than
> having the patron select an appointment themselves.  Once an
> appointment is created, but before the hold-ready items are staged,
> the appointment will show up on the next interface.
>
>  * To be staged: a list of appointments, with patron name and
> ready-item list, that have been requested, for which items on the
> local holds shelf need to be gathered and staged for delivery.  This
> interface looks two appointment-window-intervals into the future for
> upcoming appointments, and displays all appointments from that time
> back that need to be staged.  This interface could be set up as a
> "dashboard" on a centrally located computer to display work needing to
> be done, but will be usable on tablet-sized devices for staff working
> to stage appointment item batches.  Once marked "staged" an
> appointment will fall off this list and move to the next.  The staging
> staff ID will be recorded, along with the staging time.
>
>  * Staged awaiting arrival: a list of appointments, with patron name
> and item count, that are ready to be delivered to the patron for which
> the patron has not yet arrived.  This interface can be used by staff
> to mark a particular patron as "arrived" if the library does not want
> to use patron self-check-in.  Once marked "staged" an appointment will
> fall off this list and move to the next.  Staff will be able to mark
> the appointment "arrived & delivered" to complete the curbside process
> immediately, if that is the local workflow desired.  In this case, the
> appointment will be moved to the final "Delivered today" interface.
> The delivering staff ID will be recorded, along with the delivery
> time.
>
>  * Patron has arrived: a list of appointments for which the patron has
> checked themselves in as arrived, or staff have marked as arrived.
> This interface can be used as a dashboard on a centrally located
> workstation to show the appointment item batches that need to be
> delivered to the patron waiting outside.  Staff will be able to mark
> the appointment batch as "delivered" from this interface.  Once marked
> "delivered" an appointment will fall off this list and move to the
> next.  The delivering staff ID will be recorded, along with the
> delivery time.
>
>  * Delivered today: a list of appointments that have been marked
> delivered today.
>
> All interfaces will have links to the patron holds or checkouts
> interfaces, as appropriate, to facilitate any adjustments that need to
> be made.  All appointment batches will be assumed to contains all
> ready-for-pickup hold items, so staff will need to adjust holds that
> cannot be be found on the hold shelf (or otherwise) at any point
> before marking an appointment as delivered.  When an appointment is
> marked delivered all hold-ready items are checked out to the patron as
> the delivering staff member using open-ils.circ.checkout.full.override
> so that all override-able events are ignored.
>
> To simplify configuration and code in this initial version,
> appointment offers will be generated for open hours as defined in the
> hours of operation table.  This means that appointment times will
> align with the library details page where patrons can see open hours,
> and is meant to match the definition of "open" as "when the library
> will be interacting with patrons".  Libraries should adjust their
> hours of operation to match when curbside pickup will be available
> before enabling the feature.  Library closed dates are currently not
> taken into account, so the feature should be enabled on the day that a
> library wants to start offering the service, if they want to make use
> of patron-scheduled appointments.
>
> It's all entirely optional, and is meant to support and streamline
> nearly any staff procedure already in place.
>
> In addition to the normal software documentation that describes
> features and settings, we also intend to provide a few basic workflow
> descriptions to help staff make the most of the feature within the
> constraints that the physical space may require.
>
> We welcome questions and feedback, as always, but we won't be spending
> much time on details of specific workflows beyond making sure that
> physical processes can be supported and we don't make something
> libraries are already doing significantly harder or impossible. We
> want to get this out ASAP!
>
> --
> Mike Rylander
>  | Research and Development Manager
>  | Equinox Open Library Initiative
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  miker at equinoxinitiative.org
>  | web:  http://equinoxinitiative.org