Someone once said, “we should totally just stab Caesar.” Our school’s student account system, CAESAR, is the official course registration tool and is also the source of several frustrations for students. So my peers and I committed an infamy. We dared to totally take a stab at CAESAR.
Each quarter, Knight Lab encourages its student fellows to think of how best to develop skills specific to our personal interests and needs. In the past, I’ve been stuck thinking in terms of “I need to learn Python; let me do a data project.” This quarter, I adopted the reverse approach by thinking of existing problems in the community and thinking of how solutions to those problems might also help me learn the technologies I need.
And CAESAR is a real problem that my community wants to fix. It’s been at the core of hackathons like the student government’s RedesigNU last year. As it exists right now, CAESAR has a search engine that is comprehensive but not browse-friendly because the process is one-directional. For example, users are unable to press the back button without resetting the entire search, which results in juggling three different browsers just to make course selection a little less painful.
Then there are the CTECs -- the only formal documentation of what previous students thought of each class or instructor. Unfortunately, among the anonymous comments and unhelpful “he smells” notes, credibility is hard to screen for. So we instead defer to putting up screenshots of our class schedules on Facebook to get insight about classes our friends have taken as well. We also do it because we want to experience a little camaraderie of having to suffer through the same computer science requirement, and we know misery loves company.
But surely, someone’s already come up with a solution to this?
Nope. There’s been a slew of “Brutus” projects that Northwestern students have built to enhance the usability of CAESAR, like CourseDJ and Course Connect, but not one platform has captured the social aspect of choosing courses while improving the search flow (and thus browsing experience) at the same time.
When we had established our objective and proposed a solution, the learning part came naturally. Over the course of a few months, my initial (and vague) objective of learning how to interact with databases soon became two-fold, three-fold, then five. I didn’t even realize how much my skills were growing until my team and I reached a point where we could finally reflect on how close we were to having a tangible product. We had:
- Made calls to the Northwestern Course Data API to produce a JSON file using Python
- Learned how to interact with and make queries to Parse, a backend service on the cloud
- Discovered that we had somehow ideated a join table in Parse without any prior knowledge of relational databases
- Figured out how Facebook integration works using its login and graph API
- Blinged out our style factor with some SASSy CSS
- Adopted efficient frameworks and deployment tools like Middleman, Ruby on Rails, and Heroku
Amidst all the super awesome hacking/breaking/theorizing we were doing, we also learned from each other. Because my team members and I varied in terms of skill and background, we were able to grow in all aspects of bringing a product to life. Mallory got hip with the lingo of A/B testing, user interface design, and other product-orientated thinking; Ashley, the only Windows-based person in our group, learned to use Vagrant so development would be consistent across all operating systems; and Nicole and I finally, finally learned how to resolve merge conflicts. But for each and every one of these steps, everyone was either actively teaching or learning, so that involvement was consistent.
Of course, building a new empire in CAESAR’s place takes time. For now, Romaine remains beta. Lettuce hope it grows more useful over time.
(I will not apologize for the Mean Girls reference and the puns. I have no shame.)