TCNJ Online Campus Event Calendar

Category: TCNJ,Tech,webdev
MTW @ 11:14 pm on December 30, 2010

I’ve been grumbling about my alma mater‘s campus events calendar since I was a freshman (5 years ago), and nothing has improved since then.  My major gripes include its slowness, unreliability, the fact that you’re not able to easily link to a specific page, and how long it actually takes to get something posted on it.

TCNJ Campus Events Calendar

I recently had some spare time, so I figured I’d take a look and see if I could figure out what the main causes were for the slowness.


Major Issue: AJAX Insanity

In an AJAX application, you’d think it’d make sense to make requests for the information needed to display to a user, and only transport the data needed.  Actually that’s pretty much the point of AJAX – being able to transport only the data needed asynchronously.

So in an AJAX calendar application, if we’re going to load a “day” page and display all events for that day, you’d think we’d make a request to a service with the parameters needed… (e.g. service.json?yr=2010&mo=12&day=30) and get back a response with a list of the events in that day, like…

    "title": "Interest Session for ACM",
    "description": "This is an interest session for blah blah blah blah.",
    "author": "",
    ... etc ...
    "title": "Another event on the same day",
    ... etc ...

A response in this format for even a busy day (with a bunch of events) would be a few KB, tops.

Yeah… I guess that would make too much sense.

Actually watching the AJAX requests fly by quickly revealed what was going on, and why this app is so slow. It requests a 1MB XML file containing every event listed on the calendar. Even worse, it requests this every time you click a link to switch days/weeks/months, etc.

1 Request for each link you click

So want to check on each day in a week to see what’s going on? 7MB. Want to check each day in a month? 30MB. Even if every day you check has no events to show.

Instead of a ~1 KB request when you click on a link to view a day, a ~1 MB is being transferred. That’s about 1000x less efficient than it could be. I can’t even imagine what this was like with a dial-up connection.

Each request is huge (~1MB), and takes awhile (a few seconds)

This answers the question of why bandwidth on campus is so dismal.

Major Issue: Broken in Google Chrome

Try clicking on the days using Google Chrome in the current live calendar. It doesn’t work.

Considering Google Chrome usage is up to 20%, I’d consider this a major issue. The calendar currently doesn’t work for 1 out of every 5 people that tries to use it.

Minor Issue: Visual Feedback during loading.

If you’re going to have requests that take that long, you should at least provide the user with some visual feedback that something’s happening in the background. The current application doesn’t do anything to that effect.

Enough Complaining… Why Don’t YOU Fix It?

Fine. Here.


  • Reduces the requests down to a single request instead of once every time a link is clicked. This makes switching between views, days, weeks, and months much faster, and reduces bandwidth usage by a huge margin.
  • Fixed! Only one request for data per page load instead of per link click

  • Works in Google Chrome
  • Adds a spinner as the page loads to let the user know something is happening

Anyway, these are some quick fixes (only ~20 lines of code, total) that had a huge effect on the overall performance and usability of the app. There’s plenty more that could be done (a complete re-write using a framework like Prototype, for instance), but hopefully they’ll give this app at least enough attention to fix the things I mentioned at some point in the near future.

Update 1/1/2011: Added a permalink feature so that you can actually link to day/month/event pages. (linking to a week view makes the browser crash for some reason… looking into that.)

  • proofreading tips

    I was searching for this calendar! Thanks a lot for sharing

blog comments powered by Disqus