Design Showcase — Crowd Control
Well, I didn’t keep my promise in my last article clearly, but if you always look to the past mistakes, you fail to fix them in the future. In my last article, I talked about how I wanted to change this publication, or rather actually start writing for it (if you haven’t checked it out you can take a look at it right here). However, I forgot to mention one thing though. As designers, we have to look at the world and see design in everything, but we should also appreciate good design, both form and function. So in order to do that, every now and again I will be writing articles about some product or design that are designed really well. For our first ever showcase, we start at a hackathon, StarterHacks. My friends (myself included) created an app to help others with a simple problem: Waiting in line. Now without further ado, let’s see what it’s all about.
Meet the team
Aside from me (if you don’t know me you can check me out here, our team consisted of 3 members, each of which had a certain specialty to make this app work.
Shivam Pandey — Student, Mathematics, University of Waterloo
Shivam is well versed in Python, which was essential to the development of this app. More importantly, he knew how to visualize the problem and logically connect all the actions we needed to take and that the user would make. He was in charge of connecting all the systems together.
Ali Zohair — Student, Mathematics, University of Waterloo
Ali is a fast learner, which meant that he could adapt to any situation that we faced. In the case of our app, we needed to store phone numbers in a database. This is where Ali shined, learning and implementing a simple Database for us to store information.
Hossein Mohebbi — Student, Computer Science, University of Waterloo
Hossein knew that this app needed to use some third party API, and learned the essentials of the Twilio API so we could handle user interfacing through MMS. He also worked on the business side by helping to develop the pitch and key graphics.
So What Exactly is Crowd Control?
Have you ever gone to a conference where you were excited to explore and learn, but ended up waiting in a long lineup before you could? Have you ever been so hungry that you would push everyone in front of you out of the way just to get a slice of pizza? You have faced one of the major problems conferences have: lineups. Lineups cause many issues for people waiting in them and people managing them. Organizers face issues such as inefficiency and safety concerns. Users end up fatigued and annoyed. Even worse is that the time you wait in lines is valuable time you could use for other activities. Now, there are a variety of solutions already on the market, but there are many problems that aren’t solved:
- Single Screen Systems — Users need to wait for a screen to show their name/number
- Cost/Weight of the system — Some systems are really nice for big conferences, but are still hard to implement due to how many components there are
- System Requirements — Some require apps which are only usable on certain operating systems, and more support increases costs
In all these issues, one key component was overlooked: We carry around a device that is connected to the internet all the time. So why not use it to wait in line. That is why we created Crowd Control. A single user interface for everyone, their texting app, could be used to wait in lines.
How does it work
The app uses 4 components. We created a dashboard in React for the front end. This was simple enough for any organizer to use, and is scalable. More importantly, the dashboard only pushes info to the API. This means more security because the data only interacts between the server and the API’s, which means less access. This brings us to the main part of the app: The Flask API. The Flask API acts sort of like a train switching station. It receives calls from the dashboard which either gets data from the SQLite database or passes information to the Twilio API. We used Axios and Flask to communicate between the front-end to create call patterns, which was easier than using Fetch because we only needed POST commands. We created a SQLite Database because it can use local storage and is lightweight, a key factor in our design. Finally, we created a separate Twilio API Handler, which communicated between the phone’s messaging app. This also helped with scalability, as we would only have to change certain variables. Relatively simple in theory, much harder in practice.
So What Happened?
During development, our whole team as on deck working on an individual component. The react front-end was made as simple as possible for the pitch. The main aspects were the back-end components. Using Twilio allowed for us to not only send messages to all types of phones, but could allow us to scale to Facebook Messenger, Whatsapp, and email. Our database selection used a single table with three columns: phone number, status (boolean) and queue. The status tells us whether a person has already been called. For the query to call a user, we would pass it the queue number, and then the number of people we want. We would then select the people where status is false and the queue number is the one we want, and we would return a list of these numbers to the Flask API and call the Twilio API to message those users. We then delete these rows from the table. The benefit of this system is that the front-end doesn’t see the numbers, and thus is more secure.
What We Learned
A lot of the development was about learning how to develop on a team. Approaching the problem from a modular standpoint allowed us to be able to target specific components without overlap. We also learned the importance of planning. By creating tracer bullets, we allowed ourselves to break out the functions into the inputs and outputs we desired. Finally, we learned time capping projects. Sometimes you can’t add a feature you want in a short amount of time. If the deadline approaches, make it presentable enough that you can get your point across, and then improve afterwards.
I hope to be doing a couple more of these when I find cool projects others have worked on or some of mine. If you like these give me a clap and I’ll keep making them.
