Zoom Lecture Matchmaking

Home Page of web portal
Profile form on web portal
List of students in web portal
Postgres CloudSQL dashboard
GCP Dashboard

Inspiration

We wanted to recreate the feeling of meeting new people in lectures, so we decided to develop a plugin for Zoom to simulate it. This is based not only on issues we have directly faced but also commentary from mentors and professors who have profusely voiced the need for a more collaborative and holistic toolkit built directly into Zoom as opposed to using up to three/four different services for a different lecture.

What it does

This plugin enables professors to group students according to different preferences that they input on the plugin’s website. These include skill-based, social-based, pre-made, and random matchmaking. Once the data is input on the website, the information is processed by algorithms that analyze the student data and group them based on their individual skills/interests. It also provides an easy way for professors and students to view the other student details for all of their classes to ensure easy access to communication. In addition, it displays the results of the questions asked by the professor on Zoom. These features tackle the problem of collaboration in Zoom-based education as it can be very hard for students to meet other people and form study groups with other students that are similar to them.

How we built it

Backend: We ran a Flask server as our web backend that connected to a PostgreSQL instance on GCP. When updates are made and submitted in the UI, POST requests are made to an endpoint that are retrieved by the Flask backend to accordingly update and insert data into the database. In the reverse order, the UI is populated by retrieving data after the Flask server pulls data from the database and adds it to a POST request to a certain endpoint.

Algorithm: We created individual scripts for each matchmaking algorithm that used NLP, linear algebra, and graph theory to match people (outlined in the Accomplishments section).

Web Portal: We used a React frontend with a Flask backend in order to connect the UI to the rest of our project. The way we communicated between the two was by sending JSON objects through HTTP requests.

Challenges we ran into

A lot of our challenges involved integration, as we had to connect a lot of moving parts, including React, Flask, a GCP App Engine server, a GCP Cloud SQL instance, our algorithm, and the Zoom API. We had to adapt our process flow after realizing that the Zoom API doesn't support dynamically creating breakout rooms. Configuring GCP to allow the connections we wanted it to was challenging and took quite a bit of work and time. GCP takes about 15 minutes to deploy, so we had to configure a proxy to allow quick local testing and development The Zoom API also heavily restricts features during live meetings which forced us to incorporate workarounds to the grunt of our logic.

Accomplishments that we're proud of

We are most proud of our matchmaking algorithms.

In order to match people according to their interests and social personality, we created our own algorithm that uses NLP word embeddings and vectorized profile information (major, year, learning style, personality style, etc) to measure the similarity of students using cosine similarity. We represented every student in a zoom meeting using a graph, where each node is a student and the distance of each edge is their similarity score. We then took a subgraph of the nearest 20% of students (most similar to each other), and randomly selected two students to pair together.

For skill-based tutoring matching, we ranked all students according to their performance on in-class questions (which we collect during the use of our platform), split the rank into the number of groups we would like to make, and then matched each relatively high-performing student from each split section of the ranked students to ensure that each student is matched with either someone they can help or someone who can help them. This also prevents excessive skill gaps between students to prevent one from overpowering another.

We are also equally proud of the amount of effort we put into making our system production-ready. Instead of relying on localhost, we decided to deploy a GCP instance with load balancing and containerization of its different components to create a production deployment that can be used by anyone at UIUC.

What we learned

We learned how to use OAuth 2.0, PostgreSQL, RESTful APIs, React, Google Cloud, and NLP techniques. We also realized the importance of communicating between teams to make sure the integration toward the end is relatively seamless. Finally, we learned that understanding API documentation in the beginning is important in order to understand what functionality we have, as we only saw how limited we were by the Zoom API in the late stages of the development process.

What's next for Zoom Lecture Matchmaking

Once our MVP is fully functional, we plan on developing UI elements using the Zoom API in order to minimize the reliance on our web portal. In addition, we plan on improving our skill-based tutoring matchmaking algorithm by matching students not just on their overall class performance, but on their complimentary performance in individual topics. For example, a student that performs well in topics A, B, and C, but poorly in topics D and E would be paired with a student that performs well in topic D and E, but not as well as topics A, B, and C. Finally, we feel that it is possible to expand this system into a dedicated tutoring system, using the data generated from in-class performance to match tutors to students outside of class.