We recently developed a YAP app (I like the way that sounds) for a client. For those who are not familiar with YAP, Yahoo! describes the Yahoo! Application Platform:

The Yahoo! Application Platform allows you to reach our users and improve the Yahoo! user experience by building and deploying new experiences for them into Yahoo! pages, writing code the way you love to write it.

From a marketing perspective, it’s Yahoo!’s response to Facebook’s popular application platform and MySpace’s OpenSocial, but in many ways it is different (and it promises to be even more different in the future).

Here are some of the similarities and differences between YAP and other popular application platforms:

• Like Facebook, the YAP official SDK is PHP-based, and similarly both platform support development in Adobe Flash. Both also have their own markup languages (FBML,YML) and both support Javascript (FBJS,Caja).
• Unlike Facebook and OpenSocial’s “externally and internally facing” applications (seen by others and yourself), Yahoo! applications are “internally facing” (seen only by you) and thus are designed to work with My Yahoo! (and Yahoo Mail)
• Unlike Facebook and OpenSocial, very little interactivity is currently is supported on the front page/Small View
• The application metaphor behind YAP is probably more similar to those of “starting page” widgets for services like NetVibes and Pageflakes
• Sharing of applications is probably less intuitive than Facebook but comes “automatically” with each application (since it is built into the application chrome rather than the application itself for the most part)
• The YAP API supports OpenSocial 0.8, but in general its PHP API is less complicated (and less featured) than Facebook’s. Full support for OpenSocial is planned in the future

Developer Do’s and Don’ts:

• YAP’s Caja Javascript Sandbox is a bit unforgiving when it comes to spelling errors, and at the time we developed our application, there wasn’t a great way to debug these problems
• Be prepared to write your own XML parser (we did) since currently YAP’s flavor of Javascript limits some types of DOM manipulation. If you plan on using AJAX and XML, this may be an issue. I believe their JSON support is a lot better.
• Understand the limitations of different Views. The Small (front-page) View doesn’t support Javascript, Flash or IFRAMES, so interactivity is limited. If you want to update the Small View, you’ll need to periodically run a CRON job or use a Web Service. Plan on doing most of your “work” in the Canvas View, which does support Flash and Javascript (but not IFRAMES).
• AJAX and other communication and event-based calls will need to be done through OpenSocial 0.8, so previous MySpace development experience helps
• The Yahoo! developer forum does a fairly good job of answering questions so be sure to use it. The individuals responsible for evangelizing and supporting the platform did a phenomenal job in supporting our development efforts. The documentation was okay (navigation wasn’t great), sample code (at least when we used it) was okay as well but could have been organized a little better.

Conclusions:

• Developing on YAP!, as is the case with any new developer platform, was challenging but fun!
• YAP! holds a lot of promise as soon as Yahoo! was more aggressively promoting.
• Remember that for the most part, the platform is still in beta, so some of these issues have probably addressed.

A couple of weeks ago I was speaking with one of our clients about API design.  I has reminded of the conversation when checking out the YELP API this morning as part of working we are doing on a joint venture called SocialGrub. Pretty much every web-based service these days has some sort of API. An API, which stands for Application programming interface, is simply a mechanism that allows developers to get content from (or create it in) your service or application programmatically.  As developers, we all have to design them to be intuitive and easy to use (for other developers).  Here are some suggestions when designing an API:

• Call or method names should be intuitive, avoid long or confusing names
• http://api.test.com/getStore?id=1
• Support multiple file formats for output. Popular formats include XML, JSON, and serialized PHP
• http://api.test.com/getStore?id=1&format=json
• Consider having a JSON version (or serialized PHP/Phython) of your API. XML API responds tends to get large rather quickly. Consider using shorter node/element names (but try and keep them intuitive)
• Balance file size with node/element/method name intuitiveness
• Document your API, it always helps
• Include examples calls in your API as well
• When possible avoid keys for your API unless they are necessary
• Allows you to track/control usage but also adds complexity and time
• Provide platform specific SDK (PHP, C#, JS, i.e.) or sample code whenever possible
• You an also encourage your developer community to share their sample code and examples
• Study other API’s to understand best-practices, standards and get a good ideas of what developers will expect. 

Ever since our post on Facebook Integration touch points best practices went up, oddly we have a bunch of request for a large (screen saver size) picture of the Facebook Developer Ninja, so rather than email a copy to everyone, here it is: both a 1280px x 1024px version and a smaller 800px x 640px version. Enjoy fellow Ninjas!

Download: 1280px x 1024px JPG | 800px x 640px JPG
Please note that Facebook® is a registered trademark of Facebook Inc.

The Facebook Platform Team recently added our comprehensive blog post on the Facebook interaction and integration touch points to their much read Offsite Tools and Tutorials.  Matt Trainer writes:

Great post, [metablocks].
We’ve added this to our Offsite Tools and Tutorials post.
Thanks for sharing.

Matt Trainer

Thanks for the add! Much appreciate!

It seems that not a lot of Facebook apps are taking advantage of all the integration or marketing touch points that the Facebook platform provides. A growing number of applications haven’t been upgraded to take advantage of the new Facebook UI and APIs and many more continue to cling to the “profile-centric widget” model introduced in the first version of the Facebook API. These applications don’t take full advantage of all the communication venues available to them, and other important viral features I mentioned in my blog post on Facebook development best practices. With the growing number of changes to the Facebook API, and new features and services being added services, clients and even developers are simply unaware of all of these integration points

Whe developing a Facebook application you should consider each of the following integration or marketing touch-points:

Content and Information

• Profile Boxes (Main Profile or Boxes Tab)
  • Issues: Requires user action, easy to miss (especially in boxes tab)
  • View (Boxes) | API | Example
• Canvas Pages
  • Issues: Only viewable by application user
  • View | Example
• Application Tab
  • Issues: New feature, easy to miss, can sometimes to hidden
  • View | Example
• Application About Page
  • Issues: Unless your app is listed in the directory, an unlikely entry point
  • Benefits: Supports “marketing material”, you can add other applications to your about page
  • View | Example
• Application Directory
  • Issues: Populated, approvals take time, apps can be rejected
  • Benefits: Allows your application to be found by Facebook users
  • View | Example
• Application Info Section (Info Tab)
  • Issues: Easy to miss
  • Benefits: “Integrated” with profile
  • View | API | Example

Communications and Feeds

• News feeds (mini-feeds) Also See
  • Issues: Has per application limits (10 stories per user per day)
  • Benefits: Highly visible communcation element
  • View | API | Example
• User Status Updates
  • Issues: Requires user permission, may have limits
  • Benefits: Probably most visible user communcations element
  • View | API | Examples
• Notification (user-to-user)
  • Issues: number limited based on a number of metrics, lacks persistence
  • Benefits: can be sent to non-application users
  • View | API | Examples
• Notfication (app-to-user)
  • Issues: number limited based on a number of metrics, lacks persistence
  • Benefits: Highly visible communication
  • View | API | Examples
• Email Notification (using API)
  • Issues: Requires user authorization, limited to 100 users per email, can be irritating to users
  • Benefits: Supports text and HTML
  • View | API | Example
• Email Message (using Proxied Email)
  • Issues: Requires user authorization, limited to 100 users per email, can be irritating to users
  • Benefits: Supports text and HTML
  • View | API | Example
• Application Invitations (user-to-user)
  • Issues: Requires
  • Benefits: Most common way of “sharing” Facebook applications
  • View (Send) | View (Receive) | Examples
• Publisher (user-to-feed)
  • View | Demo | API | Example
• Share Button (user-to-user)
  • Benefits: Does not require poster be application user, good to use on profiles
  • View | FBML | Example
• Share Button (user-to-profile)
  • Benefits: Does not require poster be application user, good to use on profiles
  • View | FBML | Example
• LiveMessage
  • Issues: Currently in beta, may change
  • Benefits: Real-time messaging
  • View | API | Example
    

Mobile Information and Communications

• Mobile Profile Pages
  • Benefits: Available to mobile users
  • View | API | Example
• Mobile Canvas Pages
  • Benefits: Available to mobile users
  • View | API
• SMS Messages
  • Issues: Explicit user opt-in to receive SMS, app has to register ot use SMS
  • Benefits: Available to mobile users
  • View | API

User Actions

• Bookmarking Application
  • Benefits: Button adds your application icon to the user’s toolbar
  • View | Example
• Enabling Profile Box (“Add to Profile”)
  • Benefits: Tags/button puts your content on the user’s profile or boxes tab
  • View | FBML | Example
• Enabling Application Info
  • Benefits: Tags/button puts your content on the user’s profile info tab
  • View | FBML | Example
• Permissioning Application
  • Benefits: Tags/button give you permission to email, update status, create events/classifieds and send SMS to users
    View | API | FBML | Example
• Adding Application Tab
  • Benefits: Tab/Button adds your application as a tab on the user’s profile
• Adding Application to Fan Page (or Application About Page)
  • Benefits: Allows pages to use your application
  • Issues: Complicates application development, adding apps to pages is not intuitive
    View | Example
• Upload Photos to Album
  • Benefits: Show up in newsfeeds, easily accessed by other users
  • View | API | Example

Marketing and Promotional Mechanisms

• Fan Pages Also see
  • Benefits: You can add other applications to your about page
    Example
• Facebook Connect
  • Benefits: Single-sign on, access to friends list, ability to post to status/news feeds
    Example
• Social Ads
  • Benefits: Potentially cost effective and targeted way of promoting your application
  • Issues: Low click-through rates
    Example
• Other Social Networking Ad Networks
  • Issues: May be discontinued by Facebook in the future
    Example
• Placing badgets or link to Facebook on your Website
  • Benefits: Great source of traffic
    Examples (Link) | Example (Button)
• Email Marketing
  • Benefits: Can be effective if you have expertise in this area
  • Cons: Spam filters

The list is almost complete and I am sure I have missed one or two things but hopefully this will keep the advertising agencies busy for a while! I will periodically update this list and have created a home for it on our corporate wiki.

Building and testing mobile application can be tricky and time consuming.  With the literally thousands of different handsets from Nokia, Apple, Sony Ericsson, Motorola, Blackberry, LG and dozens of other handset manufacturers on a broad range of mobile carriers, the task of designing a universal mobile application is almost impossible. Additionally develpers can choose to build “native applications” on one of the many mobile OS (such as Symbian, BREW, J2ME, Apple. Here are a couple of resources that help:

• Adobe Device Central CS4 – Flash
  Allows you to test Adobe Flash applications on a varietey of handsets
• Java Device Test Suite – Java
  Sun’s device test suite for testing J2ME applications
• DeviceAnywhere – Any
  Excellent but expensive. Allows you to test using actual (real) devices via a Java Swing interface. Have a huge library of phones (and carrier networks) you can choose from.
• Mobile Device Emulators – Any
  Not as good as the real thing but definately less expensive. Here are a handful of mobile emulators you may want to test on:
  • WinWap Smartphone Emulator
  • OpenWave Browser
  • Nokia Browser Simulator
  • OperaMini
  • Microsoft Pocket PC Emulators
  • Online Mobile Simulator
  • Online WAP Browser

It has been possible for sometime (because of the MacOS widget’s webkit support for plugins) to port flash widgets or application to the Macintosh desktop. There are a couple of caveats to be aware of, however, when doing this:

1. Ensure your Info.plist file is Setup Correctly
   Ensure the following two lines are in the Info.plist file for your Mac Widget:
    <key>AllowNetworkAccess</key>
<true/>
<key>AllowInternetPlugins</key>
<true/>
   This will allow the widget to support Adobe Flash objects and allow network access.
2. Ensure your Flash Object is Running Locally not Remotely
   Accessing Adobe Flash files remotely from your MacOS widget may cause problems due to  security sandboxing so if at all possible, avoid it.
3. Beware of Floating DIVs
   Whenever you try and place a floating DIV over a Flash object, you are sure to run into trouble. Design your widget so any HTML/Javascript generated floating DIV do not obscure the Flash object.
4. Flash Transparency Does Not Work
   In order to get the widget to “float” nicely on your desktop with a drop shadow (as most MacOS widgets have) you need to place it on top of a DIV that has a transparent/semi-transparent PNG. Obviously, the DIV needs to be larger than the size of your Flash object
5. Use Clearspring or Gigya for Sharing and Tracking
   You can use Clearspring’s In-widget model or Gigya to enable sharing and tracking from within your Flash object, that way users can share the widget with friends on the web or other platforms. Here is an example we helped develop (Click Grab Me, then Web).
6. Please Refresh and Redraw  as Often as Necessary
   When doing Flash-based widget development we have noticed that a bug in the Webkit sometimes causes refresh/redraw problems with the Flash portion of the widget. There is little you can do do solve this other than to intelligently force the widget to redraw each time a user moves the widget, maximizes the widget and brings focus to the widget (by clicking on it).  In order to do this type of refreshing, you will need to use swfobject.js. SWFObject is a small Javascript file used for embedding Adobe Flash content on webpages (and in widgets). It is capable of detecting and handling Flash plug-in versions correctly in all major web browsers(on Mac and PC) and can really make embedding Flash movies a lot easier!
7. Passing in User Preferences
   Using swfobject.js and flashvars you can pass user preference from the MacOS widget environment into your Flash object.  Redraw the Flash object, reading and then passing in preferences via the flashvar, each time you load or change them.

Hope this pointers help, if you run into problems, let us know!

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

 
Some of our clients ask for Clearspring and Gigya integration, but recently someone requested we build a widget using the SpringWidget API. SpringBox has an SDK awidget engine that allows you to run SpringWidget’s Flash based widgets on both the desktop and the web. The current version of SpringWidget targets Flash Player 7 or 8 and supports ActionScript 1.0 and 2.0.

Below is an example of a SpringWidget:

We’ll keep you posted on the pros and cons of the SpringWidget platform!

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!