Class waitlist feature implementation

Hi all, not sure if anyone has thought about this before or even implemented before - a waitlist feature for classes.

For eg. a yoga class at a studio that has a maximum capacity of 10 students. Once 10 users have booked the class, enable an “add to waitlist” function, which adds any subsequent users to a waitlist. Each user in the waitlist would have a “queue number”. ie. First user that joins the waitlist will be #1, second user #2, third user #3 and so on. When a student enrolled in the class cancels, the user who is #1 on the waitlist will be added to the class automatically. Also, #2 and #3 will move up the waitlist, becoming #1 and #2 on the waitlist respectively.

Although it sounds like a very simple feature, I’m confused on how to set up the logic and actions. I imagine I’ll need to create another collection called “waitlist” that has a 1-to-1 relationship with the classes, and a many-to-many relationship between the users (ie. 1 user can waitlist for multiple classes, and each waitlist can have multiple users).

The biggest question is… How do I set up the actions (I’m open to creating custom actions that uses Adalo’s API to execute multiple changes at one go) to move users up the waitlist and add them into the class in sequence?

I can set up an action that executes when a user enrolled in a class cancels - when user cancels class, remove user from the class and add a user from the waitlist to the class. But how to make sure that action adds the user who is #1 on the waitlist?

The other problem is when there are more than 2 users in the waitlist. For eg. 5 waitlisted users, and #3 in the waitlist remvoes herself. How to make sure ONLY #4 and #5 moves up the waitlist while #1 and #2 stays put? I could add “waitlist queue numbers” to each user, but as far as I know, you can only change 1 record per action.

EDIT: I thought about sorting by timestamp, which is a reliable way to decide each user’s queue number in the waitlist. The question is: how to sort the collection records by timestamp + choose to edit the earliest record that was added to the collection?

I’m open to paying anyone with any ideas of how to implement this as it’d be a very important feature when our physical studio opens in May (yay!). We’ve been only running online classes, and a waitlist was never an issue since online classes are not restricted to physical capacity.

Thank you in advance for any ideas/help!

Hi @vancewong ,

I help you build cloneable app, just hang on and wait.

Hi Vance,

I’m sure @Yongki will provide a cloneable version, but for reference, I would create a Waitlist collection with class and user. When you’re on the admin side of the app, click through the class to see the waitlist (filtered by the current class) and sort by created date (that’ll be first come first serve).

You can have a button on the list (I’d use a custom list) “add to class” that when you click it, it deletes the waitlist entry and adds the user to the class.

Should be pretty fast & easy to implement.

Erik

@Yongki thank you! I’m excited to see how you implement it :grinning_face_with_smiling_eyes:

Hey @Erik, I’m thinking of an automated way to do this instead of having the instructors or admins to do it manually. We intend to have at least 5-6 classes per weekday and maybe even more on weekends. Having someone to manually add users to the class isn’t scalable.

Also, if an enrolled student cancels the class and a slot opens up, if the instructor/admin doesn’t add the user who is #1 on the waitlist into the class before another user books (since now the class has a vacancy), we’ll have another problem.

Hope that makes sense, and thank you for your inputs!

Hi @vancewong ,

Okay, lets see what we come up with.

Please do baby steps, understand first then move to other issues, don’t jump, because it will have negative impact.

If you come to this forum, it means you are prepared to learn and wants to know what is the logic behind it.

Sure, someone else can do this and that, but you are the owner of the app, you need to know everything.

I suggest to delete all records in class booking collection and reset the counter in class collection.

You can delete users collection too if you want it, or just follow along my naming convention for users.

There will be bugs or missed interpretation, but the goal is to know what the bugs are and the workaround or solution of it and clarify the missed interpretations.

Adalo is a great learning tool for database setup.

1 Like

Hey @Yongki thanks for this.

But I’m quite confused… I understand the idea behind how you structured it, but it’s missing a few key things:

  1. When someone enrolled in the class cancels, the first person in the waitlist will be automatically enrolled into the class.
  2. Next is the “queue number” for each user in the waitlist, because we’ll want to display that on the user’s bookings page (eg. you’re 4th on the waitlist). Or at least some way to tell how many people are ahead in the queue. I imagine this can be achieved based on the time the user entered the waitlist, but I’m not sure how to set the logic up.

Hope that makes sense? Thank you for your help :slight_smile:

Hi everyone,

@vancewong another version for you to have a look at: Adalo quick experiments: classes and waitlists - YouTube

Here I decided to avoid using timers & mass updates :slight_smile:

Best regards, Victor.

1 Like

Okay, round #2.

I just look up your name in this forum, wow, you are my senior, so sorry, I thought you are new to this forum.

Then, you can jump all you want.

Again, hang tight, more will come.

1 Like

Hey @Victor, thank you so much! Although your suggestion is mainly for admins to add and remove users, but this gave me an idea :slight_smile:

  • When user count >= class capacity, book button will add the logged in user to the waitlist instead of the class list
  • When a user who is already in the class list cancels her/his attendance… if waitlist user count > 0, remove the logged in user and add the current user (only possible with your idea!)
  • Instead of displaying a generic cancel button, which will only have the current schedule and logged in user data, I can use a list of users in the waitlist, sorted by oldest created date, limited to only 1 record. So when the logged in user cancels, it’d add the oldest current user in the waitlist (based on created date)

For the queue number, I’m guessing it can be a formula that counts the number users that were created in the waitlist before the logged in user plus 1. Eg. If 3 users were created before the logged in user, the queue number is 4. If the logged in user is the first user, the queue number is 1.

Hope this makes sense and is possible! Thank you so much for the video :grinning_face_with_smiling_eyes:

Hey @Yongki, I don’t think “seniority” counts here :joy: But yea, I’m not new to this forum haha. Just a little inactive because of a full-time job. Maintaining the yoga booking app is my hobby and favour to a friend (and yoga instructor).

Thank you for your kind offer to help and even sharing the cloneable app, it means a lot and I appreciate it :slight_smile:

Hi @vancewong,

Small comment reg. my video - it’s not for admins only. You can easily implement the same logic for a user-client (who decides to skip the class) - when he/she goes to Class screen, upon pressing the button “Skip” you have the modal with the same logic.

Glad I could help :slight_smile:

Best regards, Victor.

1 Like

Hey @Victor, yes! That’s exactly what I’m going to do for the user-clients. It’s only possible by using a list of user-clients in the waitlist (if there is any) instead of a standalone button with no current data attached to it. If there is no one in the waitlist, the list will be replaced with the usual standalone button to remove the logged-in user-client from the class list.

Your idea and train of thought were really brilliant, thank you so much :wink: Couldn’t have done it without you

1 Like

Hi @vancewong ,

You can try clone that again.

In my test environment, it works.

Couple of things that hold me back,

  1. custom list now behave a little different that I used to do with countdown, but I don’t have proof how different, it used to be easy to just renumber the whole batch of records, now it gives me a few random iteration
    I try workaround this renumber with app setting, it doesn’t work, with users collection temporary variable, it doesn’t work, with temporary collection, still doesn’t work either. It used to work without workaround.
    So, I change the technique to just decrease the queue number.
    Beware of the same name in context menu, it needs more experiments, that’s why context menu needs an upgrade, but who we are that asking so many features…hahaha :grinning:

  2. in preview environment, I still can’t eliminate cache of custom list (waitlist confirmation screen) from previous show, it disturbs the input field in change input value, if we push the button twice, the cache of custom list has gone, then it works normal.
    For this behaviour, I didn’t pay attention if something has changed from my previous encounter with this kind of use-case.

The screens are messy, the logics are still messy too, because I got lost numerous of times, unlike other’s people assumption that I can do it easy and fast, I did this in very slow and have many delays, not to mention when we do workarounds, it is still not working, my head burns… :grinning:

But if we keep doing it, there is a light in the end of tunnel, it will guide us eventually, well that light could be the brain recover itself, because it avoid us for going insane by doing the same things over and over again, so I might believe we have second brain that will only work if we persist, this second brain will save us by helping our persistence. :grinning: (just talking nonsense, after intense building)

1 Like

Hi @vancewong ,

I made new clone, this time with little cosmetic and few bug fixings.

Here is before cancel,

Here is after cancel,

The process of cancel,
Screen Recording 2021-04-03 at 9.56.31 AM

Let me know if you still have questions, or you have found bugs or I misinterpret yours.

I believe you are more knowledeable which cosmetics perform well or which ones making slow to the real app.

Hey @Yongki, thanks for putting so much effort into this :joy: I’m actually in the midst of building it based on your ideas as well as Victor’s. I’ll share more when I’ve successfully implemented it.

I like your gibberish talk, building an app and thinking of the logic to make seemingly simple functions work can really burn our brains :grinning_face_with_smiling_eyes: Fortunately, I have Yoga and meditation to help with clearing my mind before continuing :slight_smile:

Thank you!

1 Like

Yeah, we need all the help we can get. :grinning:

Happy building.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.