Waiting queue for meetings

[timothy.jones]

At the University of Cambridge, our Open Days are all going online. We want to recreate some of the in-person meetings that happen where potential students and their families can talk to an academic or student during specified times. The obvious option of advertising a link to a video conferencing meeting doesn’t really work for several reasons. First, if anyone can join then it could change from a small meeting between a couple of people to a large meeting between a hundred or so! Second, even if the video conferencing app provides a waiting room, there is no feedback to visitors as to where they are in the queue, and when they are likely to be seen.

The solution is to build a queue that provides this functionality. We wanted:

• The ability to make different queues that would accept visitors (e.g. one for academics, one for students, or grouped by subject)
• The ability to have multiple people answering questions (hosts) per queue
• For visitors to know where they are in the queue
• Not to have to advertise a meeting link until a visitor is about to meet someone.

This is the app I’ve developed. The screenshot below shows three visitors in various stages of queueing:

On the left is the page that visitors initially see. You choose the queue you want to join, optionally add your name and email address, then click to wait for a meeting. In the middle, whilst waiting you get information about your position in the queue, including an estimation of when your meeting will be.
Finally, once you’ve waited long enough, you get your meeting link.

The host page is very similar, but hosts must provide a name and URL for the meeting, which will be conveyed to the visitor once the meeting can begin; they can then click to meet with the next visitor.
There’s also the ability to send messages to waiting visitors, and to close the queue to new visitors too, so that people don’t keep joining after the meeting times have ended.

Once the code is finalised and tested, I’ll post a link to it for people to clone, in case anyone else has a use for it too.

[mglraimundo]

Suggestions:

• Set a cookie in the client-side with a custom timeout (1 day prolly works) so that you can recover your meeting if you leave the app.
• Alternatively, give the user a unique meeting id they can store and use that to recover their meeting interface if they login from another browser
• You can also store some unique id in the cookie and in a datatable and add a “Cancel Meeting” option that would remove the meeting from the queue
• Finally, to wrap it all together, set a timer (it’s available as a client side “advanced” component) to auto-refresh the queue estimate

[timothy.jones]

Thanks for the suggestions. Note that this app is really only designed as a waiting queue for “visitors” during the times the one-to-one meetings can actually happen — about two hours in total. The idea is that meetings would start at a specified time and the queue only opens to visitors a few minutes beforehand.

I did consider giving visitors an ID in case of problems, but decided it was too much for this specific use case. I didn’t consider cookies, but that seems like overkill for this particular situation too (I can see it being useful in other circumstances though).

The timer is implemented — visitors query the server automatically every minute (down to every 10 seconds if they are near the front of the queue). This updates the queue position but also lets them know that they can join a meeting (I couldn’t see how the server could let the visitor know that the meeting could proceed without the client querying). Hosts also ping regularly to ensure they get a good estimate of how many people are waiting.

The other benefit of the regular ping is that it allows me to filter out visitors who just disappear. If a visitor hasn’t been seen for a certain amount of time (2 minutes) then they aren’t counted as a visitor waiting, so there’s no need for a cancel button. If they suddenly appear again, they regain their relative position in the queue; essentially they aren’t penalised if their internet just drops out for a bit.

[mglraimundo]

Those are very user friendly and sensible UX decisions, a lot more happens in the background than one would infer from the screenshots. Nice!