Wishful Code

After facebook’s announcements last week around the new version of OpenGraph (version 3), many have been scared of an increased invasion of privacy about facebook recording and displaying, for the world to see, your activity as you browse around the web. Sparked by the release by certain media outlets of features where as you browse their websites each action is relayed to your facebook timeline.

Myth #1: Facebook is implementing this functionality

Actually, Facebook have only created an API for apps and sites to post actions to your history, and have done so in a very controlled way. The actions must contain an approved verb (eg: read/listened-to/played), an approved type (article/tv show/song) and cannot be anything outside of those bounds. The new actions API contains a sufficiently descriptive permission model for users of each app in front of that. It is the apps/sites you should direct your frustration at if you don’t want them to send every interaction you do to facebook. Indeed, I think these sites should offer more control – a compromise between fully automatic sending of actions, and a button similar to the like button.

In fact, facebook could have done so much worse. Due to the success of the facebook like button, facebook could have had the ability to record literally every article you visit on every site which implements the like button (lots) without asking for any persmission at all, or changing any code on your site. They had the power to know, without permission, everywhere a logged-in facebook user visits, but they chose to make this a push mechanism for content publishers. If you don’t like the fact that once you connect with Yahoo News or Spotify, every article you read or every song you listen to will be recorded forever on your Timeline, then you have to blame Yahoo or Spotify. Genius.

Myth #2: Anything I do on the web now will be recorded on my Timeline

Again, this depends on how media publishers intend to use facebook’s new API. Sometimes it will make sense to post actions without user interaction each time (listening to a song for example), and sometimes it won’t (imdb doesn’t know if you actually watched a movie, until you press their new watch button [this doesn't exist, I made it up]), but it’s all in the control of the publisher.

This is the evolution of the like button, the old profile Apps, and the facebook beacon combined

Facebook apps – the ones which created the mess of boxes and videos on people’s profiles, which quickly got removed a year or two ago allowed more identity to creep through, but in an extremely uncontrolled manner (developers could post pretty much any html in any layout they wanted). Now, developers don’t write any html on your profile – the actions your app sends to facebook are sent as data in a very specific manner, and how that is displayed and used on people’s Timelines is presented to you as 4 facebook-controlled options.

Like Button – as I mentioned already, the like button was a precursor to all this – 1 simple button which automatically likes a Url on the web. The like button could be reimplemented within the new OpenGraph API, but likely won’t be yet because of the fact you don’t need to give a website permission to have a like button which knows about you on it.

Facebook beacon – actually, facebook have been trying to achieve what they’ve done this week  for a while, starting with facebook beacon. Through that experience, it’s obvious Facebook learnt a lot about the direction they would need to take in order to get to their destination of becoming the central point for digital identity, sharing and discovery – and that direction is one where they share the resposibility with content providers.

Like it or not, this is the direction the web is going if you want to take part in its social features and, personally, I love it.

It’s definitely going to be an interesting time as we see how different content publishers embrace the new OpenGraph features – will wordpress.com implement an integration for their x hosted blogs? What about content publishers who have tried to do similar social/content mixing before – will iTunes give up on Ping and embrace facebook, or Microsoft connect Zune to facebook (their music and movie streaming is good but their social never took off)?

If Timeline is something to embrace as a cloud storage of my life events, and it’s to be a complete picture – then I’d like to see all the above, plus some interesting ways to push content to timeline from other mediums – TV shows and cinema, sports events (RunKeeper/MapMyRun), and trips for example, but I’d also like to see great tools for me to curate that information and powerful ways for facebook to amalgamate all my data, analyse it, and show interesting angles on my Timeline.

There are a lot of Facebook apps around, most of them existing either as a Facebook Application in order to use the Facebook API from outside Facebook or as an application housed within Facebook itself. The framework Facebook have set up is focused very much on these scenarios, and it provides for them well with its canvas. If you’re a heavy user of a particular app, you can even have an App expose a custom tab on your profile (or your page’s profile) to provide some data about you in the context of the app.

However, a lot of page owners want to have custom tabs for the sake of custom content, not to be integrated within an app. Facebook recently announced iframe tabs for Pages and with it, the deprecation of previous alternatives such as using static FBML for custom tabs on a Page.

Using iFrames has several advantages over having to use FBML since the tab is now capable of any front-end code, like being able to include any javascript effects (eg: jquery animations), embedded content or integration with other front-end services (eg: google maps or google analytics).

However, there are some limitations at the moment that make the whole process, or the possibilities around it rather limited. The main limitation is that a tab must be added through an app, and each app can only expose one possible tab at one Url.

In other words, for each custom tab, you must create and maintain a new application. Again, I can see the logic to this when thinking in an app world, but when thinking from a content context it becomes frustrating. For example, if I want to expose a CMS with a customisable amount of templates for custom facebook tabs, the best I can hope for, if templates which detect the Facebook Page ID are built and change the content accordingly configured, is to create an App per template.

In figuring out a development and deployment process for custom tabs on Facebook Pages, I developed a tab for Glamour.com’s 10th Anniversary which displays the first issue in it’s entirety, and only for users who participate within the Glamour.com UK facebook page. The page layout was designed by James Tenniswood who also put the entire magazine together inside the magazine viewer, powered by Issuu.