Open nickevansuk opened 4 years ago
Having remainingAttendeeCapacity
take into account leasing within the RPDE feed can be added as a "SHOULD" in the Open Booking API, to encourage a better user experience, or should it actually be a "MUST" to avoid UX ambiguity/variance across providers?
"For the avoidance of doubt, this must include accurate pricing and live availability information." is included in https://openactive.io/delivering-openactive, so in fact this should probably be a MUST so that the two are aligned.
On reflection this is different from the UX vs Sales argument referenced above, as in this case it is just about data accuracy.
Also for OrderProposals, the spec should clarify that an OrderProposal may not reduce the remainingAttendeeCapacity
be design, for cases where a single space is made available to multiple Customers, and the Seller can approve one and reject the others.
This is in the current spec, but its implications may not be obvious:
A Lease is not required for this flow, as in some cases Sellers may prefer to manage contention for spaces manually via the approval process instead of leasing. -- https://openactive.io/open-booking-api/EditorsDraft/#proposal-leasing
Hence any solution to this issue should also clarify OrderProposal.
The tooling has implemented the following:
The
remainingAttendeeCapacity
value in the open RPDE feeds should always include leases. This ensures data accuracy and optimises the user experience.
The spec should also clarify that the remainingAttendeeCapacity
values at C1
and C2
exclude the current lease, and that the remainingAttendeeCapacity
value at P
and B
should not be included (as they have little utility, and add additional complexity to the implementation if they are to be accurate)
Feedback
The above appears to be a contradiction, and it is also unclear whether the
remainingAttendeeCapacity
value in the open RPDE feeds should include leases or not.Clarification required
The specification logic is actually agnostic to whether or not
remainingAttendeeCapacity
in the open RPDE feed includes leases in its total. Evidently excluding leases from this figure will encourage customers to enter a booking journey with inventory that is potentially unavailable, however this also might encourage more bookings of such inventory (the same argument UX vs sales argument used when a booking system is deciding whether to support leasing in the first place).The specification should be updated to clarify that e.g.
"remainingAttendeeCapacity": 1
in the open RPDE feed does not guarantee availability for that item, as either (i) the item may be booked by another customer in the split second before a call to C1 is made or (ii) the item is actually already leased by another OrderQuote. These scenarios are functionally the same, and in both cases theremainingAttendeeCapacity
andremainingUses
, and the errors returned by C1, will clarify the situation regarding availability, especially using theOpportunityCapacityIsReservedByLeaseError
. If the booking system chooses to provide a better UX, reducing theremainingAttendeeCapacity
for leases will reduce the frequency of a user encounteringOpportunityCapacityIsReservedByLeaseError
.The specification should be further clarified to make clear that the RPDE feed may or may not include leasing in its totals, but that the
remainingAttendeeCapacity
andremainingUses
values returned from C1 and C2 MUST include the number of spaces that the user can currently select (i.e. taking into account leases, as per the spec quote above). The objective of this is to provide the user with a clear indication of the number of spaces available (the number for which they can expect a booking to succeed) taking into account those that are leased, otherwise they are forced to use a trial-and-error approach to see how many spaces are available to book at the present time. If they try to book more than the number of spaces stated as available in C1 or C2, anOpportunityCapacityIsReservedByLeaseError
will inform them that there is contention for any space that is leased (which might encourage them to try again later).The specification should be updated with a recommendation that the Broker SHOULD display the
remainingAttendeeCapacity
andremainingUses
values returned from C1 and C2 to the user in any user interface that allows amendments to the number of OrderItems for the same opportunity that are included in an OrderQuote.