One of the more commonly used functions is getInfo(), which returns almost any piece of information from a user’s profile page; gender being one of them. The value returned for gender is either “Male” or “Female,” which is fine – but they are localized in the user’s language. So does this mean you have to check for “Female” if the user is using Facebook in English and “Weiblich” if the user chose German? Yes. It also means you have to check for imaginary languages. “Lass” is what you get if the user has his language preferences set to Pirate (English). You can see the headache this causes a developer if they are asked to report on the demographic of users of your app.

Another problem plaguing developers is the lack of organization for the documentation. The bulk of documentation exists on their developer wiki. This works well enough if you know exactly what you’re looking for, but if you don’t know the name of a function you’re better off using Google. A wiki format is more conducive to separate pages. So for a new developer stumbling on to the wiki, aside from a few copy-paste tutorials, there is no clear path of where to go. Only recently, with the release of their Javascript SDK, have they created a concise page containing documentation. Facebook officially supports 5 client libraries. For some of the libraries, documentation exists on the wiki and is shared amongst one another. All of the functions are typically the same for every language, so only one wiki page exists. PHP as well as Connect for the iPhone use the wiki pages, while the ActionScript library documentation is housed on Google code. This is because a lot of these libraries were contributed by the community and not officially created by Facebook, but this can be a large annoyance if you automatically assume that the function you’re using in a particular language is described by the wiki. Forcing people to scour multiple sites and forums for documentation is never a good idea if you are trying to build a good developer community around your platform.

The Facebook Platform status usually states “Facebook Platform is Healthy”. Occasionally it displays messages about performance issues, but that doesn’t help you much. Chances are, if you’re looking at Facebook platform status, you noticed the performance issues on your application. Looking at the “Average API Response Time” and “Error Count” doesn’t reveal much because there are no units on the y-axis. However looking at Developer Updates and Top Life Platform Bugs mights shed a light on the current status of Facebook. So what is the state of Facebook? Developer Update states they are changing profile picture sizes. So everyone who ever uses a profile picture in their application should go and double check that the new sizes will work. Existing Facebook applications constantly need to be updated to simply work. The bug list is as expected; there are a few major bugs, e.g. suggest to friends does not work (opened 29 December). And less critical but still annoying ones, e.g. request-form action opens a new window (opened 07 April 2009). The platform is in a state of constant flux with backwards incompatible updates being released and bugs for old features being introduced. If you create a Facebook app, you can’t just “set it and forget it.” You must monitor for changes to the platform and update your app as needed. You must also expect that there will be periods where your app won’t operate due to internal problems with Facebook’s system.

So where does this developer hell leave us? It actually promises a brighter future. The reason the API is broken is due to Facebook constantly working on it and bringing more enhancements to users and developers. They are rolling out new features such as allowing applications to gather a user’s email if given permission and giving more control to users over their privacy settings. Yes the platform is immature, but it’s certainly not stagnant. So what can a developer do to make things smoother? There are certainly enough complaints out there, so that path won’t lead anywhere. Trying to write more on the wiki and help the community won’t be very fruitful, because the API changes quickly enough that your notes may be soon outdated. In fact, the abundance of notes like this on the wiki makes it confusing as to who is right. Here are some suggestions for developers to cope with the situation:

1. Manage your client’s expectations. Make them aware that Facebook encounters issues periodically and this is out of your control. Give them the link to the Platform Live Status page so they can check that before coming screaming at you.
2. Subscribe to the Platform Live Status Feed, Developers News Feed, and Facebook Pages Notes. This way you should always be aware of a problem or an upcoming change before your client. The feeds are available via RSS or email except for the Pages Notes which seems to only be RSS.
3. Stay up to date with the Developer Roadmap in the wiki. You can create an account in the wiki and “watch” this page to get notified of changes.
4. If the client library you’re using has a svn repository, you can check the log to read about changes. For example, this command works for the PHP library – svn log -v http://svn.facebook.com/svnroot/platform/clients/php/trunk/. The ActionScript library on Google code page has a web interface for browsing changes – http://code.google.com/p/facebook-actionscript-api/source/list. There are some tools for automatically getting notified of an update to the code: SVN-Monitor, CommitMonitor, and SVN Notifier. Unfortunately, these are all Windows programs. Leave a comment if you know of one for Mac or Linux (yes, we know you can easily write a cron script to do it

In summary, at this stage if someone says “We want to do this and that with Facebook,” the best thing to do is say “I can try but I make no guarantees” instead of “Sure, it’s totally possible” because with Facebook you never know if what is available today will be still available by the time your application is ready to launch.

While mapping and geographic tools have been successfully utilized in many areas such as driving directions and event locations, some of the more interesting applications are in what might be called “location-based social media.” All social networks generally incorporate members’ location as a piece of information, but these sites and services offer very specific geographic functions and often incorporate related technologies such as GPS and mobile.

Frappr, Platial, and Socialight are sites that allow users to collaboratively mark locations on a shared map and post notes or comments about them. The uses are fairly open-ended and range from favorites places around town to fan clubs showing where everyone lives. Socialight also allows users to send a location to a mobile phone, but all that’s send is a link to a web page.

A service more oriented towards mobile is Dodgeball. It allows users to SMS their current location which is then broadcast to their friends, sort of like a geographic twitter. It gets a little complicated for places with multiple locations such as Starbucks and suffers from the limitation of only being about the immediate moment. Instead of saying to a friend, “let’s have a drink at Ace Bar tomorrow after work,” users have to sit around and wait for an alert, then drop everything to rush out to meet someone who serendipitously happens to be in their vicinity.

For planning, Dopplr provides services focused on travelers. Users can see friends who will be in the same city at the same time and make plans based on this. It obviously has some value to people who travel frequently, but doesn’t provide any other travel related features such as lodging or local information, so its use is very limited and “who will be in the same place as me” is a simple function that is likely to be incorporated into all travel sites. In fact, travel-oriented communities such as Travelpod or RealTravel provide this and much more.

For photos from around the world, the capability to add geotagging metadata to indicate location has led to many creative applications. Flickr was one of the first services to offer this and its map is an engaging way to explore and organize photos in addition to things like text tags. Flickr also provides a comprehensive API which has allowed developers to build their own interesting applications such as Trippermap and loc.alize.us. Locr is another photo service with a very specific geographic presentation.

One of the most robust geographically-oriented communities is at Geocaching, sort of a global hide-and-seek game where people use GPS devices to find caches hidden by other users. Geocachers are a passionate bunch and generally love outdoor adventures. At best the goal is to share personal favorite locations such as a beautiful view or secret hide-away, with the cache more an excuse for the journey.

These examples are quite varied. Some are simple and fall short, while others have very intriguing aspects. All hint at the amazing potential for the social application of geographic information, which is still in its early stages. As technologies advance and people become more accustomed to interacting with spatial data, it will be exciting to see increasingly sophisticated and compelling implementations of location-based social media.