introducing hatch.
hatch. is a course scheduling platform for Rice students to endlessly mix and match courses on a hypothetical schedule, following in the footsteps of the beloved SchedulePlanner application that was shuttered late last year.
the need for a better scheduler
At the end of last fall, our longtime course planning tool, SchedulePlanner, was shut down for all students after the university moved to the scheduling tool in Esther (we’ll call it the EstherPlanner for clarity). At first, it might seem as though this was an improvement, and that students would have no reason to wistfully look back on an old, outdated system (it was written in .NET) when a new, shiny replacement arrived instead.
However, the EstherPlanner has three primary flaws.
First, it lacks the ability for students to maintain a long list of courses that they can selectively choose and compare between according to their needs. This would allow them to create a number of permutations with their schedule and then choose the one that best suits them. This is incredibly important due to the fact that students do not always get their initial set of desired courses following the matching algorithm that our university uses for course registration. Students loved SchedulePlanner for its ability to help them view multiple possibilities at once, save them all for later, and then revisit them as needed. Oftentimes this meant that a student’s schedule on SchedulePlanner would have 30+ credit hours at any given time, a capability that is unfortunately not supported on EstherPlanner.
The old SchedulePlanner was also available during the 5-day gap between the student submission of their draft schedules and the day in which our “Add/Drop” period began. Unfortunately, since the EstherPlanner is tied to the official registration system, it is inaccessible during this crucial time period in which students need to determine which classes they will try to “add” in order to replace the courses they did not receive from the matching algorithm.
The final limitation of the EstherPlanner is the tedious number of steps it takes to actually reach the scheduling tool. Simply put, the bundling of the scheduling tool within the broader education software of Esther brings unnecessary friction to the process of scheduling. It takes quite a few clicks to reach the EstherPlanner, not to mention the absence of a “keep me logged in” feature and the 2-Factor Authentication necessary for logging into Esther in the first place. In the past, students would often visit SchedulePlanner for a brief moment, almost like a notepad, to quickly test how a course they heard about would fit into their planned schedule. Thus, it is clear that the EstherPlanner does not address this need.
It should be noted that the EstherPlanner has attempted to rectify the first two issues through another tool it offers, called the “Plan Ahead” feature. In it, students can add more than 18 credit hours, as well as access it prior to the “Add/Drop” period. However, the “Plan Ahead” feature faces a massive flaw in its search functionality — its poor pagination makes course discovery tedious, but even worse is the fact that “Plan Ahead” displays courses that are not actually offered during the current term. This makes further hinders the process of course discovery, which is one of the primary use cases of a schedule planning tool in the first place. Between these issues with the search component and the tedious number of steps it takes to reach the “Plan Ahead” tool, it remains clear that the scheduling tools on Esther do not meet the needs of the students.
In order to address these problems, we began the development of a solution last fall.
our solution: hatch.
Currently, the hatch. schedule view supports adding and removing courses to a personal schedule after searching by department, toggling the visibility of courses in your personal schedule, links to the course page and evaluations in Esther (must be logged in on Esther to use this feature), and of course, the classic Calendar Week view that displays selected courses.
Additionally, one of our top priorities with hatch. is to provide a secure authentication and authorization system for students. We used Rice IDP to ensure that only Rice students can access our system (no one else really needs to anyway), and through a token-based authentication system (JWT) we are able to ensure that a user is the only one that can see their schedule.
We also emphasized the user experience throughout our development of hatch. Adding and removing courses is incredibly smooth, and there’s no need to manually save the course schedule you create.
team
hatch. was developed by a strong team of developers ranging from freshmen to juniors. The team was led by Will Mundy and Jamie Tan, with David Torres-Ramos (Sophomore), Manan Bajaj (Freshman), Max Bowman (Freshman), Peter Wang (Freshman), and Skylar Neundorff (Junior) serving as developers. The team was also assisted by two MBA students, Mayank Kochar and Thomas Santos, as PMs that worked on user scoping, roadmapping, and more.
moving forward
So what’s next for hatch.?
Currently, we plan on improving our search functionality beyond the simple search by department. Through our closed beta, we’ve come to understand that two much desired features are the ability to search by distribution and the ability to search by start and end time of courses. Thus, we’ve added these two capabilities to the top of our current priorities beyond launch.
From a user experience perspective, we plan on optimizing the loading speed — the slowest part of our application is when the schedule page is first loaded. While we installed a loading screen to stall the user (with a visually-pleasing spinner) until the data has loaded, we believe that we can minimize the initial load time through caching and provide a more optimal experience for the user.
We’ve also included a feedback form at the top of our application so that users can anonymously submit feedback and proposals for improvement on our application — we can then use this information to guide and prioritize our next features.
We’re also looking to incorporate event tracking, so that we can collect anonymized data on how our users utilize our application — this will not only inform future development, but also be useful for other data science applications that could be done in conjunction with the Data Science Club. For example, if we find that many students are adding a course with just one section of 30 seats, we can pass this information to the registrar to prompt the addition of more sections, or the development of an alternative course. These kinds of insights will be useful to the student body as a whole, and through our system, we don’t have to compromise on user privacy.
Finally, we’d like to explore other deployment options beyond our current solution, Google Cloud. While Google App Engine has served our purposes well so far, and hopefully will continue to do so in the coming weeks, we’d like to setup a deployment pipeline using our source control on Github. We’ve found that Google Cloud may not be the best solution moving forward for this kind of pipeline, and thus we will explore other options, such as Azure and AWS, to see what will work best.
fin.
Thank you for reading, and feel free to reach out if you want to learn more about hatch. or have any questions!
