BerkeleyQ

Inspiration

The inspiration for this stemmed from our own, and other cs students' experience with office hours. Office hours at berkeley are run through a queue based scheduler system, where one queues a ticket then is helped in the order the queue moves. Often times these wait times can be incredibly long-we've dealt with 8 hour queues ourselves in 162, and its no better for the TAs, with random swamping periods and often anger/mistreatment from struggling students. We wanted to try to find a data driven solution for this problem, and create a friendly ui website that allows students and ta's to better know how to pick and schedule their OH's, or at least understand what's going on to plan for the future and/or analyze the past.

What it does

Essentially, its a website with a frontend and backend designed to give insights on past and predict future oh statistics and behavior. The frontend is a well built friendly website allowing tas and students to search by cs class, and view oh slots for a given week through the hours of the day. The slots become color coded based on certain factors, including things like rate at which tickets are resolved, estimated wait time(s), number of tas, time spent on tickets, etc. The site also allows for looking at past data, and estimating future data based on past analysis. Graph based analysis is available as well for ease of use. The site also comes complete with other basic ui features like contacts, search bars, etc. The backend provides the functionality for all the previous mentioned features. At its core is a scraper that scrapes the oh ticket websites to collect data on the tickets, estimated wait times, etc. The backend uses the data to compile more complicated statistics and generated graphs, and uses various tech stacks like dynamo db and lambda to run triggered events to constantly pull, update, and store the data.

How we built it

A lot of this is addressed above, but we used a react chakra ui frontend with various ui elements. We used beautiful soup for the scraper in the backend, aws lambda with EventBridge to run triggered events to collect data, and dynamo db for database storage.

Challenges we ran into

There were quite a lot. One of the most interesting would actually be wifi-we couldn't work at Calhacks. We actually ended up going to a random starbucks on the 4th floor of a Macy's, and working there for like 8 hours, on the ground, chairs, wherever-truly a hacker experience. More technical challenges included a lot of design components we had to think about for the frontend, as well as the time crunch for iterationg on that or even developing a complicated frontend. Backend had a ton of constant challenges all throughout, so getting endpoints to work, backend to deploy, etc.