The novel COVID-19 virus is devastating populations around the globe. We have felt the effects of this worldwide crisis here in LA, with the mandatory “Safer at Home” act. We, as UCLA students, have had all our classes moved online, and we know many other students worldwide can relate. Over 290 million students and youth have had their school shut down due to the virus, according to UNESCO. For many, classrooms and clubs are becoming digitized in the form of online Zoom Meetings. Students’ email inboxes have become cluttered with many Zoom Meeting invites and URLs, all of which can become difficult to organize. This is where ZoomGroups comes in. Professors shouldn't have to worry about invites and URLs, just like a real classroom; and students shouldn't have to worry about organizing a second schedule. We wanted to create a platform that would simplify classes for professors and organize meetings for students, while still being straightforward and easy-to-use. The bottom line: we wanted to make education accessible, and enhance collaboration.
What it does
When the ZoomGroups webpage loads, the user is greeted with a simple screen where they can sign in with Zoom. Once they have signed in, they are presented with a schedule of their current classes, an option to search for new classes, and an option to create a class (if they are a professor). Creating a class as a professor is as simple as inputting some basic class information. As soon as the class is created, students can see it in the search menu and join it. From there, all a student has to do to join a meeting is click on the class, and they will be redirected to the Zoom app. ZoomGroups takes care of creating Zoom Meetings and managing & sharing Zoom Meeting URLs, simplifying the use of Zoom for both students and professors.
How we built it
Back-end: We implemented an OAuth authorization flow to gain login via Zoom. We utilized Google Cloud Functions to run the majority of our business logic: from querying databases, adding new data, validating input, managing users and logins, and utilizing the Zoom API. For our database, we used Google Cloud Realtime Database. Here, we stored non-identifying user information, such as Zoom associations, along with a list of courses and their respective Zoom information, and a list of user-to-courses associations. We utilized the Zoom API in order to allow us to programmatically create Zoom Meeting URLs for our app. Thus, an instructor never has to create a Zoom Meeting; they only have to create a new course in our app, and our cloud functions automagically generate and sync the correct Zoom Meeting information. On the front-end, we used Google Cloud App Engine to create and host our web app. Pages were served up through Express.js, and our webpages were designed using Bootstrap. jQuery and various other libraries allowed us to easily communicate with the back-end services, and manipulate our DOM. We also managed and stored local cookies in order to remember user sessions.
Challenges we ran into
It was not easy working on ZoomGroups from separate locations. Much of the last 36 hours was spent video calling and screen-sharing with each other. Other challenges we faced:
- We ran into a few CORS issues when our web app was making API requests to our cloud functions. This was because the cloud functions are hosted on Firebase and have a different domain. We had some challenges fixing this issue because Firebase does not easily allow modifications to preflight headers (to enable CORS) of its cloud functions. However, we were able to implement it through a few workarounds.
- We ran into other general challenges, such as having mismatched database schemas, but were able to fix them by working together.
There were a few challenges we were unable to overcome in time for the deadline:
- Firstly, the Zoom Developer Client only allows an OAuth workflow with one Zoom account (the developer account). Thus, our web app is unable to process OAuth logins with any other Zoom account. In order to enable this, we must have our app reviewed by the Zoom team. We submitted a request, but were unable to get a response in time.
- Another challenge we were unable to fix was getting official UCLA course information for our web app. Initially, we intended to have a valid source of UCLA courses and lectures, each with their respective professor, as the available options when selecting a class to add. For example, a student would be able to see a list of all current UCLA classes, and a professor would be validated that they are teaching a current class. We tried to get course data from two sources: UCLA WebServices API, and DevX API. We were unable to use the official UCLA WebServices API, since it requires submitting a form to gain access, to which we did not get a response in time. We were able to access courses from the DevX API (api.ucladevx.com), and implemented this in our workflow, but saw it as a bottleneck, since querying for courses often took a few seconds, and was not fast enough for our web app to seem responsive. In the end, we decided to opt for allowing professors to create their own class entries rather than relying on an official course listing.
Accomplishments that we're proud of
Working on ZoomGroups meant running into challenges, and facing them together. We are proud of our ability to work together and still create lasting memories while working remotely. This project included many accomplishments for all of us. Some of these were successfully implementing the OAuth workflow to log in and authorize with Zoom, programmatically creating Zoom Meetings on behalf of professors using the Zoom API, deploying multiple cloud functions and a web app that communicate, and having a fun time while learning a lot with friends. Looking back, we are astonished by how our team was able to put this together in 36 hours. Despite the difficulties, we take great pride knowing that our product can be leveraged by so many individuals in this time of need.
What we learned
What’s next for ZoomGroups
Getting our Zoom client app reviewed would be a very important step, since it would allow using the app with multiple Zoom OAuth logons. This is also quite essential for a published app. We would also like to revisit getting an official list of UCLA classes to use. Perhaps we can look into getting access to the UCLA Classes API through UCLA WebServices. This would allow the app to be more seamless and consistent, since all lecture and discussion sections will be correctly verified. Another feature would be enhancing our "search for classes" feature to allow searching by Department, Professor, etc. This could allow users to find their classes more easily. And of course, our app still needs a lot of polish to make the user interface more accessible and clean.