Improve booking Collection

[Rishabh-malhotraa]

Once the booking is confirmed by the mentor, that time slot for that mentor should be disabled so no new user can book a meeting in the same time slot.

Either Disable or completely remove the button. While you are at it also improve the contrast of the button on hover!

The edits need to be made first in how we are storing the availability data collection in the backend and then the date-picker component in the front-end.

[milanjain2208]

Hi Rishabh, I would love to work on this. I have a few questions for you:

1. Does the timeslots/sessions have to be of exactly 1 hour? Can it be more or less than one hour(example 30 min, 45 min)?

2. Does the start_hour have to be perfect 10:00 or 12:00or 23:00 etc. Can the mentor set it to something like 13:15(whenever the functionality is made for mentors to select time)

3. Currently it looks like the availability of a mentor in a particular day is recurring(meaning if a mentor is available on a monday, then he/she will be available for all the mondays for two months). Is this the intended behavior or do we need a change here as well? Because mentors may not be available for the same day/time for two different weeks.

[milanjain2208]

My current solution would be to store an array of available timeslots for each mentor where an available timeslot will be an object with start_time and end_time (unix time stamps or Date objects with GMT value). This will also solve the time conversion problem (https://github.com/Rishabh-malhotraa/Vita/issues/18). What do you think?

[Rishabh-malhotraa]

Hey Milan, all this was made in just two weeks for Microsoft's hackathon. I did not put much thought into the backend logic, but better late than never, right? :P

1. Does the timeslots/sessions have to be of exactly 1 hour? Can it be more or less than one hour(example 30 min, 45 min)?

It should either be 30 minutes, 45 minutes, or 1 hour, and the mentor would set this when specifying his/her time preferences(All this validation need to be done on the front-end while requesting timeslots from the user). Obviously, once both the mentor and mentee are in a video call, it does not really matter how long the session duration is. They can continue the session for as long as they like. But once the booking is confirmed, we would use this data to create a calendar event, send it to both the Mentor and Mentee an .ics file in the mail. Better even if both mentor and mentee have given calendar access while signup (functionality for all this need to be implemented), we should directly create an event on Google calendar using the Google Calendar API

2. Does the start_hour have to be perfect 10:00 or 12:00or 23:00 etc. Can the mentor set it to something like 13:15(whenever the functionality is made for mentors to select time)

start_hour should be a multiple of 15 12:00 12:15 12:30 12:45 should all be valid start_hours which the mentor could specify.

3. Currently it looks like the availability of a mentor in a particular day is recurring(meaning if a mentor is available on a monday, then he/she will be available for all the mondays for two months). Is this the intended behavior or do we need a change here as well? Because mentors may not be available for the same day/time for two different weeks.

Yes, I would like this to be recurring just like Calendly, I don't want the person to constantly update his timetable, it should ideally be done once and could be edited by the mentor if that time slot does not make sense anymore. Additionally, whenever a mentee requests a 1-1 session, the mentor would always have the option to propose a new time slot, if the time does not make sense.

Few more improvements I would like to make

• I would also like to add functionality to limit the number of sessions per day. For example, if the mentor has specified only 1 session per day, after a confirmed booking, we should show that entire day as unavailable.
• Make a given timeslot as unavailable once it has been booked.
• If the mentor has given calendar access, we should automatically block certain additional time slots, if he has an event scheduled during that time.
• There should be some extra validation to sanitize the inputs, like start_time should be always before the end_time.
• The difference between the start_time and end_time should never exceed 24 hours.
• Handling the edge case when converting the time to a different time zone would split available time slots into two days, for example, if a mentor is in the USA west coast, and has available time slots from 10:00 - 14:00, converting that to IST would split this into two different days DAY 1 -> 22:00 - 24:00 Day 2 -> 0:00 - 2:00

These are some which I can think of at the top of my mind, do let me know if you can think of some other edge cases.

[Rishabh-malhotraa]

My current solution would be to store an array of available timeslots for each mentor where an available timeslot will be an object with start_time and end_time (unix time stamps or Date objects with GMT value). This will also solve the time conversion problem (#18). What do you think?

Epoch time does not make sense since we are storing available time slots based on Day of the week, but I need to do some more research on this, maybe shifting axis to week 1 of epoch work, but I am not sure?

{
  "Monday": [
    {
      "start_time":  Date(),
      "end_time": Date()
    }
  ]
}

One of the flaws of this method would be converting time slots in different time zones would be a pain in the neck because a Monday timeslot for one timezone could be a Tuesday timeslot for another.

I will love to know if there is a more efficient data structure that fits our use case better.

Maybe not store segment available time slots as by days, but just store them in an array, in a normalized way. I would love to know your inputs.

[milanjain2208]

Hi Rishabh, Sorry for the late reply. Yes, I agree with you. We can simple store timeslots in an array in normalized way instead of doing it by days. So something like this ->

{
  ... 
  "time_slots": [
    {
      "start_time":  Date(),
      "end_time": Date()
    } ,
    {
       "start_time":  Date(),
       "end_time": Date()
    }
  ]
}

Here Date can be an epoch as well. What do you say?

[hazemessam]

Please add GSSoC'22 label to it and assigned it to me