AggieExplorer

Winter/Spring 21 Spark Project

CodeLab UC Davis
7 min readJun 21, 2021

Introduction

The goal of our project was to develop a full-stack web application that displays UC Davis course information and relevant statistics. This is a tool that our fellow Aggies will be able to utilize in order to help decide their future classes. As such, the statistics that are included are class grade distribution and current class enrollment.

The Team

Minh-Tu Nguyen — Project Manager
Ke Lin — Designer
Kiran Poonia — Designer
Salma Hassan — Developer
Elizabeth Hopkins — Developer
Hyuk Jung — Developer
Prabhdeep Kainth — Developer

Timeframe

Jan-May 2021 | 16 weeks

Tools

  • Figma
  • ReactJS
  • Node
  • MongoDB
  • GraphQL
  • Bootstrap
  • Python Web Scraping
  • Python Excel Scraping

The Project

View the completed project here: https://www.aggieexplorer.com/

Design

Overview

AggieExplorer provides UCD students with grade distributions and enrollment probabilities so they can see their chances of getting into a particular class.

UC Davis currently does not have a website that allows them to view enrollment/grade statistics of a class. The objective is to create a website where students can search for a course and see the following information: course name, GE tags, CRN, course time, unit #, instructor name, as well as how many people are enrolled/how many people have enrolled on a specific day since registration has been open for.

Users

UC Davis students who want to make an informed decision during class registration but are struggling with the lack of available course information.

Process

Our design process while creating Aggie Explorer included 4 main phases: ideation, research, design, and analysis. Since design is an iterative process, we jumped around these phases throughout the length of the project.

In our ideation phase, we created personas, storyboards, and brainstormed what the interface could look like. While brainstorming, we created the initial wireframes which helped us identify the necessary features within the site. Storyboarding allowed us to assess ways in which AggieExplorer would be used as well as in what context. Personas, on the other hand, helped us imagine the experience of different students at UC Davis (Freshman vs. Transfer). This allowed us to create a design that was accessible to all students.

Our research phase included 2 parts. In our first research phase we conducted an initial exploration of sites such as schedule builder and Berkeley Time. This allowed us to identify common themes. We also conducted interviews with 3 UC Berkeley students to get their thoughts on Berkeley Time and what features they use. This concluded two pain points which were students worrying about not getting into certain classes and them being curious about the grading scale of a class and having no way to find out.

Our design consisted of low-fidelity, high-fidelity, and interactive prototype. Some of the constraints we had during the process included not being able to add certain features like an instructor’s Rate My Professor link, class times, number of seats in the current enrollment period and class calendar due to resource limitations and time constraints of the coding period.

After finishing up the design, we conducted user testing of interviews with 3 UC Davis students and asked them the following questions:

  1. What are your thoughts on finding classes to take for the next school term?
  2. What factors determine the classes you register for?
  3. What do you think will make your process of choosing classes easier?

We also had 4 students do a walk-through of the interactive prototype to complete tasks to test the user flow. The goal is to find the grade distribution of the class DES111. The students concluded that everything was clear and easy to navigate through.

What worked throughout the project was the UC Davis color palette we used to give it a central theme similar to our school’s. Establishing our mission and goals of the waitlist tool on the home page of the website also helped give the users an idea of what they can expect on the site.

We found that users were more comfortable with using features similar to the Schedule Builder tool because they are familiar with how it worked so employing a similar feel and diction was a good idea. Our final colors are also made accessible to groups with different kinds of colorblindness, especially in the color coded statistics.

Development

Collecting the Data

The first stage of the development involved collecting course metrics from various sources. We used a Python web scraper to collect information on courses (number of seats available, GE attributes, number of units etc.) through the school’s course search tool. Then we reorganized the data for past grades given in each class to fit with requirements for graphing and storage in a database. Lastly, we stored these course metrics into a MongoDB collection for retrieval so that the website has access to this information upon request.

Retrieving the Data

Stage two of development revolved around connecting our backend and the database to the frontend. In order to retrieve the data from the database, we utilized API requests. These requests allowed us to access the class data information and display it on our webpage. The next step focused on how we should display the data. Through a table format, we placed each individual class as a card, providing only the basic information on the face of the card and having the rest of the information be displayed when the card is clicked. The last component of stage two was the search and filter requirement. With the Mongo Database Query, users will be able to search and filter for specific classes based on what information they input into our search fields.

Implementing the Front End Design

The third stage of development was focusing on creating the front end of the website and creating the components that the user can actually interact with. This stage was broken up into three major parts: creating the general pages, making a class catalog, and displaying our data. The first part was creating the pages, more specifically the home page, which describes what AggieExplorer does, and the about page, which gives the user information about CodeLab and who worked on the project. An important aspect of this step was looking at the wireframe that the design team gave us and making sure that what we were coding matched their vision for the site. The next part was making the class catalog. The class catalog allows the user to search through all of the classes and displays the information clearly. Since this was the major component of the functionality of our website, it took a while to get it right. Finally, we worked on displaying the data and graphs. We used node modules to chart our enrollment and grade distribution data we had to make it easy to understand for the user.

Site Demo

Takeaways & Challenges

Communication

As a team, this project mimicked one that is typical in a current industry environment. We had many group meetings, collaboration efforts, and lots of troubleshooting in a virtual environment. Our team consisted of a Design Team, which implemented the whole design of our website, and many Developers, which worked on the backend development as well as the front end implementation of the design team’s prototype. With the pandemic nearing an end, we realized that communication was necessary now more than ever. It has been a struggle to adapt to oncoming changes, but our team did an amazing job using the most important tool of all time — communication.

Managing the Datasets

The AggieExplorer project came with its fair share of technical challenges. At its core, we strived to provide relevant class data such as grade distribution, history of available seats, and available classes. This information, however, was not available from just one source. To compile all this data, we accessed the course catalog to get all available classes (as well as keep them updated as new classes are added during registration), the universities’ course search tool to get available seating, and the grade data provided by the university. On the frontend side, we had to ensure that the site was responsive when working with a dataset in the thousands. We used the react-windowed-select library to help manage our courses and make our site feel more snappy.

Closing

As our project is now complete, we look back and realize that we learned and developed a lot of skills in the past few months. We would love to thank CodeLab for this opportunity and our mentor James as well for providing us with guidance and help whenever we needed it. We hope Davis users will utilize our website to its fullest potential and find it helpful throughout their college careers.

--

--

CodeLab UC Davis

CodeLab is a student-run software development and UX design agency at UC Davis.