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.