AggieExplorer
Winter/Spring 22 Upkeep Project
Introduction
AggieExplorer is a web tool designed and developed to provide grading distributions and enrollment statistics for UC Davis students. The purpose of this project was to develop a full-stack application so that students can make better-informed decisions before signing up for classes.
The Team
Prabhdeep Kainth (Project Manager)
Pooja Deshmukh (Designer)
Giovanna Briano (Designer)
Robert Au (Developer)
Derek Ma (Developer)
Ibrahim Rizk (Developer)
Sreeram Sandrapati (Developer)
Timeframe
Jan –May 2021 | 15 weeks
Tools
Figma
Node JS
React JS
Tailwind
Google OAuth
Pandas
MongoDB
The Project
View the live website at https://www.aggieexplorer.com/
Design
Overview
AggieExplorer is a platform where students at UC Davis can access grade and enrollment statistics for classes from prior terms.
A key point of emphasis in the design process was to enhance the user experience with the dashboard while at the same time redesigning the existing interface. Overall, we wanted the site to encompass more interactive, student-friendly features and have a defined aesthetic to reflect the Aggie culture of UC Davis.
Initial Research
We employed a few key strategies including
- Competitive Analysis
- SWOT Analysis
- Personas
- User Surveys
From our research, we concluded that
- The site doesn’t have enough interactive features
- Users want resources comparable to Oasis or ScheduleBuilder
- We should include personalized elements
Low-fidelity
Based on our extensive research, we drafted various sketches that aimed to solve key user pain while focusing on the primary goal of this project- to design a user dashboard!
Mid-fidelity
The mid-fidelity wireframes were created on Figma after several iterations of the low-fidelity designs. We experimented with a variety of calendar layouts to make the Schedule page more accessible and modern. When we presented our version of the calendar to the developers, we asked them for their input. As a group, we decided that a standard calendar would be the best option because it is a design most people are familiar with.
At this stage, we also began to experiment with different graphs because we wanted to allow the user to see both the class and graph at the same time. We decided to go with the horizontal bar graph for the high-fidelity because it fits the page. The horizontal bar graph also allows the user to look at multiple sets of data at the same time. The reason we decided to not proceed with the doughnut chart was because it doesn’t present multiple sets of data efficiently. If we wanted a user to see multiple class statistics, each class would need to have its own doughnut chart. Our goal for the website was to allow users to efficiently and effectively find the information they are looking for in a timely manner.
After our mid-fidelity wireframes, we conducted another round of user testing. Five participants from CodeLab were tasked with completing four tasks. The general participant consensus was
- The purpose of the profile page is confusing
- Execution of layout is incohesive
- ‘Your Planner’ section is misleading
High Fidelity
Our final design is an amalgamation of drafts over a 15-week design process. From user research to user testing, this high-fidelity design puts UC Davis students at the forefront with its interface and usability. The three main features in the user dashboard of AggieExplorer are the “Profile,” “Your Schedule,” and “Saved Statistics” pages. Each page caters to the users' need for personalization and flexibility.
Landing Page Redesign
Profile
- Save student information
Your Schedule
- Emulates popular UC Davis student planner, Schedule Builder
- Allows user to view classes for upcoming quarters and curate a potential schedule
Saved Statistics
- Save statistics for past classes
- View, compare, and assess multiple statistics
Development
Google Oauth Implementation
An important part of the project this term was the implementation of a custom user dashboard with Google Authentication enabled. To implement the Google authentication library, we used the Google OAuth React library to authenticate the users. This process would generate a unique token, which we would use with the user’s email to authenticate the users on our backend and retrieve any previously saved data. Whenever the user would make a new request or update their info, we use the same id to make those queries.
Backend Improvements
One major improvement implemented in this term was making the page load times on the enrollment page much faster. Before changes, the enrollment page would query the entire Mongo database when the user loaded the page. Because we would request over 100 data points for each class (enrollment seats for each day), our response time would be an average of almost 24 seconds.
We decided to tackle this problem by splitting the big database into two smaller ones. Since we did not need the seat data for each class as soon as the page was loaded, we decided to separate the seat data into its own database and kept the rest of the information about the class in a separate database (see picture above). This cut down the response time to about 7 seconds on average, which was a 71% improvement.
Calendar implementation
A key feature added this term was a calendar page where users that are logged in can view their class and final schedules. Implementing this took a couple of steps. The first step was to write a Python script that scraped the class timings off the web from the course search website. Once we had the timings, we added that information to each class’s entry in the Enrollment Information Mongo database. The next step was to build out the front end. We decided to use the React Scheduler Library to do this. The library offered a wide selection of features such as displaying data in different views such as day, week, and month. It also offered components that were composable and extendable. Once we had the front end set up, we simply had to populate the fields using the timings information we had just stored in the database.
Reflection
Challenges
One of the biggest hurdles the developers had to overcome was the authentication portion of the Google sign-on. Since our MongoDB database was configured to run on Google Cloud and not AWS, we could not take advantage of the AWS integration with MongoDB and Google. This meant we had to find another way to verify users’ identities. We ultimately used the client id and the user’s email to match them within the database.
Working on an already established project with new developers presented its own challenges. With different coding styles and newer technologies, our developers sometimes found it difficult to implement their own changes.
Takeaways
With a two-quarter time limit and a big list of planned changes, as a team, we had to prioritize what changes we would implement. Ultimately, we found it more efficient to improve on existing features first and then move on to building new ones from scratch. We also made it a focus to take into consideration responsiveness when designing our backend infrastructure.
