ZotProfs

Landing Page
ICS 32A Demo
STATS 67 Demo
STATS 67 Scroll Down Demo

Inspiration

For our project, we wanted to create something meaningful that we could apply to our daily lives as students. Especially since class registration for the winter quarter is coming up in the next week, creating a good schedule is on the top of our minds. A huge part of choosing classes is deciding which professor to take it with. Therefore, we decided to come up with a way to quickly access professor rankings for a certain course. After finalizing our idea, we began by brainstorming the general functionality and actions that we wanted our program to be able to run. Based on this, we sketched a low-fidelity wireframe with the general layout and design of the ZotProfs application. At this point we split into two groups — one which worked on developing a clean UI for ZotProfs and the other worked on implementing the proper functionality. During this stage, we encountered many challenges. We were able to identify many technical challenges by conducting numerous test cases. With the help of our mentor, we removed bugs and made sure our application had the correct display. Furthermore, we ran into trouble trying to implement a few UI features that we created in our prototype into the actual application. However, we hope to improve ZotProfs by adding more functionality and implementing all of the features we wanted to. Despite these challenges, we were able to come up with a functioning and relatable web application with a simple user interface.

What it does

ZotProfs informs students of the statistically easiest professors for a particular course at UC Irvine. It uses data from the PeterPortal API to display a ranking of professors sorted by the percentage of students who passed a class or number of As with the respective professor.

How we built it

We started with the HTML and built a base for the landing page. Originally, we wanted to have two input boxes, one for the department name and one for the course number. However eventually we decided that the best course of action would be to make a dropdown menu, as the department name could be shortened down to many different names that are too many to catch and too variable to be able to narrow them down and put them into an acceptable format so that we could get data from the PeterPortal API. After implementing the landing page, we split into two teams – one that would implement the functionality behind the app and one that would design the interface for the resulting table that would display the rankings of the pass and A rates for each professor. Then, we implemented the code that would display the table with the accurate data, which posed many challenges, as the way we wanted to display the data was very different from what raw data the API provided. We needed to make calculations and juggle many values and variables in order to make sure that all the information we believed students would find most helpful would be displayed clearly and properly on the page.

Challenges we ran into

One of the main challenges we had was that when we initially created an array to represent the json objects we received, there were many array elements with the same professor because it is possible that the professor taught the same classes in different quarters and in different years. To make sure our data only contained one professor for a class, we created a JavaScript Object (dictionary/hashmap) instead of an array. If the professor from the API request is not in the dictionary, we would add the professor to the dictionary . If the professor is already in the dictionary, we would update the current value in the dictionary with the professor by appending the new values to the old values, which would solve our original problem of multiple professors being displayed for the table. Another dilemma we faced was exactly what data to display in the table. For example, we started off with 5 categories: Ranking, Professor Name, Passing Rate, A Rate, Average GPA, Term, and Year. However, after discussion, we decided that it would be more important to display the average data about a professor’s class rather than individual data for every term that the professor taught, which would’ve been both uninformative and long. Due to this, we had to change up the entire code, calculating more general averages from the raw data, and changing the table to accommodate the changes we made. Another challenge we ran into was in the css aspect of our project, where we had trouble with making sure the items of our project were displayed properly. To fix this issue, we needed to use a combination of margin and padding, as well as flex-box, to make sure items in the container were being ordered and separated properly. For the design part, some challenges include converting the elements in our hi-fidelity prototype into CSS code.

Accomplishments that we're proud of

One of the biggest accomplishments was to send a request to the PeterPortal API and successfully be able to parse the data from it. In addition, we were able to work through many errors smoothly, not giving up even when it seemed impossible to fix. This mentality led us to the end of the project and a product that we are very proud of.

What we learned

Through this hackathon, we learned more about front-end web development, as well as designing new and innovative projects. In addition, we were able to become familiar and work with HTML, JavaScript, and CSS. Learning about the different tools in CSS such as flexbox from the vanilla JS workshop and then applying these skills to our website really helped us grasp how to use flexbox to order items. Additionally, we learned the importance of using resources from online documentations to assist us to work with a new language as the answers of expressing a dictionary in JavaScript is answered in multiple resources such as Stackoverflow. Furthermore, we learned how essential console.log() was to help debug our code when using JavaScript. We were able to simulate what goes on when developing a project in industry, and gain valuable skills such as teamwork, problem-solving, etc. Communication between team members was especially important, as the designers needed to work with the developers closely in order to make a design that was both efficient, pleasing, and plausible for implementation.

What's next for ZotProfs

In the future, we could implement a darkmode in our web application. During the time, we already designed a darkmode UI and created a hi-fidelity prototype. Now that the functionality of our web application is operating, we could certainly bring about darkmode and give a better experience to users. In addition, we could add a link below the professor’s name that directs the user to that professor’s profile on “Rate my Professor”. This is to provide students with more data and statistics, and help them further round out their decisions when choosing a professor. Finally, our web application could include a graph that visualizes the grade distributions below the names of each professor, similar to the graph Zotistics provides.