Facebook Developers

As we indicated earlier, today we are introducing new guidelines that will change how applications are ranked in the application directory. Currently, the focus is on total number of users, but going forward it will be based on user engagement. This is an important step in the evolution of Facebook Platform which will help drive the growth and distribution of applications that focus on user engagement and utility.

With a change this foundational to Facebook Platform's measurement, we want to make sure that you completely understand how we will be measuring engagement. We define engagement as the number of users who touch your application every day (measured from midnight to midnight each day).

These touch points are:
- Canvas Page Views
- Link Clicks in FBML
- Mock-Ajax Form Submission
- Click-to-Play Flash

The number of engaged users is calculated by putting all of these touch points together. We display this as the number of "Daily Active Users." Next to it we also show what percentage that is of the application's total number of users.

This change is part of our commitment to making Facebook Platform better for both developers and users. And, we hope that through this change, you continue to focus on creating engaging applications which add maximum utility to a Facebook user's everyday life.

At Facebook we're focused on making Facebook Platform a better experience for both developers and users. To that end, we're working on some changes that we're planning to roll out within the coming weeks that we wanted to be sure you know about beforehand.

Our goal has always been to develop an ecosystem where the applications that achieve the most growth and usage are the ones that are the highest quality and add the most utility to users' lives. We want to build our tools to enable viral growth in the most natural manner and let you focus on building fun, useful applications. With the upcoming changes, we hope to shift the balance more in favor of good apps, which we think in the long term is good for everyone. Users will get better applications, and users will be able to put more trust into applications, thus spurring further adoption.

So, with that in mind, here are some of the changes we're planning. We'll provide more details about how each one works when we're closer to rolling it out.

Profile Boxes

With the release of FBML v1.1 we've made some changes to how profile boxes display content. Most specifically, we've removed the ability to display profile content that the user isn't aware of. This makes it impossible for applications to hide things from profile owners. We did this so that the user is always aware of how they are expressing themselves to their friends through your application. This means no more yellow boxes that display "Add this app!" in the profile box without the user knowing about it. We think this will help users make more informed decisions about the profile boxes they choose.

Application Directory

This week you'll see us shift our application directory metrics to a focus on user engagement. This will help inform users as they make decisions on which applications to add as well as shift developer focus to engagement rather than total users. More specifics will be available as we roll out these changes this coming week.

Requests

We will be deprecating the notifications.sendRequest API method. In its place, we will provide a standard invitation tool that allows users to select which friends they would like to send a request to. We are working hard on multiple versions of this tool to fit into different contexts. The tool will not have a "select all" button, but we hope it enables us to increase the maximum number of requests that can be sent out by a user. The standardized UI will hopefully make it easier for users to understand exactly what they are doing, and will save you the trouble of building it yourself.

Notifications

Soon we will be removing email functionality from notifications.send, though the API function itself will remain active. In the future, we may provide another way to contact users who have added your app, as we know that is important. Deceptive and misleading notifications will continue to be a focus for us, and we will continue to block applications which behave badly and we will continue to iterate on our automated spam detection tools. You will also see us working on ways to automatically block deceptive notifications.

News Feed

Because News Feed is an important part of distribution for everyone, we hope to enable feed stories to be shown to users who haven't added the application. We'll also begin to optimize these stories into higher rotation amongst the other application add stories. But this addition is likely to be further down the line than the others.

We're constantly working day and night to make Facebook Platform a great place for you to build awesome things. We can't thank you enough for your dedication and support as we continue to iterate.

Today we are making a change that has to do with both technology and the philosophy behind the Facebook Platform.

One of the key parts of the success of the design of the Facebook profile is that the user is always aware of exactly what their profile looks like to their friends who stop by to view their profile. This enables users to understand exactly how they are expressing themselves to others by simply deciding whether or not they like an application's profile box and the content that the developer has decided to put into the box.

Right now, we have made a few FBML tags available that are causing users to not trust the content in the profile box. Tags such as: fb:if-user-has-added-app, and other fb-if tags. These tags are currently being used to deliver content to profile boxes which users are unaware of. Content such as big yellow boxes which say "ADD THIS APPLICATION!" or "ADD SOME OTHER APPLICATION!".

Starting today, these tags will no longer be available for use in profile boxes. We will be migrating FBML to version 1.1, and adding a new set of tags called fb:visible-to-. They are:

fb:visible-to-owner
fb:visible-to-friends
fb:visiible-to-user
fb:visible-to-added-app-users
fb:visible-to-app-users

As a side note, you can add a bgcolor attribute to any of these tags, but they must use solid colors from this list:
http://www.w3schools.com/css/css_colornames.asp

The semantics of these tags are a little tricky, so please read this section carefully.

Everything inside an fb:visible-to- tag is always rendered for every user that views it and is enclosed in a span. If the viewing user is in the set of users that the content should be visible to, then the span will be: <span> style="visibility: visible;"> ... </span>. Otherwise, the span will be: <span style="visibility: hidden;"> ... </span>

Additionally, the profile owner is *always* in the set of users that the content is visible to. So, the result of this is that the profile owner should always see all of the content that could show up on his/her profile to any viewer. This means that profile owners will always know about advertisements or other more malicious things ("Pictures of Alice that She Doesn't Want You To See", etc.)

An example of where using an fb:visible-to- tag would make a lot of sense to use would be on a wall-like app where the profile owner needs to be able to delete any post on a wall, and individual posts should generally be deleteable by the person who made them. This could be accomplished by putting the delete links inside a tag like <fb:visible-to-user uid="{person who wrote the wall post}">.

Consequently, it will no longer be possible to use the profile boxes as a place where you can securely distribute private information to anyone *including the profile owner*. This is because all content is always being sent to the browser -- some of it will be made invisible using CSS, but that content is still accessible to anyone who views the source of the page. If you have content that you want to keep private to only some users, then you will need to move that content to a canvas page.

Note that the following tags are *NOT* considered fb:if- tags and will still be allowed in profile boxes:

fb:narrow
fb:wide
fb:user

It is important to remember, you should almost always distribute the exact same content to the profile box that you would want both the user and their friends to see. This makes it easy for the user to understand what the profile box, and the content inside the box, looks like to everyone stopping by. The profile box is for expressing, on behalf of the user, what their interactions are inside your application. A good way to think about this, is Facebook Photos. Though it is now one of the largest photo applications on the internet, the profile box simply shows the two most recently updated photo albums. Or, essentially the last few interactions of the user inside the canvas pages.

Migration Plan
FBML 1.1 is available now. Start by wrapping your FBML in an fb:fbml tag like this: <fb:fbml version="1.1">My FBML 1.1 content goes here</fb:fbml>
- For 10 days, the default version of FBML will continue to be 1.0 (the current version). Anything published that isn't explicitly tagged with a version will be considered to be FBML 1.0.
- After 10 days, you will no longer be able to use FBML 1.0, and the default FBML version will be bumped to 1.1.
- At this point, even though canvas pages and new things published won't be able to use FBML 1.0, things published in the past using FBML 1.0 (either explicitly or implied) will continue to be rendered as FBML 1.0.

Hey folks - We wanted to give you a heads-up that we're designing a new promotional opportunity that'll give your users who aren't on Facebook yet a streamlined way to sign up on Facebook and immediately start using your Facebook application. Over the next few weeks, we'll try this out with a few beta partners, and will use their feedback to refine and improve the experience both for application developers and for our users. We're working to make this capability available to all Facebook developers as soon as possible.

Over the last few weeks we have noticed several developers misleading our users into clicking on links, adding applications and taking actions. While the majority of developers are doing the right thing and playing by the rules, a few aren’t – and are creating spam as a result. Going forward, if you are deceptively notifying users or tricking them into taking actions that they wouldn’t have otherwise taken, we will start blocking these notifications. The bottom line is that if the notifications you send are the result of a genuine action by a Facebook user and that action is truthfully reported to the recipient so they can make an informed decision, you should have no problems. If you do find some notifications blocked, it was probably because this wasn’t the case and we will be happy to inform you of some best practices by other developers that have prevented this issue.

If you've been blocked by us for deceptive notifications, the error message you will see is - 200 Permissions Error.