Filed under: dev — ayn @ April 23, 2008

[Editor’s note: This is the first in a series of developer blog posts sharing some of our technical insights. Enjoy the jargon!]

One of our clients needed an app for MySpace and also wanted it to be ready as one of the launch apps when MySpace launched their platform. I’ve compiled together some of the implementation gotchas we experienced along the way.

Platform Overview

MySpace has their own REST API that exposes their social network to app developers, there is an Open Social JavaScript layer that maps the MySpace REST API to the Open Social API. Initially, MySpace hosted all their apps for you. An app can be either a mixture of HTML and JavaScript inside an IFRAME, or a self-contained Flash SWF file. The MySpace Developer site has web forms for developers to copy and paste codes and submit them to MySpace. They now support an XML manifest like the other OpenSocial containers and Google Gadgets. An application has to go through a review process before going live, and revision of the hosted code have to be re-approved by MySpace subsequently.

Each application has 3 surfaces: Home, which is where you land on when you click the “Home” link from anywhere on MySpace. Profile, the user’s profile page, and Canvas, which is the application canvas page. You can have HTML/JavaScript or Flash on the 3 surfaces. MySpace also hosts popular JavaScript libraries such as jQuery to ease development, jQuery, IMO, makes coding JavaScript more like real coding and less of an art.

Back-end Integration

The only way for an app to contact an outside server is through the OpenSocial makeRequest() call, it takes a URI and some parameters, and it can make an OAuth-signed request to the URI. This is the mechanism I used to communicate between our server logic written in Ruby on Rails and the MySpace app. You can return JSON responses or plain HTML and render the outputs in JavaScript. The following is an example of a makeRequest call and its callback:

function new_user_check() {

  try {

    params = { METHOD : 'GET', AUTHORIZATION : gadgets.io.AuthorizationType.SIGNED };

    gadgets.io.makeRequest(

      "http://HOST/myspace/is_new_user",

      function (json_data) { proc_new_user_check(gadgets.json.parse(json_data.text)); },

      params

    )

  } catch(er) {

    trace(er.message);

  }

}

function proc_new_user_check(data) {

  if (data.new_user == "no") {

    show_spinner(data.spin_controls_html);

  } else if (data.new_user == "yes") {

    $("div#first_timer").fadeIn("slow");

  } else {  //non-owner viewing canvas

    $("div#non_owner").show();

  }

}

Security Restrictions

The MySpace apps guidelines define what developers are allowed to do inside an application. Eventually, they will turn on Caja to sanitize all JavaScript and HTML tags inside the app. Most of the popular apps now violate multiple items in guidelines to get around the lack of viral features in MySpace. We played it safe and actually followed the guidelines. For example, we are not allowed to put any links on the home and profile surfaces, the only official way to navigate out of those surfaces is to use the requestNavigateTo() call. Though plenty of apps have regular hyperlinks that bypasses this restriction. Also we are not allowed to embed Flash using the <OBJECT> tag or pass in flash params, instead they prefer a self-contain Flash SWF (uploaded to MySpace) that uses the MySpace REST API.

Gotchas

What I found very interesting is that the JSON responses from makeRequest() are encoded differently depending on which surface you’re on. On the canvas surface, the JSON response is stored inside a “text” field of the returned object, and you have to parse that back to another JSON object (see code above), but on the other 2 surfaces, the object returned is just a plain JSON object without the “text” field.

It is also important to note that as of the writing of this blog post, MySpace does not provide very many viral communication channels for their apps. The only thing we get is a feed item when your friends install an app, and you can utilize the home surface as a dashboard to update the user on activities. There is no way to send messages to users, nor can an app send invites to the users’ friends. There are sendMessage() and shareApp() calls in the OpenSocial specs for messaging and inviting users so hopefully MySpace will implement it eventually.

Conclusions

MySpace apps work a lot differently than Faebook and Bebo. There is potential for new types of features as all 3 surfaces can work together to bring a brand new experience to the users. It is a shame that there aren’t very many features in the platform right now for the apps to grow virally. It will be interesting to see how the platform evolve and also to check out other implementation of applications with OpenSocial.

Filed under: facebook — klep @

A client recently asked us for a summary of our thoughts on developing a Facebook application using Flash versus FBML. The vast majority of Facebook applications are written using standard web technologies and integrating into the Facebook experience with FBML, but Context Optional and many other developers have also used Flash in various ways where FBML is not appropriate.

Generally speaking, our opinion is that any application that can be done in FBML should be done in FBML. FBML applications provide a UI that is consistent with the rest of Facebook and take advantage of modalities that users are already familiar with. We advocate using Flash or a Flash+FBML combination primarily when the application has significant rich media needs or requires features that simply cannot be accomplished with FBML and JavaScript.

Here is our summary of the advantages and disadvantages of using Flash to develop Facebook applications:

Advantages of Using Flash

• We can provide an entirely customized experience, including non-web fonts, stylized UI widgets, transparency, and animation.
• Applications can play video, music, and other forms of media supported by Flash without requiring other plugins.
• Much of the work is pushed to the client side, potentially offloading tasks from our servers.
• There is slightly higher potential for re-using the application on other sites and/or platforms without a total rewrite.

Disadvantages of Using Flash

• The application UI and interactions will be unfamiliar to users, and that barrier may be too great to achieve wide adoption.
• A Flash app cannot take advantages of the built-in features of FBML, like the ability to render any user’s image without an API call or the ability to render standard Facebook UI elements.
• It is more difficult to make the small, incremental changes that are the cornerstone of viral growth for an application.
• By pushing work to the client side, server side control, monitoring, and logging are negatively impacted.
• Some users disable Flash, or generally don’t like it due to performance degradation on their browsers.
• Facebook imposes a strict set of security guidelines for Flash widgets and requires users to download a recent version of Flash if they don’t have it.
• The security of Flash apps is dubious without special code to avoid revealing the app’s secret API key.

In general, we have seen Flash worked best when it fills in the holes where FBML falls short. For example, one of our first applications was a combined FBML+Flash app that let users build a customized music player. The player was in Flash, but all aspects of customization, user flow, and viral flow were all in FBML. Successful apps that only use Flash tend to be the exception, rather than the rule, as seen with the popular Biggest Brain app.

Filed under: facebook — kevin @ April 1, 2008

One of the primary reasons for Facebook’s success is that its social communication channels make it near effortless for friends to stay in touch. By opening up their platform 10 months ago, Facebook exposed these channels not only to independent developers, but also creative brands and agencies.

In our work with such brands and agencies, however, it seems that some haven’t quite grasped the differences between a social setting and a traditional mono-directional one. For instance, many of the companies that approach us are looking to build applications that display RSS feeds through Facebook. There are some good arguments for it – it brings the content to where the viewers are (on Facebook) and makes the content easier to share. But it doesn’t recognize that most users are Facebook for a reason other than the brand: their friends.

Coca-Cola is another example – they built an app for Sprite calls Sips. The pitch probably followed the logic that as (fluff)Friends (a highly active virtual pet application) is popular, that behavior can be replicated in a branded virtual pet - a Sprite can. Apparently, given the number of users, this has proven not to be the case. Even though it’s a virtual pet, it’s not the brand (or lack of one) that has made (fluff)Friends so popular – it’s that it integrates so well into the viral communication channels of Facebook and let’s users interact with their friends in a fun and unique way.

So what’s a brand to do? Remember why users are on Facebook (their friends) and what makes Facebook successful (social communication channels). Applications that tie into users’ desires to interact with each other in a variety of ways – not just messaging but poking and social gaming and quizzes and comparing – tend to do well. Applications that aren’t better with a user’s friends . . . . well, what’s it doing on a social network?

Filed under: facebook — kevin @

Social marketing is a non-linear, viral, social, multi-directional, and interactive means of enhancing brand recognition and increasing brand engagement.

Social marketing is not simply buying a banner ad campaign that runs on a social network, nor is it a branded widget. Done right, social marketing takes advantage of all the viral communication channels on social networks to provide an engaging experience that grows non-linearly and organically over the life of a campaign.

For example, Electronic Arts (EA) contacted us last year to build a Facebook version of their Smarty Pants console game for the Nintendo Wii. [context] first ported the game functionality to the Facebook platform. Using 22k questions from the console trivia game, we built an online version of Smarty Pants by adding a timer, awarding users points for answering quickly, and advancing users levels for playing more games.  But simply porting the game would not have acheived EA’s goals, nor would it have made for an effective social marketing program.

Through the addition of social features: friend challenges, individual game rankings, and leaderboards of users’ friend, [context] was about to make the game flow smoothly from person to person, adding a viral aspect that would have been near impossible to achieve outside of a social network.

So what happened? Within 3 months over 300k people played over 2.5M games of Smarty Pants. This is 100% viral growth. Media spent: $0

Another example - Microsoft wanted to engage users on Facebook. Microsoft Office products aren’t particularly social, nor do they have inherent consumer appeal. But together with McCann Erickson we adapted a concept already popular on Facebook: the poke. Microsoft’s Office Poke application lets users throw staplers, steal chairs, shred documents, and fetch a donut – all as ‘poking’ actions on Facebook. In the first month over 100k users installed the application and sent over 40k branded pokes per day – and about half of the users joined through viral growth (not the media spend).

Why is this important? Because today I was speaking with someone who works in social marketing who was explaining to me that it didn’t matter how viral an application is; to distribute an application and encourage installation across social networks advertisers buy impressions from ad agencies on a CPM basis, and regardless of how effective the application is the advertiser is still getting its value through the paid impression.

But that misses everything that’s interesting and exciting about social marketing! What about the 2.5M games of Smarty Pants and the tens of millions of impressions that those games created? What about the 40k daily Microsoft Office-branded pokes? The value isn’t in the paid ad impressions – the value is in the FREE ad impressions!

Users discovering a console game or interacting with Microsoft Office 2007 messages via social applications are unique from most typical advertising in that:

1. Messages sent via friends inherently more engaging than messages received through banner ads
2. Consumers are spreading brand messages on the brand’s behalf (extending the media buy 1x, 2x, or 5x times)
3. Each action a user takes results in more branded messages disseminating through the social network’s viral communication channels – news feed and mini-feed stories, profile views, requests, etc. All free brand impressions.

Hence the vCPM is born: the viral CPM. The viral CPM takes into consideration all the impressions that derive from the ad campaign – both paid and non-paid. For example, let’s look at a $250k ad buy:

Traditional model:
Agency spends $250k on an ad buy at say $5 CPM. Over the course of the campaign shows 50M brand impressions. Great!

Social marketing model:
Agency spends $200k on an ad buy and $50k on a viral application (the new creative or ad unit). The $200k buy gets 40M brand impressions. Great!

But instead of leading to a microsite, the ad buy directs users to an app. Let’s assume the reasonable rate of $0.50/user through the ad buy. Now the app we’ve built has 400k users. Cool!

And if we’ve built the app in the right way, each user is inviting a friend, or two, or three. Let’s say two. Now we have 1.2M users of our app. Awesome!

And if the app is engaging, we might get a 10% daily active user rate, maybe at first. So let’s say 120k are using the app, and sending a couple actions per day that result in stories in the news feed, or requests, or messages. And if those are seen by a half dozen of their friends, then we have another 43M brand impressions from the campaign. Wow, that’s double what we started with!

And it gets better than that. Because these impressions are better received (because my friend challenged me to Smarty Pants), the interactions are more engaging (I’m actually playing the game, not just seeing the ad), and it’s ongoing – these calculations are just the first month, but the application now lives on, constantly generated news feed stories and branded impressions. For free.

So the vCPM for this theoretical campaign, over the course of 3 months (assume the app isn’t interesting and people lose interest and the app dies within 100 days), we’ve taken what was a $5 CPM campaign and turned it into a $1.5 vCPM campaign. Or said the other way, social marketing created over 3x the brand impressions for the same $250k (and arguably more valuable, interactive, and engaging brand impressions at that).

Social networks have created a new channel for non-linear, viral, social, multi-directional, and interactivee marketing. Existing units of measurement and pricing are falling short of recognizing the value of these social branded interactions, and are ignoring the value that viral applications can bring. Forget CPM or CPC, vCPM is the real opportunity.

Filed under: facebook — kevin @

People give a wide variety of reasons why they use Facebook – the UI is clean, their real friends are there, they enjoy reconnecting with old friends. But can’t people stay in touch with phone and email and IM? And what about sharing photos with Photobucket or Flickr or Kodak Gallery? What happened to Evite for events?

It doesn’t take too many years working in the Internet space to learn that on average users are busy, demanding, and follow the path of least resistance. Right now, that path is Facebook.

The social network is rapidly replacing many means of social communication because it makes those communications frictionless. Want to send a message? Just click on name. Sharing photos with friends? Just tag them in your uploaded photos and they’ll be notified. Want to invite people to events? Only a few clicks away. Forget about cutting and pasting dozens of email addresses.

Likewise, even if I’m not a content creator (most users aren’t), my friends’ photos and events are only a couple clicks away. I can quickly and seamlessly view all my friends’ photos and see what events my friends are attending. No extra usernames and passwords to remember, no need to log into various sites to keep up with my friends’ lives. Integrated (and automatic) news feed stories, notifications, requests, and messages that make it easy to share and effortlessly stay in touch with friends.

Frictionless!