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:
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.
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.