4

I'm trying to squash the availability view of n-items into a single day column in an availability calendar. The use case is for reserving products. We can have n-pieces of any particular product, say bicycles, kayaks, etc. We may have two pieces of a product or three hundred pieces of it.

Because of the possibility of large amounts of reservable items of the same type, we can't use the normal 2D resource calendar (where one axis specifies the specific resource to be reserved, and the other axis specifies time). If there are 100 rows of items, it quickly becomes a chore to find a timeframe where 20 pieces of them would be available at the same time.

Before entering our reservation view, users pick how many pieces of the specific product they want. Users can reserve 0-N pieces, where N is the total amount of items we have of a specific product. After that, they're presented with a time/calendar view that has open slots for times when there is sufficient equipment available. If there is sufficient equipment available, users can reserve the items for one to eight hours.

My problem is that I don't know how I could visualize the following or similar cases:

Say we have a product. We have two pieces of this product, labeled item A and item B. Item A is reserved from 12:00 to 13.59, and item B is reserved from 14.00 to 15:59. A user wants to reserve 1 piece of item, from 12:00 to 15:59 (but we don't know this). There is technically one item free for the whole desired duration, but it's not the same item for the entire duration.

Can I somehow convey to users that it's possible to rent from 12:00 to 15:59, but he/she has to switch the item midway? Can I somehow show that if the reservations begins before 14.00, you can only reserve it to 14:00? Is there a better way of visualizing squashed availability of n-items? Should I even try to visualize it?

I could simply force all reservations to prefer item A, leaving item B free for reservation. But this would cause uneven wear in the items in the long run.

image of time tables

6
  • From the user side of things...Is it even worth it to rent a bike, then have to return it after an hour for another bike? From a service perspective, it would seem to anger customers and not be practical. See if you can get clarity from the business side; it seems like you could not even deal with that case. – Mike M Dec 31 '20 at 15:14
  • It looks like your users are selecting specifically which item they're checking out, is that correct? In other words, you can't just issue Item A to both of the existing reservations and let your new user have Item B for the entire requested duration? – maxathousand Dec 31 '20 at 15:15
  • MikeM, you're right. There isn't much sense user wise on allowing users to reserve items that force them to come back mid-reservation. That was just preliminary thinking on possible ways to solve this problem. – Konsta Dec 31 '20 at 15:56
  • @maxathousand Users aren't explicitly selecting what item they're getting. They just select the type of item they want and the number of items they want. The underlying system then assigns them specific items. You're right that it would be possible to move the second to reservation to item A to make room for longer reservations on item B. Unfortunately, that would require quite complex and heavy precalculations before any reservations are even made (How complex is the reassignment logic if there's +10 fixable conflicts?). I'm hoping we could find a simpler solution. – Konsta Dec 31 '20 at 16:00
  • It sounds like that may be the optimal solution though... That would be the most user-friendly way. After a user places or modifies a reservation, calculate what your new availability is so that the next user can immediately see what's possible for them to check out. How the algorithm is implemented would be out of scope here, unfortunately, but Software Engineering may be able to help. Or maybe there's a niche branch of Mathematics that may be interested in this problem as well. Or frame it as a "brain teaser" and sneak it into Puzzling ;) My hunch is that it's not impractical to do. – maxathousand Dec 31 '20 at 16:08
1

I would suggest to divide this issue into 2 questions that the observing user might want to get answers from this table:

  1. what is the (rate of) availability status of the product?
  2. which pieces of each product are available?

For the 1st question I would suggest assigning a percentage per product piece and show the overall product availability. for example, if the product is made up of 4 equally important pieces than I would show the overall column with a "progress bar" with 25%, 50%, 75%, or 100%. For the second option I would dedicate a column for each (labelled) product piece and an "Overall status" column that summarizes the product status (similar to my suggestion in the first question). good luck, Erez

1

@maxathousand Was right in pointing out that the optimal solution in terms of UX was to display an optimized availability of items. This would show users the best possible availability, that can't be improved any further by manual human work.

This could be done by precalculating the optimized reservation schedule, where the pre-existing reservations are squeezed to as few items as possible, maximizing the reservability of the product. Max was also right in the fact that the schedule optimization problem was not that hard to solve in the end.

However, we decided to go with a simplified solution in this particular MVP-product, where reservations track the quantity of items, not items themselves.

Thank you everybody for your help!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.