Getting Onto The Calendar
Published 19 years, 7 months pastOver at Complex Spiral Consulting, I maintain a list of upcoming appearances at conferences, workshops, and the like. These are the “public” events; that is, events which are accessible by members of the public, assuming they pay whatever registration fee is being charged by the people in charge of the event. This is in contrast to “private” events; that is, client work that isn’t open to anyone except employees of the client.
Occasionally I’m asked if I have an RSS feed of those events, or send out e-mail updates, or otherwise provide any sort of notice other than just changing the web page. For a long time, the answer was basically “no”. Now it’s “yes”, and it’s an example of a microformat in action.
If you’re using iCal on OS X, or any other webcal:-aware calendaring program, then all you have to do is hit the following link:
Complex Spiral upcoming events calendar. Your calendar program should come to the foreground and let you add the URI as a subscribed calendar. And hey presto! You’re done. Any changes to the web page will be reflected in your calendar the next time the subscription is refreshed, and iCal lets you set your refresh interval to be 15 minutes, once a day, once a week, and so on.
What’s happening there is you’re pouring the home page of complexspiral.com through an XSLT recipe called X2V written by Brian Suda. His XSLT pulls out the hCalendar markup and turns it into an ICS file, one fully conformant with RFC 2445. So I don’t have to figure out how to produce and provide my own ICS file. Providing the hCalendar markup is enough, thanks to Brian’s work.
Of course, the number of people who would want to subscribe to my professional appearances schedule is fairly small. This is just a demonstration, though. Suppose a site like, oh, upcoming.org were to publish their event calendars with hCalendar markup? Then all you’d have to do is find the page that corresponds to your city, run it through Brian’s script, and you’d have your very own regularly updated local events calendar, just like that.
Guess what? You can do that right now: upcoming.org is publishing its information using hCalendar markup. For example, here’s the calendar for Cleveland, Ohio, ready for one-click subscription: Cleveland events calendar. If you just want the ICS file to be downloaded to your hard drive, then you can use this link instead: Cleveland events ICS file. The only difference between the two links is that the former uses the webcal: scheme identifier, whereas the second uses the more familiar http:.
I personally think there needs to be some work done on their hCalendar markup, like properly marking up location information. The time information for some events seems to be a bit wonky as well, although the dates are accurate. The great thing is that the hCalendar information could be fixed in very short order. In fact, from what I’ve heard, they added basic hCalendar markup to the site in under an hour. Adding more, or fixing any problems in what they have, shouldn’t take much longer.
Imagine how much further this could go. Suppose Basecamp marked up its project calendars with hCalendar, and used a script like Brian’s to turn it into ICS information. Its users could have project milestones right there in their personal calendar programs. Ditto for the To-Do’s lists, because that sort of information is all defined in the iCalendar specification. The TiVo site could provide customized schedules, like all the showings of American Idol or Masterpiece Theater. The IMDB could publish movie opening dates in hCalendar format; studios could do the same. Want a calendar schedule that shows what DVDs are coming out, when? Or what new albums are being released for the next month? All it takes is a little slice of a webmonkey’s time.
The point being, there’s nothing for which said webmonkey has to wait. The tools are already here. No browser has to be upgraded. In fact, in many ways this bypasses the browser to send information directly to the calendaring program… but the information is provided in a browser- and search-engine-friendly way, so they can access and use the same data in their own ways. No alternate files. Just a single set of information, made more rich and useful through easily understood mechanisms.
How cool is that?
Comments (11)
Very cool! Since becoming aware of microformats I’ve been doing a lot of thinking about ways that this could be used to make the web a better place, and this is a perfect example. Your examples of the wide variety of ways that the hcal could enable sites to increase the utility of the information that already exists on their sites… right on!
This is very intresting and i think it will lead to something useful (it already has!), but, the calendar you mentioned is only on MAC as far as i know. What applications are suported on the windows/linux platform?
it must be great to be part of such a intresting project!
I don’t know what Windows or Linux calendaring applications support subscribing to ICS files the way iCal does, or even if any of them do, but I would think that most of them would at least allow you to import an ICS file from your hard drive. You wouldn’t get the nifty scheduled live updates that way without writing some kind of batch job, but you could at least grab the information for local use.
I used the http: version of the upcoming.org link and subscribed it to my calendar using the Mozilla Calendar plug in for Thunderbird. Seems to work just fine (and I’m on WinXP, so there’s one example).
@Eric: Basecamp provides native ics files, so conversion from hCal to ics is unnecessary.
@Robert: try Mozilla Sunbird
Incidentally, Upcoming.org also supports iCal natively. Also, the hCalendar time information is a little tricky right now because the site doesn’t store event timezones, but we’re working on that. Anyway, very interesting entry.
FYI, Eric’s events can also be found in EVDB:
http://evdb.com/search_handler?keywords=eric+meyer
As for hCalendar, why not just embed the iCalendar file info right in the HTML as well, or, have a LINK REL=”ALTERNATE” type link in the HEAD tags that points to the ICAL file(s) for that page? We do that in EVDB.
Why would I produce an ICS file separate from my XHTML when I could embed all of the relevant calendar information into the XHTML and automatically produce an ICS from that information? Not to mention that, since all the information is in the XHTML, it’s available for anyone to grab and pour into a third-party site like EVDB or Technorati or Google.
For that matter, why would anyone?
Love your site. Really interested in the hCalendar implementation. I was involved running the working group for CAP, iCalender, etc. Founded a calendaring consortium (www.calconnect.org) and thought you might like to take a peek at what’s going on. We’re going to put up an RSS feed and would like to pick up your stuff as well. Very nice format and blog. Come visit us and help us spread the word about calendaring and scheduling.
Regards, Pat Egen
Calendaring Evangelist, and end user!
http://www.calconnect.org
P.S. Dave Thewlis is the guy I brought in to be the Exec Director. He’s the one who does most of the work.
I can’t help wondering why you would keep your schedule in XHTML? Most people would want to use an application specifically designed for that purpose and export it to the web, NOT the other way around.
My public schedule, the one I put on the Web, is most efficiently kept in XHTML because that’s how it’s going to be published. So now I can add a little extra information (still via XHTML) and it’s easily translated into ICS or other calendaring formats. My personal schedule is not in XHTML, but then I have no intention of publishing that to the Web, so there’s little point in keeping it in a Web-compatible format.
You’re probably right that most people would want to store their schedules in an application and export it to the Web. However, and this is the crucial part, schedules that are meant for the Web—conference schedules, event listings, tour dates, speaking appearances, and so on—are in my mind best served by hCalendar.
Most people who use a calendaring application are using it for meetings, appointments, and similar stuff that they would never want to put online. (Would I want the rest of the world to know when I’m seeing a proctologist? Hell no! …assuming I were, of course.) The things that they do want to put online should either be stored in XHTML, or published in XHTML… and in either case, adding the hCalendar information makes it far more powerful than just blatting it out as non-annotated markup.
Because that way, as I said in the post, the same information meant for display in Web browsers (and other user agents) can be picked up by search engines with the hCalendar information—thus allowing them to provide better search results. A quick example: if a large movie site published theater times with hCalendar information, and also provided reviews in hReview, then they or any other search engine would be able to let users execute searches like “show me all of the movies that got at least four out of five stars that have showings that start in the next three hours”. Add in a simple postal code, and you can add “in my area” to that query.
Take it further: suppose we had an “hCommerce” microformat that allowed for embedding information about prices, currencies, and so on. Now you can add “that cost less than $9 per person” to the query. (Which, in New York City, would probably get “no results”, but that’s their problem.)
To bring it back to the point at hand, the point here is not to make it easier to produce the information. In fact, adding semantic information, regardless of the mechanism, makes it harder to produce information. Microformats are a lot less hard than many other approaches, in my view, but they still add some complexity. The whole point is to make things easier for the users/readers/consumers—the people looking for this information, and who want to use it in their own personal ways.