The JBBA runs a number of regular events throughout the year, some are celebrations others fundraisers and of course many of them are scheduled basketball matches!
As part or Quadra's recent re-build of, and ongoing improvements to, the website we wanted to make the process of finding, researching and attending these events more enjoyable and interactive than just churning out a monthly newsletter listing the upcoming months event schedule. We also wanted to facilitate for ticketing and online payment for events as this would reduce the manual administration required by event organisers for example estimating head count and reconciling cash payments to members etc.
Initially, we considered an integration with the Google Calendar API. This would have allowed us to reduce our initial work load as we would have been making use of Google's existing event and calendar functionality however, we decided against this for the following reasons:
- Google do not offer iCal exports of their events, so if you want to save an event in your calendar you will need to have a Google account (and more importantly, actually use your Google calendar)
- Although the API is very flexible and would allow us to manage event data only and still deal with the presentation layer ourselves, this would require a much deeper and more invested integration with Google Calendar. Any kind of 'quick fix' integration would leave us with effectively an embedded calendar on the JBBA website, this would not be inline with the JBBA's branding and would look less professional
- We would be restricted to managing events in whichever way Google deemed fit (i.e. the data we could store against each event etc). Google no doubt do a very good job of modeling events, but we wanted to keep the flexibility to do things our own way if we needed to.
We therefore decided to build our own calendar and event management pages within the JBBA website and our SilverStripe CMS, so what did we end up with?
Responsive Design & Multiple Views
First things first, everyone knows that mobile and tablet usage are on the rise and responsive websites are expected in todays world. Some more complicated features, such as calendars, are still behind the curve on this front, we did not want to fall in to that trap so without question full support for mobile and tablet was a must.
As you can see from the examples above we also decided to provide multiple views on to the data:
- Calendar View - The standard and most familiure way of listing events over a set time span. Best suited for tablet and larger screen sizes
- List View - Not interested in what day of the week and/or date the event falls on, or are you viewing on a smaller screen, the events listed in chronological order might be best for you
- Mini Calendar - used on the JBBA homepage to see whats on at a glance
The developers amongst you may have just shuddered reading that, I know I did when I had it briefed in to me as a requirement. Recurring events is the perfect example of something which is theoretically simple but is deceivingly difficult to implement in practise.
Do you treat each event instance as it's own unique event, or just as a clone of the original? How do you save a recurring event, should that save just one instance or all instances? What happens when you delete a recurring event, do you just delete one instance, all future instances, all instances?!
The list goes on, I won't bore you with the details of exactly what we chose to implement but as you can see the user can subscribe to a single instance of the event or all future instances. The work required from a management side is reduced as rather than setting up 52 individual events for something which occurs on a weekly basis, you only need to set up one which reccurs multiple times.
Saving and Exporting Events
One of the reasons we are such big fans of Linux, SilverStripe and other open source projects is because they don't lock you in to using the tools they deem to be the 'best' or the 'right one', they offer you the freedom to use what works for you personally. We also wanted to follow this philosophy and give users the ability to save events to whatever calendar application they want. We therefore decided to use the iCal standard to allow users to download events.
iCal is an IETF standard, is supported by all mainstream calendar applications and is de facto the standard for abstract modeling of events. It has a fairly complicated make up and is rather poorly documented (unless you are a robot who's sole purpose is to interpret IETF specifications) however, once you get your head around it iCal can do some very useful things like ensuring event updates overwrite the original event automatically, referencing your local time zone in all event dates and times and allows for modifying a single event instance within a set of recurring events.
The .ics iCal files are also lightweight which meant we can easily attach them to e-mails and mail out event updates and cancellations to all event attendees automatically.
Ticketing and Online Payment
Finally a number of our social and fundraising events were perfect candidates for online payment and ticketing functionality. Some events, such as seated meals, require that numbers are confirmed in advance. Paid events are also easier to deal with when payment is made in advance and is easily (and automatically) reconciled to a given payee, the corresponding ticket acts like a receipt in these instances.
Some of our events are also limited to paid JBBA members only, the event managers are unlikely to know all members and recognise them visually so requiring users to log in with a suitable account and purchase a ticket is a good way of preventing people from sneaking in to our private events. We coupled this with some ticket validation logic which, with the help of the QR code we print on tickets and a smart phone, allows us to validate that the person using the ticket to enter an event is the same person who purchased the ticket online and that they meet the requirements for the event such as age and membership status.
Looking for existing projects and services which you can integrate with and/or use under license is never a bad option, developers are taught to be 'lazy' and 'DRY' after all however, sometimes when you have a detailed set of requirements and need a highly professional visual solution bespoke functionality is the way to go.
I will openly admit that once or twice during the build phase, particularly the recurring events element, I thought to myself "why have I taken on this mammoth task!" but in the long term I stand by our decision to build things from scratch to meet our needs exactly. I am very happy with how the feature turned out and we have had some good feedback from our users, everyone is happy!