We do widget, and as anyone who creates or user widgets knows Adobe Flash-based widget have dominated the social networking and media landscape for many years. With the advent (and growing popularity) of the Facebook Platform, many thought that Flash-based widget would quickly and easily make their way, unfettered, unto Facebook pages, but this has not been the case!

Flash does work on Facebook, but with some limitations. For companies and developers looking to port their Flash-ware to Facebook, here are some important considerations to be aware of:

• Facebook does not support Flash to Javascript communication
• Interaction between Javascript or FBSJ and Flash is prohibited. You’ll have to use flashvars to pass information into your Flash component.
• Facebook does not support Flash links/navigation
• In more technical terms, navigateToUrl and getURL by default do not work in Facebook (See work around)
• You have to embed your Flash in an IFRAME in order to enable navigation to work.
• Facebook and Flash have a problem sharing the same session
• In less technical terms, writing Facebook/Flash applications that recognize a user’s unique activity require some hard work (and experience).
• Flash cannot automatically begin playing on a user’s Facebook profile page
• Flash components cannot automatically begin playing on profile pages, so the fb:swf tag displays a developer-specified place-holder image until the user interacts with the object.

Today we got our long awaited Hillcrest Labs reference kit. We are probably one of the first third-party developers on the new platform and would like to thank the good folks at Hillcrest Labs for the opportunity! For those not familiar with Hillcrest Labs, the company is the pioneer behind the first pointer–based, award-winning interactive media system for TV. Basically it’s a pretty cool HD set top box with a unique 3D controller that developers can write software for!

I must say, I was most impressed by The Loop, the innovative 3D controller based on the company’s Freespace motion control technology. It’s not only easy to use, it’s extremely accurate and actually fun! (This would make for great game controller!). Having used a number of 3D controllers in the past, this puts them all to shame. You can visit Infinity Labs for a demo of The Loop. The setup required a HD TV (so I had to bring one in from home) but otherwise it went pretty smoothly and by the end of the day I had successfully created my first “hello world” application!

The Hillcrest Labs development environment is interesting. It basically uses the Javascript language (which we have a lot of experience in) for interactivity/programming and its own flavor of SVG – an XML-based file format used – for describing both static and animated graphics. SVG is a new experience for us, but we are big Adobe Illustrator CS users which can be use to read and write SVG using a add-on (plug-in) from Hillcrest Labs. Over the next couple of weeks we’ll be building some applications on the platform and we’ll let you know how it goes.

I have always been a big fan of Rapid Application Development (RAD). Wikipedia defines RAD as:

…the term and its acronym have come to be used in a broader, generic sense that encompasses a variety of techniques aimed at speeding application development, such as the use of web application frameworks and other types of software frameworks.

In the past, the key to a lot of rapid application development has been the use of software frameworks or toolkits. Unfortunately these types of frameworks are sadly missing when it comes to widget development.

Recent entrants in the space have failed to deliver compelling widget RAD solutions for a variety of reasons. First and foremost, most of them (such as WidgetBox and ClearSpring) are marketplaces or distribution plays and have no real intention at being or becoming a toolkit! Although both WidgetBox and ClearSpring have things such as “Facebook App Generators” or accelerators, these simply try and stuff existing Flash-based widgets into new social networking platforms and are not toolkits per se. Others like KickApps see themselves as hosted, white-label platforms! The closest thing to a widget toolkit is probably Sprout Builder, but its feature set has limitations, some find that its “development” environment is complex, and users have no control over the memory footprint or branding.

In general, here are some problems with many of today widget toolkits:

• Branding: Most toolkits (as well as “wrappers” from WidgetBox, ClearSpring and Sprout) have mandatory branding (that promotes their service) which cannot be removed.
• Size: Even if you can live with someone else’s branding, anything that is “general purpose” tends to be very large, and on the Internet size matters! I remember a recent client that tried to build a widget using one of the toolkits only to find that they had created a 500KB monster. We were able to recreate the same widget in 50KB!
• Cost: But wait a minute, you say, these toolkits are FREE! Unless you don’t put any value on your own time, then yes, is all free. Unfortunately the client I mentioned above had invested over 20 hours in the exercise, only to find out it didn’t meet their needs, and this does not take into account potential future support cost!
• Integration: None of the toolkits that I know of support any deep integration (other than an simple RSS feed) with client or third-party API’s.
• Tracking: Although a growing number of “toolkit” provider are starting to provide some support for traffic reports and analytics, this support is limited and cannot be customized or integrated with a customers existing reporting system.
• Support: Actually, the lack thereof. As you can imagine, most “free” toolkits do not come with support.

So what’s the alternative? At Metablocks, we build custom widgets to exacting brand, size and platform requirements. We have our own “internal toolkits” that speed up the process when it comes to things like XML communication, tracking and user interaction, but these are small and agile software frameworks that bring no extra “weight” (or wait) to the project. Obviously many of the things we do, cannot be duplicated with a general purpose toolkit. Thing like two-way communication (even within social networks), custom tracking and reporting, advanced video and audio support to name just a few. In addition, if something goes wrong, there is always someone there to fix it. If you have tried a general purpose toolkit and are less than pleased with the results, please give us a call!

Once you have a custom widget that works, THEN you can a marketplace like WidgetBox to distribute it. Remember that most of these companies (like WidgetBox and ClearSpring) are trying to solve a distribution problem, not a development or design problem!

Tags: widgets, widetbox, clearspring, sprout, flash

We recently ported a Flash-based game to Facebook and were faced with some of the challenges of the Facebook platform imposes on Flash apps, mainly the limitations Flash applications have when communicating with their “container” (the Facebook canvas page).

When building and integrated a Flash app with its container, many situations come up that require you to pass information into the Flash application (via Javascript or Flashvars) and get information out of the Flash application (via Javascript or a redirected URL and a query string). Anyone who has build a more complex Flash application knows what I am talking about! Unfortunately, Facebook doesn’t support the type of communication.

Since Facebook doesn’t support external communication via Javascript or FBJS, and since Facebook doesn’t support navigation by the Flash application (via navigateToUrl or getURL), it becomes difficult to convert more complex Flash/Flex applications and widgets into Facebook application.

Since we do a lot of Flash to Facebook porting work for clients, we have to develop workarounds to many of the problems that plague Flash apps on Facebook. Here is one such solution:

Enabling Flash to Facebook Book to Flash Communication:

1. Put your Flash application in an IFRAME within your Facebook Canvas Page
   You can pass information to your Flash application (located in the IFRAME) by passing a query string (<IFRAME src=”flash.php?value=x”…>). The PHP page in which your Flash application sits, picks up query string (“value=x”) and passes the parameters as a Flashvars to the Flash application (<EMBED src=”..” flashvars=”value=x” …>).
2. Your Flash application communicates back to your Facebook Application using getURL(”..”,”_top”,”GET”)
   Since your Flash application is in an IFRAME, navigateToUrl or getURL will work! The trick is to make sure you get using GET and setting the target to “_top”, the URL should be a URL to a Facebook Canvas Page (http://app.facebook.com/myapp, i.e.). This way your Flash application can pass information via a query string to your Facebook Canvas Page.
3. Your Flash Canvas Page picks up the information from the query string
   Voila you are done! You passed information into your Flash application (such a a username, i.e.), and you got information back from your Flash application (use as the high score, or test results, i.e.)! Complete 360!

If you having problems porting your Flash apps and widgets to Facebook, let us know! At Metablocks, we love solving hard problems, especially Facebook related ones!

Tags: facebook, flash