What we started with was a simple solution for a calendar. You book a date and it goes unavailable after you do. However I quickly realised that our first 10 customers all wanted something way more complex.
Businesses have specific needs when it comes to time. For example we received queries such as "Can I make the customer to book 3 days at once, and make that recur every month". As a business owner I answered "of course" but as a developer my head was spinning.
We ended up reformatting our whole calendar and availability structure. Here is it broken to pieces.
The core structure
We have two things that together form our calendar solution; Submissions and event entities. Submissions hold all the submission data such as booker information, price, and other related information. Event entities hold all the time-related information.
Events need their own data entities. Every submission or booking that is done through our solution has its own "entity" which stores all the data. Initially I included the time information into that entity, but later realised that that is not scaleable. I realised there will be a need for a specialised data entity which holds the event related information.
Event entites are very simple
The goal of a data entity is to separate date information from other information, but still link it to keep it as a coherent whole. Here are the pieces of information we store in every time event.
Programmatical name - This is used to find the entity
From - To - Storing the event as a timestamp from-to
Link to submission - Link to the related submission
Notes - This allows the user to add notes to every event
Team member - While not always needed, we added a team member field you can assign a team member in charge of a certain event.
Building the UI is hard
As calendar functionality gets more and more complex, building an UI to support it is very difficult.
Calendar in a form builder and a chat builder
This turned out to be the most complex part of the whole process. This means that when the calendar is visible to the business, and you are building your form. We had such a variety of customers that we need so many different features to be supported while keeping it simple to use. The features we support are as follows:
Multiple date bookings
We needed to support booking for multiple dates. For example a person wants to book a caterer for two events at once. I built this with replicating the calendar, just setting it in an array into the json for the amount of times that the user has allowed it to be multi-booked.
Date range select
Some businesses also wanted a date-range selector, so we provide this option as a type of calendar. First click selects first date, and second click second. We did not allow time bookings with date range.
Recurring events
Recurring events are events that recur up to maximum of 6 months. Recurring time can be set weekly or monthly.
Slot lenght
We allow you to set a slot lenght per a type of booking you're managing in the form. So based on your solutions you can book for 30 and or 90minutes and see availability based on that. I wrote a blog post with a snippet about how to build timeslots for calendars in JavaScript if you're interested in a bit more information on that.
Earliest booking date
Some of our customers don't want to allow bookings for the next few days, and therefore we
Dynamic pricing
What I mean with dynamic pricing is a possibility for the user to set any day, or recurring weekday and give a numerical or percentage increase or decrease for that day. For example if the customer wants to book a Monday, they can set the price as -20 or -20%. We also allow for an external library to plugin and provide dynamic pricing based returning a value from 0 to 1.
Building this on our snippet
When I started building the front-end of the form, I came accross this step. This means what is shown to the end-user of the form. I wanted to keep things simple, meaning that there would be no external libraries in place. Someone called me crazy for that. My logic was to build all in vanilla javascript to ensure three things; full browser compatibility, knowledge of how things work and making sure we don't need to load any external libraries.
I ended up building the calendar based on a vanilla javascript calendar here: https://github.com/vanilla-calendar/vanilla-calendar. Shoutout to https://github.com/bennias for giving me a head start. Our version started from the same logic, but has now extended into its own beast. Hopefully I've time to contribute back to the starting point.
All of the logic in step 1 is possible to be browsed through this calendar. We have 3 types of main front-end's for the calendar; calendar, calendar with timepicker and range-picker.
Backend and management of events
Putting the parts together
Pulling all the parts and logic together when it was not planned from the get-go was a challenge and all together probably one of the most complex things I've built. However now I can say confidently that I've build a calendar and time management system that does not suck. This is all also based on our GDPR friendly forms so our EU customers can breath freely.
Check it out by logging in and playing around here.
If you wish to copy the work further or get some comments on your calendar logic, send me a comment or a contact form request and I am happy to help you out further.