So who’s doing it? OAuth has been the buzz in the tech world for the past few months. Enough so that that Facebook, Twitter, Google, MySpace, FourSquare, Netflix are in. Although there is no specification regarding what a 3rd party site should or shouldn’t be allowed to do on the OAuth-providing site, most provide enough APIs to replicate a good portion of the site functionality. Twitter and Foursquare allow you to do anything that you can already do through their web interface/app. This is great for developers as they can build their own twitter/foursquare clients. And of course this isn’t just limited to small party sites and applications; Facebook uses OAuth with Google for it’s friend finder feature.

To the end user this is great! Services are now integrated together. Say goodbye to the creation of countless user accounts. Everything could be accessed via your Facebook login. If you want to share something with friends, you can do that via 1 click as opposed to being redirected to the specific OAuth provider’s share page. Aside from simplicity, security gets a benefit. Facebook’s friend finder asks for a user’s email and password so it can access the contact list. With gmail, if your original email account is with gmail, all you have to do is log in and that’s it.

Excitement aside, it can be easy to overlook the potential security/privacy issues. When logging in with OAuth, you are allowing a 3rd party to act on your behalf. So, let’s say you have logged in with Twitter on a 3rd party site – a year later, that 3rd party site could potentially spam tweets from your account. The counter argument states that twitter can then instantly disable any actions from that 3rd party site, but that doesn’t help against the initial occurrence. Another thing to note is that when logging in with OAuth credentials, it is possible to give away all of the personal information available to the OAuth provider. So when logging in with Facebook, the 3rd party site gets the user’s email address, name, location, relationship status, friends, etc… As it becomes easier to integrate services it also becomes easier to spread your personal information unknowingly. None of this is a problem of OAuth specifically, but rather stems from improper implementations.

All in all, OAuth is an excellent tool that will bring a more seamless web in the future. It is possible that we may end up with a central social hub that allows us to control all of our servers. Imagine going to a movie theater and posting a status update from Facebook. It would instantly check you in with FourSquare and post to Twitter. In addition to Netflix learning which movie to suggest to you later. We’ve written about Data Portability before, and looks like OAuth actually won.

HTML5 has been around for a while. Yes, it is still in draft form and the formal specification hasn’t been published yet, but that didn’t stop all major modern browsers from implementing a decent set of HTML5 features. By now, the web is chock full of HTML5 examples showing off everything from latest JavaScript to HTML5 markup tags. But people still seem to be on the edge when implementing them in real-world production environments. This should not be the case. The reality is that HTML5 features already implemented in modern browsers are mostly stable, and the published spec will ultimately not have major changes.

If there is still some doubt that HTML5 is still the “future” and is not needed in the current web, let me throw in some rough figures. Note, these numbers are taken from Wikipedia. So interpret them how you wish. Roughly 54% people still use Microsoft Internet Explorer (IE), of that ~ 36% is IE8. Making that 23% globally. About 31% use Firefox, about 80% of which is 3.5 or 3.6, making that 25% of the global market. Safari and Google Chrome take up another 13%, although I do not know what percentage of those browser version are HTML5 capable and in use. It can be assumed that at least half of the browsers out there support the commonly touted HTML5 features. So should we let half the people miss out on great features due to other people still using IE7 and Firefox 2?

Rolling out HTML5 may be easier than you think. Anyone who runs a commonly visited site probably already has different style sheets and/or JavaScript for IE/IE6 users. So pull in HTML5 JavaScript conditionally by checking if functions exists. It is ill-advised to rely on checking the user agent, as some browsers misreport it (i.e., IE8 in “IE7 mode” still has the window.postMessage JavaScript function).

Putting in HTML5 tags on the other hand is tricky. Putting in new tags such as <article> and <aside> won’t render properly in older browsers. The best way so far is to insert tags dynamically into the DOM using JavaScript. This isn’t practical for simple tags such as <article> but can be used for flashier tags like canvas. Existing libraries are already implemented this way. Cufon uses Canvas to render fonts in most browsers and VML in IE.

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.