Events on the Web: Why Do They Suck?

If you’ve ever wanted to easily find out what events are happening in your area, you know what an impossible a task it is. I usually have to check 4 or 5 sites, plus Facebook and Twitter before I feel up-to-date. To make matters worse, none of these services freely exchange information. An event listing on Upcoming, for example, has no correlation with the same listing on Facebook.

Adding insult to injury, duplicate events with differing times and dates often arise, cluttering up an otherwise decent experience with this:

Sun 05:00 PM Caribbean Night with the Marbali Steel Drum Band

(eventful: Inn at East Hill Farm)

Sun 05:25 PM Caribbean Night

(upcoming: The Inn at Hill Farms)

Which time is correct? Is the venue called East Hill Farm, or Hill Farms? The good news is problems like this can be avoided if these services just talk to each other.

From my experience with the APIs of the big players in the event listing market (Upcoming, Zvents, Eventful, TicketMaster, etc.), it is evident there is no standard format being used to exchange event information behind the scenes. If you’ve ever seen an event listing with redundant date, time and location information in its description, it’s because a proper event listing standard has yet to be widely adopted.

Each API arbitrarily assigns its own naming scheme, date formats and data structure. At Localist, we’ve picked up the slack a bit by developing customized parsers to retrieve and standardize the information, but cleaned up information isn’t truly useful until the format is adopted by a wider audience.

What about hCalendar?

While hCalendar is a great microformat for standardizing the presentation and “scrapability” of event listings (making the search engine the API), it inherently requires that all data related to the event be visible to the user. In practice, this has forced most event listing sites to intentionally limit the amount of parsable data available, restricting additional useful information to be entered in the free-text description ï¬eld, where no standard is defined.

Also, providing relational information between events and performers is not reliably possible using hCalendar. For example, if there are 5 recurring instances of “Trivia Night” at “JoeÊ¼s Bar,” it is not possible to attach photos or other useful data to “Trivia Night,” only the specific date instance. This results in isolated information that is quickly lost as time goes on.

What needs to be done?

The first step is to getÂ everyone, not just the big event listing services, to adopt a simple standard that has already been widely adopted. The best candidate so far is iCalendar, or ICS. Every calendar on the Web should be available in the ICS standard without requiring any modification by an external service or parser. Once this happens, event data can be collected consistently.

Then, we step it up. The ICS format ensures all event information revolves around the event time only, when really, it should revolve around time and space. A consistent way to add information on top of the ICS standard is easy to implement; the challenge is, again, reaching a critical mass.

Where can I see an example?

Services like FuseCal are diligently combing the Web looking for calendars of all shapes and sizes, then parsing them into a (somewhat) accurate iCal format.

Aaron Brazell is a Baltimore, MD-based WordPress developer, A Sr. Web Enginner at 10up, a co-founder at WP Engine, WordPress core contributor and author. He wrote the book WordPress Bible and has been publishing on the web since 2000. You can follow him on Twitter, on his personal blog and view his photography at The Aperture Filter.

http://www.pigsonthewing.org.uk/ Andy Mabbett

Five – or any number – of recurring instances of â€œTrivia Nightâ€ at â€œJoeÊ¼s Barâ€ are catered for in the hCalendar microformat by the “include pattern“.

hCalendar is an HTML representation of iCalendar – if your event data is in an hCalendar, then it is, by definition, in an iCalendar.

iCalendar (and this hCalendar) have location and coordinates properties for “sapces”.

I’m not clear what problem remains to be solved, here?

http://www.pigsonthewing.org.uk/ Andy Mabbett

s/and this/and this

Sorry.

http://www.pigsonthewing.org.uk/ Andy Mabbett

Oh dear!

I meant:

s/and this/and thus

I’ll stop, now.

http://www.technosailor.com/ Aaron Brazell

No worries

http://www.dataflurry.com Joel McLaughlin

Agreed! Great points. Websites often times provide inaccurate information. Sites need to offer redundant event management so that people can confirm or decline the accuracy of event information