Website: Calendar Module
Client: Me, but also the Society of Professional Journalists
Contributions: Built the entire back end and the entire front end (one widget aside).
Live Demo: Link
SPJ’s event calendar was never what one would call satisfying. When I inherited it in 2006, it was a locked-in database that only worked on SPJ’s website and nowhere else. During the golden age of open internet APIs, when every platform let you do whatever you could (responsibly) dream up with their data, I moved the calendar to Google Calendar and routed it through a service by Yahoo called Pipes that allowed it to display natively on SPJ’s website while also availing itself to people’s personal calendars on their computers and phones.
Then Yahoo ended Pipes, and I used a less elegant solution that relied fully on Google. Then Google locked the doors on its barn, preventing their calendars from appearing on SPJ.org in any form other than an ugly widget that clashed with everything else. All I wanted was a calendar application that wasn’t reliant on these outside sources but would still work properly across all platforms (from iOS to Windows to the web) and display elegantly on SPJ’s website — which, due to its own locked-in nature, didn’t play nice with any of those platforms by default. Amazingly, nobody seemed to offer a solution, not even a paid one, that threaded those needles.
Once that was working and this whole thing was confirmed worthwhile, I created an interface — using HTML, PHP and another database — that not only allows me (and anyone designated as an admin) to log in and enter/edit events, but allows anyone (without logging in) to submit events that admins can edit, reject or approve as-is for inclusion in the calendar. So in that respect, it gave us more functionality than we ever had with Google and Yahoo’s calendars. Since its launch last year, several SPJ members and chapters have used that submission feature to good effect.
Because it runs on plain-old code and isn’t reliant on any outside sources of data, the calendar module not only is lightweight, but designed to work as intended for as long as the web itself works. And anybody who knows how to code can, of course, easily modify it for their own particular needs.
Surprisingly (but also not, if you ponder for a moment how tangled they are), the most obnoxious part of the whole process wasn’t the building or language translations, but making sure time zones work across everybody’s various events and services. What seems like simple math gets messy in a hurry once you factor in time zones beyond the usual eastern/central/mountain/pacific. It becomes an outright boondoggle when you add in the inconsistent treachery that is daylight savings time, and it morphs into a waking nightmare when you learn all the ways some services translate those time zones and DST periods differently than others. Whose idea was time zones, anyway? Because I’d like to speak to them.