In the last year-plus I’ve been developing Facebook apps and tabs, I’ve uttered this phrase more times than I care to recall. I remember when I first started developing for Facebook, there seemed to be such promise in the idea that I could build the bulk of these apps in any language, on our own servers. There seemed to be a lot of freedom in that.

Then I started trying to build page tabs.

The problem with developing for FBML tabs is that Facebook sucks in your html, CSS and JavaScript code and then “sanitizes” it to ensure it’s safe. This includes things like renaming CSS id’s and classes, and all your JavaScript functions. They also only support a subset of native JavaScript methods, so a lot of JS you’re used to using is considered invalid. Seriously, you can’t even do a document.write() or alert() on an FBML tab.

So in order to do anything meaningful with JavaScript, you’d have to write it with their replacement functions. So the native method of:

document.getElementById(‘wrapper’).value = ‘test’;

would have to become:

document.getElementById(‘wrapper’).setValue(‘test’);

Seems not a big deal at first glance, but it can be a royal pain in the butt to test the code outside of Facebook. And forget about including libraries like jQuery.

Plus, there’s all the stuff that is considered “invalid” within an FBML tab. This includes things like certain CSS properties like @font-face and image maps (beats me).

To make things weirder, there were certain Facebook-specific tags that wouldn’t even work on a tab. You couldn’t, for example, embed a “Like” button on a tab or use Facebook’s own tag to embed an iFrame. While I know some of these rules and restrictions were tied to legitimate concerns about security and user experience, many just seemed arbitrary and stupid.

Then sometime in 2010 (I need to research the specific timeframe), they announced that page tabs would eventually be migrated to being iFrame-based. I’m telling you, based on what I’d gone through as a FB dev and hacking together working solutions for tabs, this was the best news I’d ever heard. It got added to the Developer Roadmap, and was originally slated for completion in Q4 2010. Well, the calendar flipped to 2011, and the roadmap got adjusted to say Q1 2011. I know must of us feared it would just keep getting pushed back or never happen at all. I also had concerns that Facebook would still find some way to screw it up, like maybe invent some sort of “faux” iFrame with crippled functionality.

Well, yesterday, out of the blue, I saw a new post pop up in the Developer Blog feed (which you’re all subscribed to, right?). It was the announcement I’ve waited for months to hear. They’d finally implemented iFrames in page tabs. This came alongside the announcement about page layout changes, but I won’t get into that part of it here.

So once I’d finished my cartwheels around the office and Twittering about this amazing news, I sat down to actually try some stuff out. I switched an existing sandbox tab to iFrame and it just started working. Through some R&D, I was able to use any JavaScript I wanted, loaded jQuery, added a working Like button with callback functions and more. This is Facebook development nerdvana, folks. It’s as if I’d been writing with a hammer and chisel and suddenly been given a word processor. I can’t overstate how big a deal this is for the future of Facebook app development.

But what does this all mean? It means that, as of yesterday (2/10/2011), you can now switch your page tabs into “iFrame” mode. So now, instead of your code being sucked in and displayed within Facebook’s sterilized sandbox, it all loads up in an iFrame straight from your own server.

To put this in perspective, here’s just some of the stuff we can now do on a tab that was not possible before (or not possible without major workarounds):

• iFrames (duh)
• Load external JavaScript files, including libraries like jQuery
• Use web fonts, with @font-face for CSS
• Embed Like buttons
• Embed flash video or animation without the need for an interstitial “click to play” graphic
• Launch JavaScript events on page load
• Easily implement multi-page navigation within the same tab
• Submit forms without having to do them via Ajax calls
• Set cookies and sessions
• Add Google Analytics tracking code (previously FB would strip it as invalid)
• You also won’t have to constantly be busting Facebook’s rigorous caching of css and images

See what I mean? There are other FBML tab limitations I’m sure I’ve forgotten about, but these alone have made building creative, functional tab experiences a real challenge.

This is why today feels like the dawning of a new age. Facebook has finally cleared the road. Now stop reading this and go make some kick-ass apps.

Update, 2.15.11: Today we started seeing iFrames in tabs not loading at all, and the new ‘signed_request’ parameters they added were missing some attributes. Even the sandbox tab that was working perfectly on the day of launch was acting like a regular ole FBML tab today. After some brief panic and some trolling through the comments of the original announcement, someone mentioned they fixed the problem by upgrading the page to the new layout. I switched our sandbox page, and everything started working again. I’m not really sure if this was the intended behavior all along, requiring you to upgrade your page layout before being able to use tabbed iFrames. But definitely good to know.

The biggest part of the conference, and CEO Mark Zuckerberg’s presentation, was the introduction of the “open graph” and Facebook’s new suite of social plugins. There are much better resources on the web to explain that stuff in-depth, so I’ll not rehash it all here.

The bulk of it revolves around adding social widgets, particularly the “Like” button, to your sites in an effort to extend the socialness of Facebook to the regular web. While this got a ton of hype and a lot of brands initially jumped on the “likifying” bandwagon early on, I never really had the opportunity to do a lot with it. Most of my time in the last year has been primarily building web apps within the Facebook platform. However, based on what I’d seen in the demos in San Francisco and how I saw people implementing it, I started to suspect most were probably doing it wrong. Or just didn’t understand its real usefulness.

It was only recently that I had an opportunity to do some R&D around how to properly set up your website for Facebook Like integration. And even though I’ve been in Facebook-Land for quite a while now, what I discovered really surprised me. Despite my usual, generally low opinion of the Facebook platform, I had to admit this is pretty damn cool.

With that intro out of the way, here’s how you do it…

At the f8 conference, Facebook announced this concept of the “social graph”. They described it as the interconnection of all social objects on the web, which could include web pages, Facebook apps and profiles, photo albums, videos, etc. The gist of it was that now everything could be made social, not just what was within Facebook’s walled garden.

One of the prominent examples they showed was that of IMDB.com (Internet Movie Database). They showed how a button that said “Like” could be added to an individual movie’s page, in this case The Rock. Next to the button, you’d be able to see if any of your friends liked it, and how many people total. When you clicked the button, it would register your affinity for this awesome movie (and it is) and write a message to that effect in your Facebook stream. If the “object” you liked was also a certain type, like ‘movie’ or ‘book’, it would automatically be listed on your profile as one of your faves as well.

In addition to IMDB, they showed a few other examples, like the Levis site, which was using multiple Like buttons per product page.

To aid in this “likifying” of the web, Facebook also revealed several new Social Plugins that made it dead simple to connect your pages to the graph. Not only could you easily drop code onto a page to generate a Like button, but you could show recent user activity, enable real-time chat and register users for your site.

All of this works by embedding simple iFrames and Open Graph tags to your web pages, essentially making them equivalent to Facebook pages.

That’s all well and good, but what does it give you, other than the satisfaction of seeing Like counts rise? Not a lot, especially if your site has tons of pages. Who has time to go through them all to track Likes? Not me. And can you act on that data in any meaningful way? Not if you just use the copy-and-paste social widgets, which is probably all most people really do.

But what if I told you that you could track all likes and shares across your entire website from one place, and target messages and ads to people that have Liked specific pages?

Okay, let’s start making Like buttons on your site actually mean something.

One of the first steps to making all this work, is to create a Facebook App that will serve as the main unique identifier for your site. All your pages will reference this app’s ID to tie them all together. And in addition, anyone you add as an administrator of that app will have the ability to view analytics (what Facebook calls “Insights”).

To do this, you have to be a “verified” Facebook developer. This really means nothing more than verifying to Facebook that you’re indeed a real person. You can do this by either confirming your mobile phone or adding a credit card to your account. Don’t worry, you don’t get charged anything. This step is annoying, but it ensures apps are linked to legit Facebook user accounts.

Once you’ve gotten verified, go to http://www.facebook.com/developers/apps.php and click “Set Up New App”. Here, you really only have to fill out a single field, which is the name of your app. Normally you’d need to fill out a bunch of other setting for your app, but this app is just a hub for consolidating all your site’s social data. Just keep this page open, because you’ll need the app ID that was generated for later steps.

The only other setting you might want to consider updating is the “Manage Users” area in the app editor. Here, you can add other users as administrators of the app, or simply Insights users. Anyone who is set as an administrator of this app will be able to view Insights for the domain and manage “liked” pages.

Onto the next step…

So how do we use this new app to track Likes, Shares and other data across our website? We link it up to our domain with some html. To start, go to the main Insights page and click the green “Insights for your Domain” button. In the dialog that pops up, enter your domain (i.e., mydomain.com), and in the “Link With” dropdown, select the Facebook app you just created.

When you select your app, you’ll see the sample meta tag change to list your app’s ID. Copy this tag, but don’t close the popup at this time. Now edit your homepage’s html code and insert this tag somewhere inside the element. Save the page and upload it back to your server.

Now click “Check Domain” in the Insights popup. If everything worked, the dialog should go away. You may have to refresh the Insights page, but you should now see your site listed under ‘domains’. Now, once your site starts collecting social data, you can simply return here and click ‘View Insights’ for your domain. Currently, you can see data for Likes, Shares, Feedback per Share, Reshare rate, gender, age, countries, cities and languages. Just be aware that it can take a day or so for Insights to start showing up. Facebook seems to be delayed by about 24 hours (or more).

The next thing you’ll need to do is insert the necessary meta tags into your site’s pages that Facebook needs to handle Likes and Shares. Minimally, they should include:

1
2
3
4
5
6

<meta property="og:url" content=“YOUR_DOMAIN”/>
<meta property="og:image" content="THUMBNAIL_IMAGE_HERE_50X50"/>
<meta property="og:description" content="DESCRIPTION_HERE"/>
<meta property="og:site_name" content=“SITE_NAME”/>
<meta property="og:title" content=“PAGE_TITLE”/>
<meta property="og:type" content="website" />

Pay particular attention to the “type” attribute. You really should only use “website” on the homepage. Most other pages will probably fall within one or more of the preset types, found here.

For example, if your site is for a fast food restaurant, you’d use either ‘restaurant’ or ‘food’. A bookstore would use a type of ‘book’ for product pages, a baseball team might use ‘sports_league’, and so on. If you don’t want to be as specific as that, there are a few more generic types, like ‘company’.

You should already have a meta tag on your homepage that looks like this:

<meta property="fb:app_id" content=“XXX” />

That tag should go on all your other pages. Even though anyone that’s an admin of your app can administer pages and view Insights, you can also add one-off admins on a per-page basis. Just add this tag, and include a comma-separated list of Facebook user ID’s:

<meta property="fb:admins" content=“XXX,XXX,XXX” />

Below is a screenshot showing how the Liked item will show up on a user’s wall, and where each OG tag is used.

Additionally, these tags are used whenever someone shares this page via Facebook:

If you want to test that your Open Graph (OG) tags are done properly and displaying the right thing, use Facebook’s Linter app. See an example here.

Lastly, you’ll want to make sure your tag contains proper namespaces, for example:

<html
xmlns="http://www.w3.org/1999/xhtml"
xmlns:og="http://opengraphprotocol.org/schema/"
xmlns:fb="http://www.facebook.com/2008/fbml" lang="en">

Now that we’ve laid the framework, let’s actually start implementing those Facebook buttons.

Before you start using FBML tags on your pages, you’ll need to install Facebook’s Javascript SDK, with code similar to:

1
2
3
4
5
6
7
8
9
10
11

<script>
window.fbAsyncInit = function() {
FB.init({appId: ‘XXX’, status: true, cookie: true, xfbml: true});
};
(function() {
var e = document.createElement('script'); e.async = true;
e.src = document.location.protocol +
'//connect.facebook.net/en_US/all.js';
document.getElementById('fb-root').appendChild(e);
}());
</script>

The first bit initializes the SDK and binds it to your app’s ID. The second function includes the actual Javascript SDK library from Facebook. It does this asynchronously so as to not delay other items loading on the page.

To implement a like button, you minimally just insert: <fb:like></fb:like> This will load a standard like button with default options.

The Like button can be customized with additional attributes. For example, this will change the word “Like” to “Recommend”: <fb:like action=”recommend”></fb:like>. This will show just a like button, with a numeric counter: <fb:like layout=”button_count”></fb:like>. See more options under Attributes here. Similarly, basic share buttons can be inserted on pages via: <fb:share-button type=”button”></fb:share-button>

Once these tags are added, the buttons should start displaying on your pages. All that’s left is to start doing something with that data.

When you go to a graph-enabled page, and you’re logged into Facebook AND you’re an admin of either the app or your Facebook ID is listed in the fb:admins meta tag, you’ll see an “Admin Page” link beside the Like button. You might not see it until you yourself have clicked the like button for that content.

Clicking this takes you to a Facebook page manager, much like you’d see when editing a fan/brand page. This has been created by Facebook specifically for seeing Insights on this specific page, plus messaging to users that have Liked it.

For example, let’s say you added a Like button to a page selling The Social Network on Blu-Ray. When an admin clicks that link beside it, they will see a page similar to the above. You’ll see Like counts and basic Insights activity (which may be delayed by 24 hours or more).

The coolest thing about this is that you can now message to anyone that’s liked this specific object. So if you write a status update about The Social Network, everyone that’s ever Liked that page on your site will see it show up on their wall, with a link back to the site. You can also geotarget status posts just like you normally would. For example, people that have Liked The Social Network that are in San Francisco. There’s also a page manager created for the root homepage as well.

So that’s it! There’s certainly more work involved in doing this the “right” way, but you get a lot more benefit than from simply scattering social widgets all over the place.
There are a few caveats and gotchas to be aware of:

• One note about page admin links, they will NOT show up if you classify a page as og:type=”article”. Facebook considers this a transient content type and won’t let you message against it.
• Facebook also caches OG meta data. So if you change it and do another Like or Share, it won’t appear to have changed. The cache can be cleared 3 ways:
• Every 24 hours automatically by Facebook
  • Loading the URL into the Linter tool
  • An admin Liking the page
  • Note, however that changes cannot be made forever. According to this page, og:type and og:title can only be edited initially. After 50 Likes, the title cannot be changed, and after 10,000 Likes, the type becomes fixed.

I hope this has provided some insight (no pun intended) into how to tie your site into Facebook and how you can leverage that information to stay in front of your customers.
That said, Facebook is notorious for breaking and/or changing things on a whim, so if a recent change has made anything in this article inaccurate, please let me know. And while I’ve been doing Facebook development for over a year now, I’m far from being the foremost expert. If I’ve made any mistakes, or you just have questions, please post in the comments.

At some point someone should’ve mentioned to Dennys, “Hey, you know you could probably spike your fan count by a couple MILLION in one night. Sound good?” That they didn’t either means a) nobody brought it up, or b) it was shot down by someone with no appreciation of the impact of such things. Or maybe they just don’t care about Facebook. I think a big factor in this is that “traditional” agencies still haven’t the first clue how to advise their clients on social media. This even includes a lot of digital agencies that only want to sell a client a website.

Throughout the game, I was reminded of when I first got into this gig. Around 1998 I built a website for a prominent local real estate agency in my town of Marietta, Ohio. At the time, I wasn’t doing anything very advanced, and the realty listings were powered by a third-party Perl script. I think I got a couple grand from the whole shebang, but it was 10 times better than what I was replacing.

Once the site launched, I made a lot of recommendations to them about how to promote the site. I pitched the usual stuff, but what I really hammered on was that they were insane if they didn’t put their web address on every single “for sale” sign on every property they had listed. They’d nod and acknowledge it was a good idea, but they never ever did it. I left Ohio in 2006, but my gut says they probably still haven’t taken my advice.

And here we are in 2010, the future, for pete’s sake, and clients are still compartmentalizing their media. This is our website and this is our broadcast ad, and ne’er the twain shall meet. Stunning.

It should be pointed out (as was pointed out to me), a couple spots included Facebook and/or Twitter logos. That’s great, but they were small and in the last tenth of a second of the commercial. Notice all Sears ads now have social media logos? WTF? Do you expect people to touch their television screen and go to your Facebook page?

What Denny’s (and others) should have done was had a clear social media call to action. Yes, we’re doing free breakfasts, but you have to become a fan on Facebook to get it. Or, tack on something extra, like become a fan and get a free cappuccino to go with that free breakfast. As of this writing, the Denny’s Facebook fan page only has 25,000 fans. In my experience with Facebook-based promotions (where I and my firm helped take a brand from 900 fans to 100,000+), I’m sure they could’ve multiplied that by a factor of ten or more tonight, easy.

Not sure when these agencies (or brands) will get with the program. As much as Facebook makes me roll my eyes sometimes, I cannot deny it’s become a force to be reckoned with. And it won’t be long before no brand can afford to leave it out of their strategy.

That said, as long as there are agencies bungling through this, firms like the one I work for will continue to show them up.