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
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.
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:
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
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:
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:
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.
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.
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.
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
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).
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!
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):
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).
Click Add Widget.
You will be given 3 options: In My Widget, On My Webpage and Using the In-Widget API. Select Using the In-Widget API.
Enter the informaton for your widget including its name, code type, sharing menu type, colors, sizes and other options.
For Share menu you want to choose Default Menu or Just Tracking
Under What Do you Want to Share enter the embed HTML for your widget
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:
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.
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.
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.
Imports
You need to make sure you have correct imports at the top of your code. Common mistake is to forget this step.
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.
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
};
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!
