Comment 2 for bug 1879983

Great proposal and I totally understand your focus on a v.1 experience that can be fielded quickly.

I don't see any mention of OpenSRF methods. Would adding them represent extra work, or are they part of the development plan? The Hemlock mobile apps interact almost exclusively through the OSRF gateway, and having a few basic APIs would I think enable a better mobile experience.

MOBILE USE CASES

These are listed in order of decreasing utility, and increasing effort.

0. Notify me that I need to schedule pickup for available holds. Some UX in the app links to the OPAC pickup scheduler URL.

1. Notify the staff that I have arrived for pickup. This would be a button in the app instead of the form login via the mobile browser. The arrival UX could present an interstitial with per-location arrival instructions.

2. List my pickup appointment(s), and possibly add them to my calendar. Of course the email action trigger could include enough information to allow the mail app to do it.

3. Request a new pickup appointment. This UX could be globally visible based on the org setting, and enabled if the patron has any available holds. The UX could be triggered from the Holds interface, or by deep linking from a push notification or the email sent by the action trigger.

OSRF INTERFACE OUTLINE

Rough sketch of the interfaces I think might be required to support the above use cases.

0. Notify me I need to schedule pickup. No OSRF interface is required, but the OPAC URL would need to be predictable.

1. Arrival

    API: actor.curbside.arrive
    Parameters: auth_token, user_id, vehicle_description

2. List Appointments

    API: actor.curbside.appointments.retrieve
    Parameters: auth_token, user_id

3. Request Appointments

    This seems like a lot of work for diminishing returns so this outline is rough.

    APIs: actor.curbside.appointments.list_available
                actor.curbside.appointments.reserve