Facebook acknowledges testers exist!

Yesterday, Facebook made a pretty significant announcement for developers of Facebook applications. The announcement involved assigning roles for people on the application development team, and defining what they can and cannot do. As far as I know, it’s the first real acknowledgement by Facebook that Platform application development has moved mainstream and is no longer solely being done by guys in their basements (or lofts – this is Facebook after all). Traditional development teams building Facebook apps using traditional software lifecycle concepts are popping up everywhere. I’ve even see teams build apps on the .NET platform, as unlikely as that seems.

Facebook application development teams have always needed to register who was on the team with Facebook, so that those people could access, build, and test the application before it was released to the greater public. The problem was that belonging to the team was binary – you were either in or out, and only those that were in could access the pre-released app. However, all of the team members could view and modify the Application Secret, change the app’s URL, or throw everyone else on the team off. It didn’t matter what your actual job was, if you were on the list you had absolute authority.

The new Developer's Role dialog

Facebook has now changed that by allowing you to define the roles for the people on your dev team, and thereby limit what they can and can’t do. Here’s a list of the roles you can assign:

• Administrator – complete access to the application and all its settings
• Developer – can modify all technical settings and access Insights but cannot reset secret key, delete application, or add additional users
• Tester – can test the application in sandbox mode but cannot modify the application
• Insights User – can access Insights but cannot modify the application

This is great news, and is a step in the right direction to show that Facebook application development is growing up. I’ve done some consulting on testing Facebook apps, and have always been uneasy when I’ve been added as an applications “Developer”. I always felt uneasy about getting exposure and access to a company’s crown jewels, and asked to be taken off the list as soon as the gig was up. Now, I can be added as a “Tester” and gain access to only those priveleges that I need.

So let’s hope Facebook continues along this thread and provides more tools and services that acknowledge that Facebook application development is being done by teams that have real needs. For example, a real development team will want to stage any code changes before making them live (just like what Facebook does with the Beta Tier). Unfortunately, the only way to test this beta code is to register another application with Facebook so that the production and beta code can run in parallel. But registering a new application will cause a new Application ID/Secret to be created. This means that once the beta code is proven to be good it will have to be modified in order to be run as production. Bad bad idea, but it’s the only way that Facebook will let you do it. It would be nice if Facebook would provide some easy ways to deal with things like this, as well as other difficulties that large dev teams certainly encounter. Facebook – give me a call, I have lots of other ideas.

So what would you change to help your development team interact with the Facebook Platform more easily. Leave a comment to let us know.

Facebook Platform ecosystem – Now Supersized!

I often find myself discussing issues about Facebook applications with people who aren’t yet a part of the Platform ecosystem. They talk with me because they’re possibly interested in having their company play some role in it, and they’d like some data on the size of the opportunity. The questions I most often hear are “How big is the opportunity on the Facebook Platform? How many developers? How many applications?”.

My initial reaction is to answer “Huge!”, but I know that the question is really about quantity and not quality. Assigning numbers to these questions is often difficult, but the one “official” place to get statistics like this is Facebook’s Statistics page. Unfortunately Facebook updates the “big” statistics like the number of active users quite often, but the Platform stats has stayed static for quite some time. When I first began getting interested in the Platform two years ago, Facebook claimed that there were a million people worldwide developing for it. That number has stayed constant for a long time.

Until now. Facebook recently updated this page and now claims that 2.5 million of us are building on the Facebook Platform. However you look at it, that’s a pretty impressive number. They also claim that there are 20 million application installs done on the average day. Spread out over 500 million users, some quick math tells us that the average user is installing a new app once a month – also quite impressive.

Hopefully Facebook will update these stats a bit more often since they do show the viability for making a business case by working with the Platform.

Big changes coming to Facebook Platform

Today’s Developer Roadmap post by Facebook has outlined some big changes coming down the pike for Facebook Platform. Here are the big 3 changes (well, as far as we see them):

No new FBML apps

Facebook will no longer accept new FBML Canvas applications by the end of the year. These are the types of applications that launched the Facebook Platform way back in 2007 (the same year that saw the iPhone and The Simpsons Movie). FBML apps have a lot going against them, most importantly is the fact that there’s really no good reason to write them anymore. It used to be that developers who wanted to write Canvas applications had to choose between FBML and the simpler but not-as-powerful IFrame method.

But IFrame has now caught up and surpassed FBML in terms of power, so there’s really no reason why a developer building a new application in 2010 should even consider using FBML. There’s also another issue at stake here. FBML Canvas apps require all of the data traveling between a user’s browser and the application itself to be routed through the Facebook servers. This is a legacy design from 2007 that was done to give Facebook more control, and allow for user authentication, but it’s costing Facebook a lot of money to run these servers that do very little but act as proxies.

Since new FBML Canvas apps no longer provide any real value, and they cost Facebook a lot of money to support, Mr. Zuckerberg et. al. would like to just sweep them under the carpet. Looks like that’s what they’re doing.

Parts of the Classic REST API are being deprecated

Whatever we said about FBML apps is doubly true of the Facebook “Classic” REST API. Born in 2007, it now looks like patches upon patches with no coherent vision. It’s been so far surpassed by the Graph API that Facebook never even bothered to mention any non-Graph API support for their very important location updates yesterday. It’s been clear for a long time that this API needs to be put to rest, and deprecating parts of it is definitely the beginning. We can all say Amen.

OAuth 2.0 will be required for authentication

Another nail in the Classic REST API coffin. OAuth 2.0 goes hand in hand with the Graph API that Facebook would like to push everyone towards. Enough said.

Facebook has historically moved very quickly, which contributes to a good part of their success. Moving quickly means getting things out to customers quickly rather than perfectly and dealing with the consequences later. Today’s Developer Roadmapupdate is a good example of how to deal with those consequences, and will ensure that Facebook developers will continue to have loads of things to do as Facebook continues to innovate.

Location, Location, Location ummm…. Places, Places, Places

Facebook has just announced their long awaited location-based feature that they’ve called Places. Places is currently available from the Facebook iPhone app, or from http://touch.facebook.com/ if your mobile device supports HTML 5 and geolocation.

Places seems to be all about “Checking In” to places, a’ la Foursquare, although Places doesn’t seem to have the concept of “mayor” yet. In fact, it really isn’t so clear what the relationship of Places to similar services like Foursquare or Gowalla even is. On the surface, they’d seem to be rivals, but representatives from these other companies were on stage at the launch event. Everyone seems to be scratching their heads and asking “Why?”. Inside Facebook seems to think that everyone will play well together. On the other hand, All Facebook seems to think that Facebook is simply playing the proverbial cat that toys with the mouse before eating it. We seem to agree – Facebook is several orders of magnitude bigger than Foursquare and really doesn’t need them. Bye…

In other relationship news, Facebook has chosen to use Bing Maps instead of Google maps for well, mapping. Not a big surprise here, Facebook’s relationship with Microsoft > Facebook’s relationship with Google.

Facebook also seems to be making a big deal about privacy for Places. As if we’re all worried about Facebook’s use of our private data … There are also some safeguards to protect you from your friends playing pranks by checking you into the local strip joint, the free clinic, or Country Kitchen Buffet.

The name that Facebook chose for this service is also very interesting. Places vs. Locations. When you think about it, it makes sense based on the service that Facebook is providing. This service uses places (Katz’s Deli) as their atomically addressable entity as opposed to location (40° 43′ 20.33″ N, 73° 59′ 14.41″ W) which is far more precise, but amorphous. Facebook is clearly shooting at getting people to check in and tag real places to help fill up their Open Graph. This choice also seems to encourage developers to build location-aware applications around places and friends (since that’s what Facebook is all about) rather than real-time precise locations that one would need for say a citywide gaming application.

Which brings us to developers, APIs, and testing, the Raison d’être of this blog. Facebook is exposing user’s checkins to applications that use the Graph API (sorry Classic RESTful API developers – time to change). Currently, the only thing applications can get is checkin info using one of the following APIs:

GET https://graph.facebook.com/[checkin_id]

Gives information about an individual checkin

GET https://graph.facebook.com/[place/Page/user_id]/checkins

Gives a list of checkins that this entity has made. BTW, why can a place perform a checkin??

GET https://graph.facebook.com/search?type=checkin&access_token=ACCESS_TOKEN

Seaches for checkins

We’re told that an API to create checkin information from an application is on its way, or actually is in Double Secret Beta. Look for it soon, and then things will begin to get really interesting.