Inspiration
We came up with this idea keeping in mind the long queues we have to stand in, everyday. For example, when we go to a career fair, we wait for a long time before we get to meet recruiters. So we thought about bringing this queuing system online so people don't have to physically BE STANDING in the queue. In addition, we thought that all queuing systems work in a similar way like banks for example, where people wait in queues to get their queries answered. This was the inspiration of our project and we wanted to take out the annoyance caused by queuing delays in counters.
What it does
The system allows recruiters (who talk to students about job opportunities) and students (who visit recruiters and want to learn about opportunities) come together and prepare queuing schedules. For example, a recruiter from Amazon might decide that he wants to talk to 300 students today while a recruiter from another company may decide to talk to 200 students, say. Students can then book slots which allocates "tokens" to students that indicate which position in the queue a student is in, as well as provide an estimate of waiting time. Since this is a virtual system, students can stand in more than one queue at the same time.
How we built it
We planned on developing APIs that other applications can use to perform queuing-related tasks. We then planned on using REST API because of the various advantages it offers in terms of simplicity and scalability and we targeted mobile users. Since we had members skilled in a variety of areas, we used Java and C# .NET for development. We finally built a prototype for mobile browsers.
Challenges we ran into
1) Scheduling was a big problem that we ran into and we had to deal with deadlocks. 2) To make queuing fair for everyone, we direct users to be physically present whenever appropriate. 3) We needed to identify and collect required data for predicting wait times. 4) To implement all of these features, we found it incredibly difficult to come up with general APIs, so we built the application for mobile browsers and not for native apps.
Accomplishments that we're proud of
1) Scalable 2) Can be applied in any scenario where there are people standing in a line. 3) Allows for people to stand in more than one queue. A student gets to move forward in a queue virtually even though the student is physically present in another queue.
What we learned
1) How not to sleep for close to 36 hours at a stretch 2) Front-end UI frameworks such as bootstrap and back-end application development such as the .NET framework
What's next for Virtual Queue
1) Prediction of accurate wait times 2) Native mobile apps 3) APIs
Log in or sign up for Devpost to join the conversation.