As my employer goes through the process of figuring out how best to make our service work within the Facebook environment, one thing is becoming very clear to us.
A Facebook App is not a widget. It’s not simply a snapshot of our site’s content or functionality. It’s not a snippet that can be grabbed on one site and that can be pasted into another.
Building for Facebook requires a different way of thinking about your service. It’s not about identifying what content or functionality will work the best within a small footprint on a third party site, it’s about actually tying your functionality to the various integration points that Facebook has made available – the news feed, the friend relationships, the sidebar, etc - and building a full on feature.
In the twilight of the first Internet boom, when it became clear that there just weren’t enough Internet users to support the massive numbers of consumer facing start-ups (and not nearly enough online advertising $$), one of the things that my company did to try and stay afloat was to go “B2B.” Instead of trying to build a destination site business, we packaged our functionality and ratings platform up and begin to pitch it to more established companies.
This was typically a fairly drawn out process – especially for the larger and more established, “bricks & mortar” companies. We had to work through bizdev organizations with long sales cycles, marketing organizations, and finally, the client’s in house developers. We’d identify the client’s needs, the potential integration points where we could hook our rating service into the client’s website, and did our best to twist our website’s functionality to integrate with the client.
From an end user perspective, this “ASP” (Application Service Provider) model was not ideal. End users were forced to hop back and forth between domains, and things like login status, reconciling privacy policies, and synching data was a huge headache in those days. And it made for a lousy business (this is worth its own post).
Facebook’s platform offering is generations ahead of this sort of ASP architecture, and they've done away with the sales cycle and conference call pieces of the equation. However, the thinking involved in designing an application for Facebook is very similar to the thinking required in running an ASP business. But instead of Facebook’s marketing department deciding what Facebook users want, Facebook users decide.
I think that my initial unease with the Facebook platform was due mostly to the fact that I was evaluating it as a widget play.
And this is not a widget play.
With widgets, users drive the Internet wide implementation and distribution of third party content / functionality. With Facebook’s platform, implementation is managed by developers and can entail far more than just a snippet of content, and distribution, while still driven by end users, is limited to the Facebook universe.
These are two different beasts within the broad framework of building distribution / syndication for your web service. It took me a couple of weeks, but I think I’m finally coming to terms with this.
Comments