The creation of calendars and events on websites is a recurring challenge for web developers - over the last year we've developed our own events system for concrete5 that we think is both easy to use and highly customisable.

See the video for this post where I explain our thinking behind this system and how it works. For context the video was filmed on the 14th of Dec, 2013.

Some further background

We felt the need to develop our own calendaring solution for concrete5 because we found that existing systems:

  • often presented complex date entry forms, with recurring dates being confusing to manage
  • weren't 'Composer' driven, meaning that clients would need to follow a different process to add events, compared to other pages and info
  • had fairly fixed outputs that weren't easy to customise and style, and that often didn't present events in orders that were useful
  • didn't handle events that spanned periods of time very well
  • had both complex dashboard pages and blocks that were at the mercy of core upgrades and breakages
  • were difficult to visually customise, as well as extend with additional pieces of information

We tried to take a step back and look at the way our clients (and ourselves) actually use recurring dates on websites. What we realised is that with web based calendar systems perhaps too much emphasis is put on handling recurring dates, and making them like iCal or similar, rather than focusing on the typical use cases where events are put on sites.

As described in the video, we looked at eliminating the need for complex date entry interfaces and replacing them with a simple text area for the entry of one or more dates - this didn't initially feel possible until we evaluated a wide variety of date usage scenarios and developed a fairly long list of realisations and conclusions that supported our aim. Here are some of the main conclusions we had through our investigation :

Truly recurring events aren't actually that common

Yearly recurring dates aren't really used very often on websites, they are more for things like birthdays/anniversaries or due dates for billing. For events that run every year, it's also very rare that it actually falls on the same date, events tend to be put on weekends or simply get moved around the calendar. Event organisers tend not to want to publish future event dates until they are confirmed anyway. We realised that if yearly recurring events are needed, writing a list of say, 6 specific dates is neither time consuming or confusing.

Monthly recurring dates (e.g. the same date every month) was something we really couldn't think of a use case for on a site. Putting something on the same date of every month means the day of the week is constantly changing - you'd be more likely to have the '2nd Thursday of every month'. In these cases, again, dates often get skipped due to holidays, etc. Monthly events often have different times too. We found that our clients were updating their events every few months after they had confirmed bookings, etc, so the idea of manually managing a list of dates wasn't a concern.

Weekly events are something we realised that normally only last a set time, maybe something like every week for a month. This is then really easy to enter in four times, and again it can have different times for each recurrence. You might have the last event go an hour later for example. Although it's perhaps a bit messy to put in an event date 52 times, we simply haven't seen examples of people wanting to do things like this. 

Recurring events often need to be adjusted later

The other problem we recognised is that events change, get cancelled, effectively breaking traditional recurring rules all the time. So if we did set up something that was say, weekly recurring, but on a holiday it would need to be removed, we'd have to put in a 'NOT' event.. this just didn't make sense to us. 

People are comfortable using longer date formats, ones they use in everyday life

We realised that people often get emailed a series of dates for an event - with our system they can cut and paste them in. A simple text box for date entry is both easy to work with, but also very easy to review and check - there's no wondering whether you've set up the recurring rules correctly.

We also heavily looked at date formats themselves, almost to the point of madness. Dates are such a complex field due to language, cultural and historial reasons. Although complex, we found that there are some nice ways using PHP to handle a wide range of common date formats and we found that people would tend to prefer to write dates more in full for clarity (i.e. 25th December 2013, rather than 24/10/13). 

Dates don't always need heavy input validation

As I briefly mention in the video, the idea of providing a freely editable text box for date entry at times really went against my developer instincts - not providing a date picker or at least heavily validated fields for date entry seemed like an invitation for all kinds of problems. However, after actually using this system on a few real projects we found that this simply wasn't a problem.

What kinds of things could this calendar system be used for?

We didn't want to set a specific purpose for this system, we wanted it to be as generic and flexible as possible. Some of the purposes we think it would be great for are:

  • Clubs and organisations that need to list specific events like matches, races, club nights, functions
  • Entertainment venues that need to list gigs, perhaps with monthly recurring events, karoke night, etc
  • Calendars on tourist information websites, listing community events, as each event page can provide large amounts of detail
  • Use on private/members only sections of websites, to display meeting dates and times, like a traditional calendar, being able to list the next upcoming meetings

Has this caught your interest?

We think the beauty of this system is that it's quite simple in it's set up, with nearly all of it's complexity wrapped up in a 'dateparser' helper, not in a series of complex dashboard pages. You can even add the event dates attribute to ad-hoc pages on your site to turn it into an event - there's no need to create events in a seperate system and link them to pages. 

If you think this calendaring system is what you need for your next project, feel free to message us and we're happy to discuss.

Also feel free to ask any questions! 

-Ryan