How four girls conspired to take down CAESAR

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.

So Nicole Zhu, Mallory Busch, Ashley Wu, and I built Romaine.

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.

In the end, Romaine is not a journalism project. Python isn’t a journalism skill. Neither is using Parse, JavaScript or Facebook APIs -- until you find the right application for them. Romaine introduced us to technologies we might otherwise use in newsroom development and taught us to be aware of our audience throughout the design process.

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.)

 

About the author

Suyeon Son

Undergraduate Fellow

Latest Posts

  • Introducing StorylineJS

    Today we're excited to release a new tool for storytellers.

    StorylineJS makes it easy to tell the story behind a dataset, without the need for programming or data visualization expertise. Just upload your data to Google Sheets, add two columns, and fill in the story on the rows you want to highlight. Set a few configuration options and you have an annotated chart, ready to embed on your website. (And did we mention, it looks great on phones?) As with all of our tools, simplicity...

    Continue Reading

  • Join us in October: NU hosts the Computation + Journalism 2017 symposium

    An exciting lineup of researchers, technologists and journalists will convene in October for Computation + Journalism Symposium 2017 at Northwestern University. Register now and book your hotel rooms for the event, which will take place on Friday, Oct. 13, and Saturday, Oct. 14 in Evanston, IL. Hotel room blocks near campus are filling up fast! Speakers will include: Ashwin Ram, who heads research and development for Amazon’s Alexa artificial intelligence (AI) agent, which powers the...

    Continue Reading

  • Bringing Historical Data to Census Reporter

    A Visualization and Research Review

    An Introduction Since Census Reporter’s launch in 2014, one of our most requested features has been the option to see historic census data. Journalists of all backgrounds have asked for a simplified way to get the long-term values they need from Census Reporter, whether it’s through our data section or directly from individual profile pages. Over the past few months I’ve been working to make that a reality. With invaluable feedback from many of you,......

    Continue Reading

  • How We Brought A Chatbot To Life

    Best Practice Guide

    A chatbot creates a unique user experience with many benefits. It gives the audience an opportunity to ask questions and get to know more about your organization. It allows you to collect valuable information from the audience. It can increase interaction time on your site. Bot prototype In the spring of 2017, our Knight Lab team examined the conversational user interface of Public Good Software’s chatbot, which is a chat-widget embedded within media partner sites.......

    Continue Reading

  • Stitching 360° Video

    For the time-being, footage filmed on most 360° cameras cannot be directly edited and uploaded for viewing immediately after capture. Different cameras have different methods of outputting footage, but usually each camera lens corresponds to a separate video file. These video files must be combined using “video stitching” software on a computer or phone before the video becomes one connected, viewable video. Garmin and other companies have recently demonstrated interest in creating cameras that stitch......

    Continue Reading

  • Publishing your 360° content

    Publishing can be confusing for aspiring 360° video storytellers. The lack of public information on platform viewership makes it nearly impossible to know where you can best reach your intended viewers, or even how much time and effort to devote to the creation of VR content. Numbers are hard to come by, but were more available in the beginning of 2016. At the time, most viewers encountered 360° video on Facebook. In February 2016, Facebook......

    Continue Reading

Storytelling Tools

We build easy-to-use tools that can help you tell better stories.

View More