Facebook is now an elmcity event source

Last week I said that confusion about the visibility of events in Facebook had thwarted my plan to include Facebook as an event source for elmcity hubs. The day after I wrote that post, though, Stephen Judd noted in a comment that a new data entry method has appeared — one that clears up the confusion.

Until April 30, your choices when publishing an event were:

Open: Anyone can see this Event and its content.

Closed: Anyone can see this Event, but its content is only shown to guests.

Secret: Only people who are invited can see this Event and its content.

Some people opted for Closed when they really ought to have picked Secret. With the advent of API-based search that meant automated tools like the elmcity aggregator could surface events — like surprise birthday parties — not meant to be seen.

But on May 1 the choices had narrowed to just public or private. It’s implemented as a checkbox:

[x] Anyone can view and RSVP (public event)

It defaults to checked, i.e. public. That’s consistent with the general tilt, in Facebook, toward public rather than private defaults. Many people think that’s the wrong default, and I’m inclined to agree. But at least a confusing three-valued choice has been reduced to an easier-to-understand two-valued choice.

Given that, I’ve decided to add Facebook as an elmcity event source. I’m mindful of the power of defaults, so haven’t made this a default behavior. When a curator spins up a new elmcity hub, the event sources included by default — that is, before you add any iCalendar feeds to your registry — were, and still are, Eventful, Upcoming, and EventBrite. If you want to add Facebook events, you can now do so by adding a new name/value pair to your hub’s metadata record in delicious:

facebook=yes

Curators can, by the way, now include or exclude any of the services. These are the defaults:

eventful=yes
upcoming=yes
eventbrite=yes
facebook=no

All of these settings can be tweaked.

The elmcity service finds Facebook events by searching for them using the location you specify in your metadata record. Here are some sample searches:

If you change the location parameter in that URL you can see which Facebook events will be included for your town. So far, I’m not seeing many public events, even for very populous locations. Facebook’s event system was always more appropriate for friends-and-family events that you wouldn’t expect to see on a community calendar. If you wanted to advertise an event open to the general public, services like Eventful or Upcoming or EventBrite were better ways to do it. Or you can create a public iCalendar feed.

It will be interesting to see if Facebook’s new event system, which defaults to public, produces more public events than before. To the extent that it does, it could become a useful source for elmcity curators. But if people who create public events in Facebook want that to happen, they’ll need to learn more about those events appear in other contexts.

Consider this event, one of a handful that turns up in a search for Keene, NH. Here’s what anyone can see in Facebook:

What film is being screened? Neither the title nor the description tells us. My guess is that if you know Susan Hay, and are affiliated with mothersuniting.org, that information is part of a shared context that Susan just took for granted when she posted this “public” Facebook event. When she marked the event Public it hadn’t occurred to her that the actual scope of Public means she ought to have named the film in the title or description.

Note that there is an events page at mothersuniting.org, albeit five years behind the times. My own view is that mothersuniting.org should be the authoritative source for its own event information. It could use Google Calendar, for example, to publish an HTML view of a calendar into the events page on its website, while at the same time producing an iCalendar feed that could be listed in a community registry. Facebook really ought to be a downstream consumer of that kind of event source, not an upstream producer.

But no matter what I think, there will be people, maybe a lot of people, who end up making Facebook the authoritative source for their event information, instead of their own websites. So I’m enabling curators to capture those streams. We’ll see how it unfolds. As always, it’ll be fascinating to watch people walk the slippery path that divides private from public.


PS: If you’re a developer working with the new events API, here’s an odd quirk I’ve uncovered. Dates and times reported through the Facebook API don’t correlate sensibly with dates and times reported in the Facebook application.

At first I thought this was a timezone issue, and tried various Ptolemaic adjustments to make things work out. It got weirder and weirder, until finally I went empirical and made this table of observations:

    Where: Keene: GMT-5 
 FB start: 2010-05-09 19:00
API start: 2010-05-10 02:00
     Diff: +7 hours

http://www.facebook.com/event.php?eid=113825365318937

    Where: Chicago: GMT-6 
 FB start: 2010-05-01 11:00
API start: 2010-05-02 06:00
     Diff: +7 hours

http://www.facebook.com/event.php?eid=114150548619789

    Where: Salt Lake City: GMT-7
 FB start: 2010-04-28 06:00
API start: 2010-04-28 13:00
     Diff: +7 hours  

http://www.facebook.com/event.php?eid=115044215191908

    Where: Fresno: GMT-8 
 FB start: 2010-05-03 11:00
API start: 2010-05-03 18:00
     Diff: +7 hours

For no reason I can see, the API reports a local time that’s 7 hours ahead of the time you see when you view the event in Facebook. After making that adjustment, things seem to work. Why 7 hours? Beats me.

3 thoughts on “Facebook is now an elmcity event source

  1. Zach Beauvais

    Hi Jon,

    As I tweeted, I had a similar problem with time differences from a different source. Using a WordPress install from the States (my shared host is an American company) and using the .ics from Google Calendar (set to GMT) to display upcoming events kept showing the time as 4hrs later than they were recorded in Google Calendar.

    So, If I created a google event at 10:00, it’d show up as 14:00 in the displayed calendar. It took me a while to find that it was returning the local server time. Oddly, it was a single PHP include which was breaking it, but seemed to kill the rest of the plugin when I modified it, so I ended up using Google’s iframe (yeuch) instead.

    I wonder whether there is something similar occuring here? It should be behind by 7 hrs if it’s in California, however… hmmm

    Reply
  2. Mike Grace

    It’s fun to hear that you have made progress with this since I last heard you talking about it at dinner before Kynetx Impact. Will be interesting to see if things trend towards the direction that you predict.

    Reply
  3. Pingback: Syndicating Facebook events « Jon Udell

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s