Q: What do you get when you cross a kangaroo with a calendar?
A Brief History Lesson
First, the earth cooled. Then, Joel Seligman (former director of Campus Information and Visitor Relations), Chris Manly (former Nexus of All Things Cornell (TM)) and myself (former youngster) sat down in the Day Hall board room and hammered out a requirements document for the very first version of the on-line University Events Calendar.
Well. That’s not exactly true. The very first online version was a Filemaker database that had web functionality (circa 1998), but it was only visible to those intrepid folks who man the phones in Day Hall. And the online-edness (that is so a word!) was an after thought. The primary functionality of said database was to print out pages of daily events on campus and post them on the Information Desk in the Day Hall lobby so that visitors might know that at 11:15 there was a brown bag lecture on the Heisenberg uncertainty principle in room 128 Rockefeller.
In all the days that I tirelessly entered events into that database, printed them, framed them, and set them on the Desk, I can honestly say that Joel was the only person I ever saw actually look at them.
Fast-forward about a decade and the University Events Calendar sees, on average, 18,000 visits per month. Joel was a visionary, you see. There should totally be a statue of him on the Arts Quad (for he is also largely responsible for the fact that there is a Cornell Home Page (as opposed to just CUInfo) as well). Plus? He’s really tall and well-dressed and would make an excellent statue.
I digress. Sorry.
And Now For the Modern Day
Earlier this week, a bunch of us sat down in a conference room in the CCC with the bones of a requirements document for the newest incarnation of the Events Calendar. The OWC and IWS team (as well as some folks from Engineering and Mann Library) has been working with IS (Information Systems) to implement an installation of Bedework to replace the current–and ailing–calendar.
People, I’m not even going to try to spin this. This project is going to be complicated. Most of that meeting was spent discussing philosophical issues about coding practices. Bedework, you see, is Open Source, which means that we are free to modify it as we see fit (yay!). But the more modifications we make to suit our own purposes, the more forks we drive into the code (boo!)–moving us away from the standard as developed by the good folks at RPI and CalDev and making updates a potential nightmare (boo again!).
And there are features that we’d like that aren’t quite there yet in Bedework. Now, we could make them work with some slick coding in XSLT and XML and other brands of Alphabet Soup (yay!), but this presents problems for units on campus who want to adopt the installation of Bedework as their departmental calendar (boo!).
So, where does this leave us? In a little bit of Limbo, frankly. IWS programmers are busy looking at the code and comparing it to the reqs doc to see how (or if) we can make all the lights green with regard to needed functionality. IS is doing the same on their end and is also evaluating Bedework for use campus-wide as a calendaring service. Mann Library and Engineering will begin to poke around in the interface and evaluate it in terms of functionality and customization. Joel is in Boston, last I heard.
All I can say is that it’s a good thing there were donuts at this meeting.
Here are a Few Random Items of Note
- It’s come to my attention that the email subscription to this blog was broken and throwing up errors. I have fixed this. Subscribe! Subscribe!
- If you don’t already know about BlogHighEd, you should check it out. Brad Ward (Butler U) and Matt Herzberger (Texas A&M) are aggregating the best of higher ed blogging for your reading pleasure.
- You should also check out the 1st Annual edustyle Higher-ed Web Awards and nominate any sites that you think are outstanding at Cornell.
A: A Leap Year!
Lisa
Glad to see you back, Lisa! How was vacation?
So, onto this blog post which I am supposed to be commenting…
That’s definitely the problem with open-source systems. If you change stuff too much, updating will be a huge hassle! I think the best way to deal with the customization is to develop a theme/skin for the code. So, the code stays the same, and just like with WordPress (this blog, hint hint), the theme is applied. That way, when an update is needed, the code can be upgraded, and the theme reapplied.
Now, you could always write your own calendar system. Just use a bit of XML, PHP, and MySQL, and you’re good to go. It wouldn’t be hard at all! I can already imagine how the database would be queried, and output according to the date and time of the current pageview. For example, you could use PHP to tell the MySQL database to echo out any data that will occur (is greater than) the current date/time. Like this:
$MySQL){echo $MySQL;}
?>
Of course, that is a highly simplified version! You would have to define the variables and do a lot of other processing stuff to control the way the output will look.
And then, there’s always the possibility to use AJAX. That way, it’ll be really fast and no page reloads will be required.
It’s up to you guys, but I would personally go with writing my own instead of trying to use Bedework.
Oh shoot, my PHP code up there got screwed for some reason! Ignore it, it’s not going to work if I try to post it here…