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.
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.
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 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!
- Better Exposed Filters
- Date iCal
- Feeds Tamper
- Field Group
- Insert View
- Views data export
- Workbench Moderation