We have started to notice that Google is continuing to improve the indexing of Flash objects (SWFs). They seem to be doing a fairly decent job, but since many Adobe Flash developers are unaware of this fact, much of that content is jiberish (variable names, stage elements, i.e.) in spite of the fact that Google says they are using an ‘interaction’ algorithm.

Here are couple of thoughts and recommendations:

• Google’s spidering of Flash content will come as a surprise to many. Developers or publishers who do not want Google to expose the contents of their Files should consider updating their robots.txt files (Disallow: /*.swf$)
• Developers who wish to potentially enhance their Flash or widget SEO, should consider putting “meaningful” content on the main stage of the Flash objects and cleaning up any placeholders or default text

Adobe AIR brings unique and attractive features to Flash widget developers. First of all, it’s cross platform; secondly it provides access to both web and desktop resources and thirdly, it comes with a great security model that allows you to write power yet secure widgets.

Sandbox Model

AIR applications can be built using both  Flash and HTML/AJAX and can also leverage PDF for document rendering. The Adobe AIR sandbox restricts unauthorized access to the system files by AIR application. One application cannot access another applications secure files. Adobe comprehensive sandbox model include support for both application and non-application sandboxes. AIR also supports a special mechanism called “Sandbox Bridge” which allows non-application-sandbox files to access the properties and methods of files in an application sandbox.

Support for Code Signing

Adobe AIR applications must be signed by a code-signing certificate. Adobe recommends that developers use a commercially obtained code-signing certificate, as opposed to self-signed certificates! This support for digital code signing ensures developers are who they say they are!

Data Encryption
For added security, Adobe AIR enables apps to store  encrypted data (using AES-CBC128-bit encryption) in a separate location. Since two applications cannot share the same encrypted store, sensitive files are secure.

HTML Security
The security model for the HTML application sandbox in AIR differs significantly from the sandbox available in the browser.  Adobe AIR locks down certain Javascript functions to prevent malicious code from harming a user’s file system. Additionally,  untrusted scripts are added restrictions.

Resources:

• Introducing the Adobe AIR security model
• Adobe AIR HTML Security FAQ
• Adobe AIR Security Concerns

Since I get asked this question a lot, here is a quick round up of the more popular widget marketplaces, builders and distribution platforms (at least the ones that matter most):

1. Widgets to not appear to feature a full range of sharing options
2. SDK is not publicly available and adds functionality to the SproutBuilder

I predict that 2009 will be the year widget ad networks become a reality. Companies like Clearspring, Widgetbox, Gigya, SpringWidgets, and iWidgets have provided free widget distribution and/or development platforms for a number of years. Expect that to change in the future.  Widget platform providers are externally and internally experimenting with mechanisms to monitize their previously “free” services (ClearSpring announced their widget ad network in Dec 2007, Gigya announced theirs in January). The monitization trend makes senses, Web 2.0 companies have to figure out how to generate revenue, and with where the economy and financial markets are today, there is not better time to start than now.

Expect to see the following types of ecommerce models being applied to widget distribution.

• Recommended and sponsored widgets channels
• In-Widget advertising
• Mini ad banners within widget sharing menus
• Trial and premium widgets
• Premium widget delivery and tracking
• Paid widget distribution

There seems to be a lot of confusion about how to get Clearspring integrated into your widget using the In-Widget API model (which is the only way to go if you developing a ‘professional widget’). I decided to outline the basic steps involved

Adding a Widget:
First you will need to create a Clearspring widget (this assumes you have already created your Clearspring account).

1. Click Add Widget.
2. You will be given 3 options: In My Widget, On My Webpage and Using the In-Widget API. Select Using the In-Widget API.
3. Enter the informaton for your widget including its name, code type, sharing menu type, colors, sizes and other options.
4. For Share menu you want to choose Default Menu or Just Tracking
5. Under What Do you Want to Share enter the embed HTML for your widget
6. Next, Clearspring will provide you with some sample code for your widget (under Grab your Launchpad advanced code!). The sample code isn’t the most intuitive but its a good start. I will try and share some “actual” code you can use in a future post.

Editing A Widget:
Now you can further customize/edit your widget. The primary tabs you’ll work with are:

1. Template Content
   This allows you to modify the HTML embed content that is generated when user’s share your widget. This is the same content you entered above in the What Do you Want to Share section.
2. Library Code
   This is were you can get the code (AS3, AS2 or Javascript) for your widget. This should be the same code generate at the end of the Adding a Widget process.
3. The rest of the tabs can generally be safetly ignored unless you want your widget to appear/live on the Clearspring site.

Modifying for Flash/Action Script Code:
There are 4 steps involved in actually implement Clearspring sharing and tracking within your widget.

1. Imports
   You need to make sure you have correct imports at the top of your code. Common mistake is to forget this step.
2. Initialization
   You need to initialize the Clearspring Flash API before you can do anything with it. Go head and initialize it in your Flash code. Hopefully you can figure out how to do this using the sample code.
3. Share Menu
   To call the share menu, you’ll need to create a share button, attach a click event to it, and add a click function that looks something like this:
   
function on_share_click(event:MouseEvent):void
{
kernel.menu.show();
kernel.track.event('ClearSpring Share'); // custom event
};
4. Tracking
   When ever you need to track something simple use: kernel.track.event(YOUR_EVENT_NAME_HERE);

Easier said than done but hopefully this provides a good start and helps you avoid some of the common mistakes (choosing the wrong model, working in the wrong tabs, missing a key step) that many of the folks we do Clearspring widget consulting run into!

The Adobe  AIR  runtime was designed to allow developers to use Adobe Flash and FLEX to build “rich media” applications that run outside the browser on multiple operating systems. Today, a vast majority of web widgets are written in Adobe Flash.  This allows them to run on a broad range of social networking, community and blog sites. Creating Adobe AIR versions of these widgets enables them to function as desktop widgets with very little extra work.  In the past, developers had to package Flash widgets on one of the desktop widget platforms (MacOS, Vista, Yahoo! widgets, i.e.) or use ZINC to create destkop version of their widgets. Some of these options were limited to certain platforms, while other options were cumbersome or expensive.

Adobe AIR is looking like a very attractive widget development platform. Like the recently updated Yahoo! widget engine, AIR supports WebKit, SQLite, XML, AJAX and Javascript.  Like the Yahoo! widget engine, users have to download and install the Adobe AIR runtime (approximately 15MB vs Yahoo’s 23MB).  Additionally, Adobe AIR runs on Microsoft Windows 2000; Windows XP; Windows Vista Home Premium, Business, Ultimate, or Enterprise; Mac OS X (10.4, 10.5); and Linux – pretty much everything! More to come on Adobe AIR widget development!

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.

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.

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