Snipe.Net Geeky, sweary things.

Big Changes to the Facebook Platform


Last night, during a webcast, Facebook announced some upcoming significant changes to the Facebook platform. Most are good, a few may be frustrating, but here they are. These changes will start to be rolled out in November & December and will continue into the first and second quarter of 2010.

If you develop Facebook applications, I strongly encourage you to check out their new Facebook Developer Roadmap, which breaks down upcoming changes in detail and let’s you know when to expect these changes to roll out.

I for one am thrilled to see Facebook finally trying to work with developers to give them a clear idea of what to expect and when. As someone who has spent the past two years writing Facebook applications and being frustrated by surprise platform changes, this is a giant step in the right direction from my point of view. Previously, it was not uncommon to get only a day or two’s notice – or no notice at all – regarding critical application functionality. If you’re the developer for one application, that’s inconvenient and annoying at best, if you’re obligated to maintain a dozen or so applications it can be utterly traumatizing.

From the look of things, Facebook is trying to streamline the way applications communicate with users, and is adding some features specifically designed to improve the flow of turn-based gaming and make it easier for users to find games amid the sea of applications in the app directory.

Overall, these changes bring new features to the application developer’s toolbelt, but changes to the newsfeed and Stream API also mean that several of the ways you were previously able to send messages to a user’s newsfeed/stream (the one you just updated in April to comply with their last round of newsfeed changes) will no longer be supported.

To put a finer point on it, if you don’t feel like extending your current applications to take advantage of the new features, you will still need to update them to get them to function as they currently do. If you do not update your application to use the Stream API, your application will NO LONGER send any messages to your users’ stream. More on this down below.

So here’s a quick run-down of what to expect in the next few months – I’m covering the issues that will affect current applications first, and then we’ll get into the good stuff that talks about new features and functionality, so you know what you have to update to keep your existing functionality before worrying about extending it.

Big changes to the Stream, old API not supported, templates disappear, new format

As I mentioned above, if you don’t care enough (or your clients are not paying you enough) to update your current applications with the new functionality these updates bring, you’re still going to have to spend some time in the code just to get them not to break.

As of December 20, 2009, when Facebook.showFeedDialog and feed templates are discontinued, if your application hasn’t been updated to use Stream.publish, Facebook.streamPublish, or FB.Connect.streamPublish, your application will no longer be able to send newsfeed messages.

These Stream API functions will be the only way to send messages to users’ streams and they are available right now, so I encourage you to start making the switch now so you have plenty of time to test and troubleshoot any issues that come up.

But wait – there’s more!

Stream stories will be rendered slightly differently, with only one image and few lines of text. Only the first image and first few lines of text will be rendered by default. A user can choose to expose the rest of the images and text by clicking a “See More” link.

Only one action link will be rendered, and it must be 25 characters long or less. “Formatting”-style characters (like “|”, “[“, “]”, and others) will not be rendered.


Key Policy Change: In order to encourage intentional behavior, you will no longer be able to automatically pop up a Feed form for a user unless that user has explicitly indicated that he or she wishes to share this information. According to Facebook, “a user should never be surprised by a Feed form”. You can continue to render Feed forms through FB.Connect.streamPublish and Facebook.streamPublish.

In the Stream Roadmap page, they outline when it is appropriate to open a feed form:

  • When the user has clicked a button that says “Share this”.
  • When a user has indicated via your user interface that they want to share. For example, if a user wrote a review within your application, and they checked a box that said “Share with friends” next to your “Publish this review” button. If you pre-checked a “Share with friends” box and they unchecked it, a Feed form should not pop up.

Perhaps more importantly, they also outline when you should NOT prompt the user with a feed form (and therefore NOT allow your user to post the action to their stream):

  • When a user takes an action that is a normal part of using your application, for example, achieving a new high score.
  • When you present a user with a result or new information, for example, completing a quiz.

These last two will directly impact how a LOT of Facebook apps and games currently function. While it will no doubt have an adverse impact on monthly active users for the applications that currently trigger stream entries on these actions, it is most likely a response of Facebook users complaining about the tremendous influx of stupid quizzes that have been flooding their newsfeeds for the past several months.

Hopefully, the other changes detailed below will offset the impact of apps not appearing in the stream as often and will more than compensate for any loss in virality.

Check out the Stream Roadmap page on the Facebook Developers site for full details.

No more Profile boxes or Boxes tab

That’s right. Poof. Going forward (in the short term) application tabs will be the only way applications can integrate into Profiles. We will be removing profile boxes, application info sections, and the Boxes tab. Facebook says they are exploring additional ways to enable developers to integrate into Profiles.

Please note that it does NOT appear that Facebook will be moving application content currently in Profile boxes or the Boxes tab into Profile tabs for you. From the Profile Roadmap page on the Facebook Developer’s Wiki:

Where will users’ profile boxes go?
Profile boxes will not exist in the near future. Application tabs will be the only way developers can integrate into the profile. If integrations on the profile are an important part of your application, we encourage you to focus development and transition to application tabs.

(Timing: Late 2009/Early 2010)

So it looks like if you don’t make this change to your application yourself and you rely on Profile boxes or Boxes tab boxes for your application to work, your app will effectively just disappear from user profiles when this change goes live.

Application tabs will shrink from 760 pixels wide (today) to 510 pixels 520 pixels wide to accommodate a slightly revised design. Boxes, info sections, and the Boxes tab will be removed in the near future. This kind of sucks, in my opinion, but I assume they’re doing it to accommodate a new design with either larger ads or some sort of right-rail navigation. Still, that’s a 250 240 pixel loss of real estate. Bummer.

Update as of Dec 15, 2009: According to a recently updated roadmap page, they will be shrinking the tabs down to 520 instead of 510. This, along with other profile changes, is set to roll out early 2010 by their last estimate.

Slight Application Canvas page layout change. In order to make it clearer to users when they are using an application created by a third party developer, Facebook is going to slightly modify how the top-navigation is rendered on canvas pages:


Looks like they’re still tinkering with ideas on the new layout of Application Canvas pages, but overall this shouldn’t impact most applications too much. They encourage developers to periodically check the Canvas Roadmap page for updated designs.

Now then – we’ve covered all of the stuff that impacts your current applications as they are now. Let’s look ahead to some of the great new functionality ahead.


Developers will be able to ask users to share their primary email addresses. This is a big deal because it was previously verboten to collect a user’s email address without specifically asking them to type it into a form and submit it. (Timing: Nov 2009)

New Application Counter (woot!)

Roadmap_CounterThe application counter is one of my favorite improvements laid out in this roadmap and is just one of many steps Facebook is taking to position itself as a gaming platform.

You will have the opportunity to increment your count to indicate to a user that they should take an action in your application, for example, take their turn in a game, or see a comment from another user on content they created within that application.

The count can be incremented by your application, and when a user clicks through to the application, the count will be reset to zero.

As we continue to see an influx applications leveraging Facebook as a platform for RPG and turn-based gaming, it seems Facebook is getting behind the idea and beginning to provide specific features to encourage growth in this area. (Timing: November/December 2009)

Games/Applications Dashboards

In fact, apps that are games will be separated by category from apps that are… well, applications. Plus, users have access to two different Dashboards, one for Games and one for Applications.

The Games dashboard will have a number of features that encourage users to find games their friends and playing, and to stay active in games they’ve started, including:

Recent games: Facebook will prominently display games that a user has recently played, showing the application icon and application name. Clicking on a game will take the user to the game’s canvas page.

Game News: There will be a text field next to each game on the dashboard where developers can set Game News. This area is free form and targetable by user, e.g. “You are ranked 17th among your friends. Austin’s score is the next highest at 28,400. Can you beat him?” or, “Your pumpkins are wilting – water them soon!”

Your friends are playing: Facebook will display some of the games that your friends are playing along with information about relevant activities in the game.


According to Facebook, an app cannot appear in both the Games directory and the Applications directory, and they’ll be reviewing Games listed in the Games directory to make sure they belong there.

All non-game applications will have similar functionality (your recent applications, application news messages, and applications your friends are using) in the Application Dashboard.

Application Notifications

Facebook is removing application-to-user notifications and user-to-user notifications. Instead, they encourage you to use other channels to communicate directly with your users, and to enable them to communicate with each other about your application.

Communication between you and your users:

They encourage you to use Email (once the user has opted to share their email address with you) for things like product announcements, newsletters, or billing and transactional communication.

If you want to notify users about an action they should take with your application (like taking their turn in a game), incrementing the Application Counter will be a good way to notify them.

The application news in the Application Dashboard will be a great way to share a brief message with a user while they’re exploring the Dashboards. You’ll be able to target these on a per-user basis.

Communication between your users and their friends:

The stream is the most powerful way to enable users to share their experiences with all of their friends.

The new Share flow will give your users the ability to send messages directly to their friends’ Inboxes, with attachments predetermined by you. This will be the best way to encourage one-to-one and one-to-few messages between users, and is intended to replace requests.

Users will still be able to invite their friends to check out your application.

The estimated timing on this is approximately 30 days after you are able to start requesting a user’s email address. (Latest estimate: November/December 2009)

Open Graph API: Incredible potential, or not at all?

The info on Facebook’s Developer page for this is a little vague at best. They state:

The Open Graph API will allow any page on the Web to have all the features of a Facebook Page. Once implemented, developers can include a number of Facebook Widgets, like the Fan Box, or leverage any API, which enable the transformation of any Web page so it functions similar to a Facebook Page.

For example, AwesomeTees might decide that strategically they would like to locate their brand identity at AwesomeTees will install the Fan Box widget, which will allow any Facebook user to “Become a Fan” of AwesomeTees, thereby establishing an official connection to AwesomeTees. The user will then have AwesomeTees listed in their list of connections on their profile as Pages are represented today.

This isn’t that different than how it currently works, so that’s not really news. What is interesting is this one line n their description, further down:

Additionally, any content that AwesomeTees publishes on will show up in the stream on Facebook like it normally would.

Wait, say what? It sounds like they’re saying that news updates that would normally appear on a website, and would have to be manually cross-posted to a brand’s Facebook fan page will somehow automagically appear. I would have to assume they will require some sort of XML or JSON standardized format that website news announcements will have to be published in, but there’s little detail out on this just yet. This feature is a ways off though, with initial versions not expected until the second quarter of 2010.

And finally – Verification goes away as a brand, becomes universal for all apps

According to the Principles, Policies and Verification roadmap, Facebook is doing away with paid Verification and is extending it out to all applications.

On December 1st, 2009 we’ll retire the Verification brand, as we scale what was a voluntary program into a universal requirement. There is no longer a submission process or fee, and there won’t be distribution boosts as the product will move towards more intentional user sharing. Starting today, we will suspend the processing of Verification submissions. All apps must meet Verification Checklist expectations and will be subject to review at any time.

So this means while you no longer have to shell out big bucks for your app to be verified, it also means that Facebook will probably be more aggressive about making sure all developer applications do meet their verification criteria, and will yank your app with ir without notice if it feels like your app isn’t up to snuff.

Full Timeline

To give you a little more perspective, here is the timeline of the upcoming Platform changes, based on Facebook’s Developer Roadmap and originally compiled by InsideFacebook.Com:

Late October 2009

  • Simplified policies posted, verification program ended, and “extending verification standards to all applications”
  • Platform Live Status tool launching, which will show “updates on platform stability and load”

November 2009

  • New email permission API (developers can ask users to share their email address)
  • Access point to invites will be moved “to either a filter in Inbox or surfaced in the Application and Games Dashboards”
  • User-to-user Inbox APIs will be launched
  • Stream story formatting changes (1 image shown by default, few lines of text, 1 action link)
  • New “add bookmark” button

November/December 2009

  • Notifications API (both app-to-user and user-to-user) will be removed (note: Facebook says this will happen “30 days after email permission is available”)
  • Feed forms cannot be popped open without “explicit user intent” (note: this is a new Facebook policy)
  • Application bookmarks moving from the bottom menu bar to the left side of the home page
  • Counter API launching (counts can appear on home page application bookmarks)
  • Applications and Games dashboards launching
  • New application branding on canvas pages launching

December 2009

  • All stream publishing APIs beside Stream.publish, Facebook.streamPublish, and FB.Connect.streamPublish will no longer be supported (December 20)
  • Revamped developer site launching

Late 2009 / Early 2010

  • Requests API will be removed (note: Facebook says this will happen “30 days after launching new Inbox sharing”
  • Profile boxes will be removed (application tabs will be the only way to integrate into the profile page at that point)
  • Improved analytics and APIs launching

Early 2010

  • Open Graph API launching


So it feels like Facebook might finally, really be getting their shit together. This is arguably one of the biggest rounds of changes to the platform that we’ve seen in quite some time, and for the first time, they’re actually giving developers a head’s up and being very transparent about timing and impact.

All in all, the vast majority of these changes are great news for application developers. We’re getting tons of new features, new integration points and opportunities for viral engagement. The trade-off in what we’re losing seems to be well worth it, if all of these improvements come to fruition.

About the author


I’m a tech geek/dev/infosec-nerd/scuba diver/blacksmith/sword-fighter/crime fighter/ENTP/warcrafter/activist. I run Grokability, Inc, and run several open source projects, including Snipe-IT Asset Management. Tweet at me @snipeyhead or read more...

  • great summary, i'm liking where facebook is headed!

  • timeontaskva

    Allison, Thanks for this. I received an error message tonight that got me panicked. This post was the first item that answered my searches fro what was going to happen.
    Do you know if this will affect the static fbml apps much? I have about 30 fanpages for clients out there all using this one, and a lot. Some on a tab and many in the boxes? I fear I will lose them all, am I reading this change correctly?
    Would appreciate any guidance in this area….

  • You won't lose them all if you understand how to make yourself valuable to them. I'd bet that most of them have NO idea about the changes coming. Position yourself as someone who can help them take come proactive measures, instead of reactive measures, and you'll probably end up with more work (and trust) for it.

    This will affects static FBML on the following ways:

    – Boxes tab GOES AWAY. Make other plans. It will be gone.
    – Profile tabs GO AWAY
    – Page tabs lose 250 pixels – which means a redesign for most. If you're the one to break the news, they may well come to you for the changes.

  • I'm sorry, I meant Profile boxes, not tabs. Profile tabs are still there, but boxes that appear on a person's profile page are gone

  • timeontaskva

    Allison, Thanks for the info – I was not at all worried about losing my clients and am prepared already with a backup of the info – I just wonder when the boxes tab goes if the static fbml creations (which all show up in boxes generally) I have will still remain or will they be gone as well.

  • They'll be gone – looks like Facebook isn't going to move them anywhere. I mean, they'll still exist in the static FBML app, but they won't be visible anywhere.

  • I use an app on my profile page called Custom Profile Box to link to my fan page. I assume since that app is a “box” it will be gone. Do you know if we will be able to create tabs on our profile page? My guess is no, since fbml isn't available for profiles.

    Thanks so much for this article!

  • Pingback: Upcoming Facebook Changes to Boxes and the Box Tab that Will Impact Your Custom Fan Pages | (Anti) Social Development()

  • amidar

    facebook has progressed a lot over the last 2 years,hopefully with these changes we'll see a smoother api applications

  • Is it just me, but the option to message all fans seems to have disapeared from my facebook pages?

  • This bit is particularly troubling to me: “Application tabs will shrink from 760 pixels wide (today) to 510 pixels wide to accommodate a slightly revised design.”

    I've only been working with Facebook for a week or so and am already at my wits end with how stunningly obtuse it can be. My number one frustration so far is how application tabs work, or DON'T work, as is usually the case. I've got an app that I'm desperately trying to get to work within an application tab without having the interstitial “click here to enter the app” page, but FB is making it damn near impossible.

    So now, after all this work, I may have to scrap it or redesign it because FB decided to whack off 250 pixels? This is an app for a name-brand, it's amazing how careless FB seems to be, especially given the HUGE sums of money some clients are spending for these apps.

  • I know it's frustrating, but honestly, at least they told us in advance this time. SO many changes over the past year have been slipped in without anyone knowing in advance. Since I work with some high profile brand that spend a lot of money advertising on Facebook, the 4 days notice I *might* get in a best-case scenario was better than most people got.

    You unfortunately will have to redesign it once they push this change through – no way around that. But what's giving you trouble with the interstitial?

  • Well, I've blown two 12-hour days on this app so far, and the primary reason is I'm stubbornly determined to get as much as possible working on the app tab itself. This is a fairly simple app and I hated the idea of having to create a landing page just to get people over to the app canvas page.

    So I started running into the now-familiar pitfalls like not being able to use iframes in an app tab, not being able to force logins with require_login(), and having even the most basic javascript completely hosed by FB.

    I've ended up with some working Ajax calls, but one of them requires authorization. So the Ajax call is fired, the user is prompted to log in, and the Ajax callback (a PHP file) is run. Problem is, I need that php script to know what the resulting logged-in user's ID is. I can't for the life of me figure out how to get that. My guess at this point is that the script has absolutely no access to that data, whether from $_SESSION or $_REQUEST.

    So I thought, fine, I'll just require login before you can even see the app. Problem is, require_login() doesn't work on an app tab. You can't even have an app tab redirect to the app canvas itself. Seems I am thwarted at every turn.

    Is this what it will always feel like to be a Facebook developer? Any excitement I had about this project has turned to utter resentment.

  • To answer your last question first, yes – this is exactly what it's like being a Facebook application developer. You can always tell when I'm working on a Facebook app because the swearing in my Twitter stream increases x 1000 – which is impressive, since I swear a lot to begin with.

    I've done exactly what it sounds like you're trying to do for the (now expired) vitamin water Great Debate poll. The application lived in the boxes tab (so same require_login restriction). It was a poll where you had to click on one of the two basketball players names to vote which you thought was the best, it would log the vote and prompt to push a feed to the stream broadcasting your results.

    The way I did it was:

    The default state of the box, the bit that loads when the boxes tab is clicked on, was basically static. Divs were defined there that called the clickrewriteform/clickrewriteurl mock ajax functions.

    So it looked something liek this (hoping Disqus doesn't eat my code):

    <form id="form">
    <div id="preview">
    <input type="image" src="" clickrewriteform="form" clickrewriteurl="" clickrewriteid="preview">

    <input type="image" src="" clickrewriteform="form" clickrewriteurl="" clickrewriteid="preview">

    <input type="image" src="" clickrewriteform="form" clickrewriteurl="" clickrewriteid="preview">

    So there are three “hotspots” here – one for the image labeled Kobe, one for the image labeled LeBron, and one for the preview without voting.

    Then on the voter.php file, THAT's WHERE I pull up the FBID of the user:

    $facebook = new Facebook($api_key, $secret);
    $user = get_user();
    // SQL query stuff
    echo 'your vote has been counted';

  • Well, its not as much that FBML isn't available for profiles, its that the Custom Profile Box and Static FBML apps are not permitted to be added to profiles, only to pages. That is a setting in the application itself, so it would depend whether or not the application maker permits it.

  • Does this still work if the user wasn't logged in before clicking?

    On a side note, for some reason I had this idea this whole time that “Mock” Ajax was actually something that was deprecated. In all the Ajax docs in the Wiki, it never really mentioned it. I only really heard of it from other blogs and forums.

    But don't get me started on the wiki. My first day doing Facebook work, I got hung up for two hours one something because the syntax example in the wiki had typos 🙁

  • Well, they'll have to be logged into Facebook in order to allow the app in the first place, so that's not really an issue.

    Mock Ajax is not discussed much in the wiki, but as you said, the wiki is severely lacking. They are encouraging people do move to FBJS, but Mock Ajax is still supported.

  • That's where I'm getting hung up. Anyone can view the app and even do one of the Ajax calls without being logged in. Only the second call asks for authentication.

    So how do I make it so the app can't be accessed at all without logging in? Again, this is the 'require_login()' limitation I'm running into within application tabs. Sorry if I'm being confusing, it's getting late 🙂

  • When you use:
    $facebook = new Facebook($api_key, $secret);
    $user = get_user();

    That should invoke the API and prompt the user to login if they are not logged in. If you do not call the facebook library and attempt to access user info, it won't.

  • Sorry – I just realized that get_user is a function I came up with to handle the tab require_login bullshit. Here's the code:

    function get_user() {
    global $facebook;
    global $authorized;

    try {
    return $facebook->api_client->users_getLoggedInUser();
    } catch(Exception $e) {

    return $facebook->get_canvas_user();

  • I got this working:

    For both links, if I am logged out, it will prompt me to login.

    The canvas/tab page (index.php) content is this:


    require_once '../client/facebook.php';

    $appapikey = 'XXXXXXXXXXXX';
    $appsecret = 'XXXXXXXXXXXX';
    $facebook = new Facebook($appapikey, $appsecret);

    function get_user() {
    global $facebook;
    global $authorized;

    try {
    return $facebook->api_client->users_getLoggedInUser();
    } catch(Exception $e) {

    return $facebook->get_canvas_user();

    $user = get_user();


    <form id="form">
    Click Me!
    No, Click Me!


    <div id="preview" style="height: 200px; width: 400px;"><h1>Magic happens here</h1></div>

    and the test-ajax.php, the file the ajax calls, is:

    require_once '../client/facebook.php';

    $appapikey = 'XXXXXXXXXXXX';
    $appsecret = 'XXXXXXXXXXXX';
    $facebook = new Facebook($appapikey, $appsecret);
    $user_id = $facebook->require_login();

    // Greet the currently logged-in user!
    echo "<h1>Hello, <fb:name uid="$user_id" useyou="false" />! You clicked on button number ".$_GET['number']."</h1>";

  • Meh – sorry for all the replies – I wanted to get this sorted for you.
    I zipped up the working code – you can download it here:

    Just remember to:
    1 – Change the path for the facebook.php include
    2 – change the API key and secret to your own
    3 – In your application settings, under PROFILES, make the Tab Url “index.php” (no quotes)
    4 – in your application settings, under CANVAS, make sure your canvas url has a trailing slash, like

    They are not clear about the trailing slash nonsense, and it's screwed me up multiple times.

    Hope that helps.

  • Hyram from Ashtabula

    Does this box thing mean that “Pieces of Flair” won't display as a nice bold graphic alongside my profile material? That would be unfortunate, as I use that to display flair that makes my political leanings immediately clear to first-time visitors…

  • I DM'd you on Twitter, but again, I can't thank you enough for the help. Unfortunately, your example exhibits the same behavior I've been trying to work though. When I'm logged out of Facebook and I click on one of the buttons, I do get a login page. But after I log in, I'm redirected back to the app tab and nothing has happened. It's as if the click only served to log you in, but it feels like nothing happened.

    I guess what I'm hoping for is you click on the button, you get logged in, and when you come back to the original page, the Ajax-generated content is already there. Is this even possible?

    If not, my only option may be to immediately prompt a login before they see the app at all. Thoughts?

  • Have you tried setting a post-authorize url?

    If it carries your vars along in that url, you should be able to to make the index.php conditional. It passes _POST vars, but when testing you will want to dump POST, GET and REQUEST, since I've seen weird results.

  • Giving this some more thought, I'm not sure this is possible 🙁

    Ajax needs a click or some other user-trigger. So if you used the gateway approach you mentioned (assuming the post authorize url doesn't work), and you had one link that is a “click here to begin” type of thing that accesses a script that tags the api – same as the test-ajax in the file does, when it behaves as expected and the user is not logged in, it will return the user to the fan page with the “click here to begin” stuff still there and they'd have to click again once logged in to actually begin. This is crummy, but I don't know if there's a way around it. As long as you tag the API in the url of that click to begin link, it should ask the user to login. You can also tack on the require login parameter to the link to make sure

  • Yeah, I think this has been the crux of my problem. Meaning, why in the world couldn't the Ajax call be completed “as planned” after the login happens? The user clearly clicked to initiate it, and if login fails, it just fails. I think it's bad User Experience to allow the user to click on the button, have to log in, and then not provide any feedback as to why nothing has changed.

    So back to one of my other options, is there a way to prompt the user to log in as soon as they click on the app tab? Another option could be to do a check to see if the person viewing the tab is logged in, and if not, show some sort of semi-transparent representation of the app, with a 'click to start' button.

    Lord, working with Facebook feels like one giant workaround. Every time I see something that seems really brilliant, I hit three more really retarded roadblocks.

  • mike

    since feed forms are depricated.. will it still be possoble to have a user select multiple friends using multi-friend select and posting to them?

  • Thank you for your e-mail. I will be out of the office from Monday, November 30 until Friday, December 4 with limited access to e-mail and voicemail.

    I apologize for any inconvenience and will get back to you as soon as possible once I return.

    – Alison

  • David

    Please can you tell me what the effect is for gift applications ? Does this mean you will no longer be able to send a gift from one user to another user ? if a user decides to send a gift within an app to another user then does it have to send the virtual gift by email ?

  • I *believe* this should show up in the application's dashboard – but I'm honestly not sure yet.

  • I *believe* this should show up in the application's dashboard – but I'm honestly not sure yet.

  • twity

    pls.. help me to logged in my fb account

  • szajmon

    I tried to figure it out, but it's still not clear, Maybe somebody has the answer..
    The application boxes at profile pages are gone, that's okay. But what's with the fan pages? Can I add application boxes (particularly Static FBML) to fan pages after the change?

  • Yes, fan page tabs will still be fine (although the canvas is shrinking a little). It's only the profile boxes and Boxes Tab that are going away.

  • Pingback: Big Changes coming… Fix your FanpageBoxes right now! : Social Media Virtual Assistant | Twitter | Facebook | Blogs | Wordpress Website and Blogs |()

  • Thanks for the update.


  • Pingback: Catching Up with Folk Artist, Natalia Zukerman On Her Strategic Use of Social Media and My Annoyance with Facebook’s Frequently Changing Platform « Kraus Notes()

By snipe
Snipe.Net Geeky, sweary things.

About Me

I’m a tech geek/dev/infosec-nerd/scuba diver/blacksmith/sword-fighter/crime fighter/ENTP/warcrafter/activist. I run Grokability, Inc, and run several open source projects, including Snipe-IT Asset Management. Tweet at me @snipeyhead or read more...

Get in Touch