FBML

The Facebook Markup Language can be compared to the “icing” on the cake that is the Facebook API. Although FBML is not completely necessary for writing a successful Facebook application, it brings to the table many features that make development on Facebook more efficient, and in the end, it makes life as a social applications developer much better. For instance, you may have previously retrieved the name of the user of your application through a simple users.getLoggedInUser API call on the server. But perhaps you’ve discovered that it’s not worth going through the entire process of authenticating the user on the server side and returning the application user’s name. Or, what if you want to further separate your presentation logic from your application logic? A name, after all, is not necessarily something that should be calculated or processed. You may want to have your HTML in a file that’s entirely separate from the files you are making API calls from, and therefore something as simple as a name might make sense to include with your HTML.

For these reasons, FBML can be an ideal tool for organizing your Facebook applications and, most of all, for reducing the amount of API requests you have to make to Facebook. One FBML tag on a page takes no HTTP requests off your servers in order to render, whereas a simple API call for the same information could take one HTTP request to authenticate with Facebook and another to retrieve the information desired. This additional overhead slows down your application, and in an environment where you could easily have millions of users using your app, you want to save every request you can.

FBML is a tool, a resource, for you as a developer to make your work in the Facebook API more efficient. FBML brings a lot of power to developers, allowing them to use API calls only when most needed. As I will show in the “Hello World” example in Chapter 1, an entire simple application can be created using FBML alone!

The intent of this book is to get you to the point where you, as a Facebook developer, can decide when FBML makes sense for your application and when you are better off using the Facebook API. It’s my hope that you can continue to use this book as a resource as your development skills mature.

Tip

One topic not covered in this book is the Social Network Markup Language (SNML) and the social networking website Bebo (http://www.bebo.com). SNML is a tag language extremely similar to FBML that works on the recently launched Bebo Developers Platform. However, Bebo also supports certain FBML tags, so this book should serve as a reference for developing on Bebo as well as on Facebook. I will update this book’s Facebook Page (http://page.fbmlessentials.com) with more information regarding Beboʼs SNML and supported FBML tags as this new platform progresses.

Keep in mind that the only FBML tags that Bebo does not yet support are <fb:mobile/>, <fb:visible-to-connection/>, <fb:attachment-preview/>, and <fb:is-in-network/>. Therefore, use this book as you see fit for your Bebo application development! You can read a great how-to article on porting apps from Facebook to Bebo (written by Blake Commagere, developer of the Zombies, Vampires, and Werewolves games on Facebook) here: http://dev.aol.com/article/2008/porting-your-facebook-app-to-bebo.

Developer Guidelines

Before we get started, we should go over some guidelines. Although there are no “official” guidelines for development at the time of this writing, other than the Facebook Developer Terms of Service (http://developers.facebook.com/terms.php), there are some unwritten rules generally accepted by the Facebook developer community. Some of these may not make sense for you until we get further on in the book, so you may want to bookmark this section for later reference. Taken from the Facebook Developer Wiki, the following rules were written up by a few developers outside of the Facebook organization (see http://wiki.developers.facebook.com/index.php/Developer_Guidelines_Manual):

Invites
  • Do not force a user to send invites.

    • Show the invite page after performing an action.

    • Make it clear the action has been performed, and that the user is not forced to send invites to continue using the app/perform the action.

    • You may also include a link to the invite page somewhere in your application.

    • Sending invites for an app using another app is prohibited by the Terms of Service (TOS).

    • Do not include users who already have the app installed in the friend selector (or variants).

  • Do not use invites for ranking purposes.

    • When using invites as part of an application’s function, such as user ranking, make sure there are other ranking methods that can replace invites.

    • Using invites alone increases the chances for the application, and the user’s rank within it, to lose value.

  • Do not use blocked markup, or attempt to use sketchy methods to gain a user’s attention in the Requests page.

    • Usage of CSS, large fonts, and other prohibited markup is looked down upon by the community. We highly discourage this.

    • Usage of blocked markup can also lead to the removal of your application.

Notifications/News Feed
  • Do not post every action your app makes.

    • Simply send/post when the primary function of an app is performed.

    • Too many notifications and/or News Feed stories increase the chance of an app being blocked and/or being viewed as a spammy app by users.

User Interface
  • Do not require install or login in the main canvas page.

    • Doing so increases the chances of the user not using your application, or just installing it and not using it.

    • We recommend you have a page that entices the user to use the app, but do not mislead the user with false data.

    • Show what your application does, not a simple “Add this app and you’ll see what this is about” or misleading descriptions.

  • Do not require both an install and a login.

    • Doing so is pointless. Only use one, as deemed necessary.

    • It is a nuisance to users, and probably lowers chances of actual app usage.

  • Do not use JavaScript alerts.

    • JavaScript alerts are annoying to the user, disrupt the smoothness of the experience, and do not fit in well with the Facebook user interface.

Naming
  • Do not use the same or similar name as an existing app without expressed permission of original author(s).

    • Using similar names confuses users.

    • It may be a copyright violation, when applicable.

In addition to the preceding guidelines, it is my opinion that you should conform to the following rules as well:

  • Keep your applications in a format compatible with Facebook.

    • Your application should feel like it is part of Facebook, with the same look, colors, and formatting.

  • Use FBML wherever possible to replace API calls.

    • This reduces overall overhead and shortens development time.

    • This also gives you a few more features, such as invite forms (covered later in this book), which aren’t accessible via the API.

  • Where FBML is not possible, render the page as FBML and use an <fb:iframe/> tag for the areas that need to be rendered outside of FBML.

  • Separate your presentation from your application logic!

    • This can be a huge timesaver for you in the future, and it gives you a single location in which to store your FBML tags without mixing them up in your code.

Get FBML Essentials now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.