Since we helped launch a rather complex MySpace application for the Travel Channel early last week, we have learned a LOT about hard core OpenSocial development (on MySpace in particular). Unfortunately there are very few resources available out there to build that have built and understand how to built world-class scalable applications for MySpace! Most of the me-too apps currently put together do not take advantage of any of the rich features the OpenSocial platform has to offer and are buggy and/or simplistic.

During our development process there was really no resources to turn to when we ran into problems, we simply had to solve them ourselves. None of our colleges in the social media have really cut their teeth yet with OpenSocial, so it was basically us. Today we got a call from a fellow developer in Canada working on a similar large project and in a couple of minutes were able to help him out with some of the problems that previously took us days to solve.

Based on that experience, we have decided to create an internal OpenSocial Development Support Collective – a group of OpenSocial developers (we are currently limiting the number to 10) who have similar experiences/expertise on the OpenSocial platform and who can share development best practices and know-how, and when necessary - pick up the phone and call each other. We have used this model effectively before and it makes a lot of sense given that we work closely with other social media developers and marketing agencies on large projects so collaboration has always been key to our success.

If you are an OpenSocial developer (or social media development house) that has successfully developed and deployed one or more applications on the MySpace, Orkut or Hi5 platforms, and would like to join our collective, please contact me.

We just launched an OpenSocial application on MySpace yesterday and boy, OpenSocial on MySpace (even in 2009) is hard to do (right)! For the few and brave interested in MySpace Apps, here are a couple of pointers:

1. Pick the Right Surface Model
OpenSocial panels (Canvas Surface, Profile Surface, Home Surface) can support content from a number of sources including inline HTML/Javascript, inline Flash or external iframes. Not all surfaces support all sources and not all resources are available to all sources. OpenSocial’s core Javascript API is only readily available if you use inline HTML and Javascript, but very few web developers want to write an application entirely in Javascript! Using external iframes (available on the canvas surface) works great – but you then you are forced to use the MySpace REST API (good luck getting it to work). You are almost forced to use session cookies to keep track of the user, unfortunately there is a good chance Internet Explorer 7 will block your cookies because you are using iframes in mixed environment! Important OpenSocial/MySpace Javascript functions such as invite friends do not work in iFrames without some serious workarounds!

2. Remember – Some of This Stuff is in Beta
The MySpace app development environment is a bit tricky to use. Uploading for App XML for example, will wipe out your App source settings (which you will have to re-enter each time you upload your XML). It also wipes out the large icon and sometimes resets the OpenSocial version API – so be careful! We could not get the official MySpace REST API and I personally don’t know anyone who has.  We figured we could probably eventually get it to work, but found it faster to modify an existing unofficial MySpace REST API.

3. The Good News is that it Works
Yes, you an actually build and deploy a great OpenSocial application on MySpace. True, the platform is constantly changing and the applications we wrote six months ago are very different from the ones we are writing today, but its getting better and easier. The MySpace support team were very helpful and having gone through the process ourselves (and with clients) before, the approval process has very fast and folks were very responsive (Thanks Rondata and Nosheen).

Here are some of the strategies we were able to employ to successfully deploy the MySpace application:

• We used an external iframe for our canvas surface. This is a LOT better way to do than using OpenSocial’s equivalent of AJAX when developing a complex application (we had previously used this technique successfully but it does not lend it self to rich or heavy media usage).
• We create a page at the entry point of the external iframe that acts as a “Controller” that marshals out calls to other pages along with all the important data they need (which is only available at the “Entry Point”).
• To overcome the problems IE 7 supporting session cookies in mixed iframe/security environments, we limited the amount of information the application needed (ownerId and viewerId pretty much) and passed that around using query strings or accessed pages via the controller
• We got the friend invite to work using the suggested “iframe PostTo Workaround” in the External iframe IFPC call Demo after a good amount of trial and error. Apparently if you forget to register parameters to MySpaceContainer (or do it wrong) Javascript calls still “work” but your callbacks simply don’t fire.
• We were not able to get the official MySpace REST API to work so we would a decent unofficial API, updated it and got it to work.
• We used inline HTML/Javascript for the home and profile surfaces along with AJAX. This is a good and light way to go since all OpenSocial “AJAX” calls automatically pass along the application’s ownerId and viewerId, so do don’t have to look them up on the front or backend!

Next week I will talk about some other OpenSocial development best practices so stay tuned.

It’s been a couple of weeks since I was last in the Google’s OpenSocial API. We are in the process of porting yet another Facebook application to MySpace using OpenSocial. Fortunately we wrote the original FB App with portability in mind.

Facebook vs. OpenSocial
The Facebook API and OpenSocial API use very different models making reuse very difficult. At its core, Facebook uses a Server-side proxied web application model. The Facebook server talks to your PHP-based application (which uses XML-REST API to get info from Facebook) and displays the results. OpenSocial uses a Client-Side Javascript widget model where applications are written in Javascript and get information via a Javascript API. Any external communication is done using an AJAX-like API function but all the logic is on the client-side.  As a result, the development models are very different for both!

Here are a couple of suggestions to make your Facebook applications more “portable”:

• Do not use the Facebook datastore, store preferences and application data in your own database
• Decouple “data” pages (pages used to generate data) from your Facebook application and access the data using includes or AJAX calls, make sure your “date” pages are stand alone and do not generate any FBML.
• Design your Facebook application to retrieve all data/information using AJAX.  This take my previous point to its logical limit but since OpenSocial users Javascript/AJAX for all of its data retrieval you’ll be in great shape.
• Organize your libraries to separate Facebook related functions

It seems everyone wants a quick and easy way to get their content or widgets on Facebook and other social networks, so naturally people sometimes assume that widget distribution engines like Clearspring and Gigya automatically get your content to these sites – this is usually not the case.  Here are a couple of things to keep in mind about the limitations of using ClearSpring to “share” widgets on Facebook:

• The Facebook link in the ClearSpring sharing menu does not by default publish your widget as a application on Facebook (see below). This “Post to My Feed” feature is very lacking!
• The only way to get a Flash Widget onto Facebook is to wrap your widget in a Facebook application. You can develop (or have someone develop) that from scratch or if you already have a ClearSpring widget, you can try using the ClearSpring wizard to publish your widget (but it has its limitations)
• Widgets ported using the ClearSpring wizard cannot be customized, so there are is no way to remedy some of the limitations (limited news feed support for example)

ClearSpring Facebook Publishing Illustrated:

Getting Your Widget on Facebook: Alternative Approaches
Facebook is a lot more than a “widget platform”.  In fact, unlike MySpace, Facebook doesn’t really lend itself well to supporting widgets of any kind (even Flash-based widgets). The best and most effective approach to “porting your widget” to Facebook is really to rebuild it as a Facebook application.

Alternatively, you can port your widget (both Flash and Javascript) by building a simple Facebook application around it that embeds your widget in an IFRAME (more info..). By building it yourself (or having us build it for you), you have a lot more control over user interaction, publishing information to user’s news feeds, email and other notifications as well as what actually appears on the user’s profile or boxes tab.

With the new user interface changes on Facebook, sticking Flash-content in a user’s Boxes tab isn’t very viral, and chances, few visitors will ever see it. Tommorrow I will spend some time discussing how to build Facebook applications that more effectively leverage the New Facebook user interface.

Quite often we get the request: “I want a widget”. Although most people making that request have an good idea of what platform they want their widget deployed on, some don’t. Here is a quick look at some of the common widget platforms options available, their pros and cons, and other important considerations:

• Flash-based Web Widgets: This remains the most common platform for widget development. Widgets built in Flash are generally designed to be embedded on social networks, blogs and other web pages (by simply cutting and pasting a snippet of HTML code). They can be distributed directly or using a Widget marketplace or distribution platform. About 80% of the actual widgets we build fall into this category.
  

• Other Web-based Widgets: There are a number of other web-based start pages, portals and communities that prospective clients are sometimes interested in developing widgets for. These include services like iGoogle, Windows Live.com, Pageflakes and Netvibes. Widgets built for specific web-based services are generally are generally not portable across services. We usually build widgets in a way that increases the likelihood reuse (since most services support some flavor of Javascript), additionally some services, like Netvibes, have “wrappers” that allow them to be used in other start-pages.
  
  See more comprehensive lists…

• Desktop Widgets: Desktop widget platforms include Yahoo! Widgets, MacOS X Widgets, Microsoft Vista Gadgets and Google Desktop Gadgets. Widgets built for these platforms are designed to run on a user’s desktop. As a result, they are generally are not spread virally or via “drive-by” marketing. Prospective clients evaluating or considering desktop widget platforms are usually driven by specific customer requests or applications. Most widgets built for a desktop platform require that the user first install a widget engine (Windows Vista and MacOS are exceptions), a process that can be time consuming and can pose a barrier to adoption.
  
  See more comprehensive lists…

• Facebook Application: Although a a widget can be embedded in a Facebook (FB) application, a FB app is “technically” not a widget – its a lot more. When building “widgets” for the FB platform, most people are talking about developing a Flash-based widget and then build a FB application to “contain” it (the are some limitations). The alternative is to ditch the widget idea and simply build a full featured FB app that takes full advantage of the platform.

  

• Other Social Media Applications: This involves building applications or “porting” existing Flash-based widgets to platforms like OpenSocial (for MySpace, Hi5, Orkut and others) and Ning. Unless you have a compelling reason for doing this, you are probably better off with one of the other options.
  
  See more comprehensive lists…

So What Widget Do I Need?
Hopefully you have already answered that question. The platform (or platforms) you select to develop and deploy your widget(s) on depends on the following:

• who your target customer is (consumer, customer, enterprise, prospects, i.e.)

• the purpose of the widget (marketing or utility)

• what your marketing or customer acquisition goals are (related to purpose)

• how you envision the widget being used and distributed (is it viral?, i.e.)

Clients interested in solving marketing, awareness and branding problems are usually interested in Web-based widgets (or social media applications) that are often seen, easily spread and hopefully come with a compelling reason for folks “driving-by” to spread them.

Clients interested in using widgets to deliver utility or functionality or extend an existing application, are probably most interested in Desktop widgets.

Clients that want marketing exposure on numerous widget marketplaces (WidgetBox, Netvibes, Yahoo! Widgets, i.e.) are probably going to want to build smaller (feature poor) widgets on a technology (Flash, i.e.) that works on multiple platforms.

Clients targeting “paying” or enterprise customers are probably looking at specific desktop widget platforms.

More Widget Platform Information
I hope this answers some of the questions people about widget platforms. I have also created a section (wiki.metablocks.com/widget-platforms) on the Metablocks Wiki dedicated to tracking relevant widget development platforms, feel free to check it out.

Tags: facebook, opensocial, ning, widgets, flash, google, netvibes

MySpace is finally ready to launch its OpenSocial-based development platform. According to Mashable, developers can now submit applications for review and the first set of approved applications will be available to users on March 13! In January, I talked about MySpace and OpenSocial in one of my previous post Facebook Platform vs. OpenSocial. Although it was announced last November, Google’s OpenSocial partners are only starting to launch their platform initiatives with 3 large sites (MySpace, Google’s Orkut and Hi5) launching over the next month! MySpace’s Jim Benedetto did a great job at the O’Reilly Graphing Social Patterns conference outlining MySpace’s upcoming platform’s strategy.

When Facebook launched its f8 application platform it experienced a 37% increase in growth and the number of available application quickly grew to over 10,000 by the end of year. It is going to be interesting to watch MySpace’s OpenSocial platform roll out as far as the number of applications being developed and if they do indeed bring users back to the site.