This started as an outline for a quick presentation at the local Drupal users’ group. Turns out I had more to say.
The Current Situation
Our current campus events calendar is a set of half a dozen Google Calendars. Each calendar has a manager; some of the calendars are “openâ€, which means that people can submit information using a web-based form and then the manager either adds the item to the Google Calendar or asks one of our students to. Sometimes events are duplicated with conflicting information.
Featured events on our home page are managed entirely separately from the rest of the calendars. Sometimes the events have been in the campus calendar. Sometimes they haven’t!
The Academic Calendar at a glance is managed separately from both of those. This information is core to student life, but isn’t handled in a consistent way across all of the calendaring systems.
Campus holidays are listed not just in those three locations, all managed separately, but also as a separate list on the Human Resources site.
What we built was a single Drupal-based calendar to integrate all of these systems.
The Content Type
The fields are organized into tabs with Field Group.
The description has a very lightweight WYSIWYG with CKEditor: just bold, italic, lists, and links. We’re using Media to manage the image and flier fields; at the outset I’m being very simple with those, since it’s a new feature for the campus calendar. All of the images will be displayed using a single simple image style.
The Date field includes a repeat option, which can be tricky to use in Views but works pretty well most of the time. I ended up adding an “Academic Quarter†field for some specific events; it’s a kludge, in my opinion, but academic calendars really don’t match anything else out there.
Categorization
This isn’t really a Drupal thing so much as it is a user research thing. I discovered pretty quickly that the Google Calendars weren’t going to work as categories. In particular, I wanted to generate the Academic Calendar at a glance automatically, but the Academic Google Calendar had too many superfluous events. In fact, we discovered that there were literally two different definitions of “Academic Calendarâ€!
After looking at all of the calendars and their descriptions, we decided instead to run a card sort. We printed out cards with about 75 randomly selected events and had groups of students organize them into sets. After looking at the results and trying a few things, I ended up creating a two-dimensional Taxonomy system: categories and formats.
The Academic Calendar at a glance is then a View built on an intersection of those: “Deadlines†that are either Holidays or Academic events. We’ve also given users filtering tools so they can drill down to find what interests them.
To make sure we’re using consistent descriptions, the page describing the categories and formats is actually built with Views and Insert View, displaying the taxonomy term descriptions. For my own ease of use, I added edit links, too.
Importing Events
The Date iCal module in combination with Feeds made it really easy to import all of our Google Calendars, which was great for testing out ideas. I also built a sort of rough bulk editing view for adding information to the imported items, which was mostly used by me and by our student workers.
I also create a CSV import format specifically for bringing in a bunch of dates related to academic quarters, so that we can import them all at once instead of creating them one at a time. On this one I used Feeds Tamper to set the category and published state.
Roles & Rules
By using the CAS module with the Workbench Moderation module, anyone on campus can now submit an event directly, but calendar managers will approve them before they go live.
So we have three roles: authenticated, which is anyone who can log in through CAS, calendar approval, which more or less matches the old set of calendar managers, and administrator, which is a few people in our office.
We’re using Rules to handle notifications for the calendar managers. Any time someone who isn’t a calendar manager or admin submits an event, an email will go out to all of the calendar managers.
That same Rule also shows a message when an event is submitted, explaining the moderation process.
The Calendar Module & Styling Dates
We’re using the Calendar module to handle the daily and monthly pages. I like how it builds a calendar, but I have some frustrations: I have not yet figured out whether it’s possible to make the days clickable on the monthly calendars, which made the mini-calendar pretty much useless. Also, styling the calendars can be pretty tough: there’s a lot of awkward specificity to overrule if you want it to look different from the defaults.
Similarly, the built-in markup in Date fields is odd at best and we’ve had to work around it quite a bit. I’m hoping to look at overriding the markup with template functions, but I’m not super-happy about that.
Views, Views, and More Views
As I mentioned, the daily and monthly pages are Calendar views. The holidays are a pretty simple table view, restricted by category and grouped by year.
If you haven’t done much work with dates in Views, this is a place where creating date formats comes in really handy. The date is added twice: one time to display it in the format we want, in the other formatted as just a year for grouping.
The academic calendar at a glance does something similar, but with a more complicated category selection criteria and no grouping. But I created a contextual filter so that there’s pages for each quarter. A weird thing about academic quarters is that they sort of overlap: people start registering for the next quarter while the current one is still happening. So sometimes you want to see the flow of dates, and sometimes you want to see just a single quarter’s information. This hits both options.
The events by category page is a simple listing grouped by month with an exposed filter. I’m using Better Exposed Filters to get checkboxes. There’s a bug in the most recent versions of Views for Drupal 7, by the way, that exposes some Views editing text to visitors. The way around it for now is a template function.
We also have a pretty simple View for highlighted events. On the calendar site, it’s a list, but we also have an XML feed using Views data export that will be used in our current CMS to display those events on the home page and on the current students page. The highlighted events are those marked “Promoted to front pageâ€, since that’s pretty easy and built in.
There isn’t a good way to separate out the ability to moderate from the ability to promote without adding another module, so for now we’re going to manage socially. There’s only a few calendar managers: we can tell them not to touch the button, and we can check on it pretty easily.
Features, Git, and Continuous Integration
This is our first project working with our colleagues in Application Support on having a development to production workflow. We’ve got a Feature built for the calendar’s structure, including all the things you can set with Strongarm.
In the test site, I’m making changes and trying new ideas, then recreating the feature with a new version number.
Then I commit it and push to our internal Gitlab site – which is also where we have all of the theme changes, both the CSS that the designer has been working on, and the template changes I’ve been working on. All of the commits happen on the dev branch.
Dave set up a deploy script to make all of those changes live on the test server, so once the commit is pushed, it fires off the script.
Then I go to Gitlab and make a merge request when I’m ready for all those changes to go into the production site. I approve my request J and then it’s in production. It’s been pretty smooth so far and I’m pleased with the process.
Next Steps
Next week we’ll be doing training with the calendar managers and a separate training and meeting related to the Academic Calendar(s). We’ve actually decided not to do a final iCal import for the last couple of weeks of entries specifically so that the calendar managers can get some practice and familiarity.
I’m working on a short write-up for calendar visitors to help them understand the changes. I’m also prepping some redirects and changes to our existing CMS to go live on the day of the switchover.
The week after next, we should be able to go live. After that we’ll be keeping an eye on things and listening for both problems and ideas. I imagine we’ll have a few weeks of tweaking and updating; there’s always things you don’t find until something is in front of people!
Modules Mentioned
- Better Exposed Filters
- Calendar
- CAS
- CKEditor
- Date
- Date iCal
- Features
- Feeds
- Feeds Tamper
- Field Group
- Insert View
- Media
- Rules
- Strongarm
- Taxonomy
- Views
- Views data export
- Workbench Moderation