Joining with the Web 2.0 “go-meta” business model that’s so popular these days, iWidgets provides a service that lets you build widgets once and deploy them to various popular widget APIs and platforms.
At the heart of iWidgets is a “PowerPoint-like” widget builder that takes strong design cues from Yahoo! Pipes, but as Peter Yared (CEO of iWidgets) says:
then again Pipes looks a lot like Prograph (the original dataflow programming company, where I worked from 1992-1995)
The site transforms the widget you build into:
a native FBML or GoogleGadget/OpenSocial, which are two completely different architectures (serverside vs. clientside), and then call the destination-specific API’s for things like persistence whenever possible.
The builder was constructed using jQuery and like Pipes renders the connection lines using <canvas>. Peter shared some of the back story behind building the application:
I wrote the initial builder in [another framework] and found it obtuse. After spending literally a week trying to turn the date picker into a color picker, I threw in the towel. A friend of mine turned me on to jQuery and I fell in love with how clean and fast it was, the way it separates the HTML from JavaScript is beautiful. So I rewrote the builder we had at the time in jQuery in a two week coding session! Soon after that I got funding from Opus Capital, and when I looked to hire people, I found 3 out of 4 of our engineers through the jQuery mailing list. It’s funny how things like that work out; I ended up finding total rockstars because they were playing with a cool new library.
Peter also shared some details on the overall development process:
It took us 10 months to build the site, we have had one guy (Richard Hensel) full time on the builder UI with another guy (Jeremy Stanton) on it about 1/3 time, with the rest of his time on the overall site doing the wizards and getting things like the %#$# back button to work. Then there are two guys working on the backend, one on FBML and the other on Gadget/OpenSocial, and we just added a junior AJAX guy. We contribute back where we can, for example Jeremy contributed to the Selectable in jQuery UI. The iWidgets site itself is completely AJAX, data from the server is sent as JSON, and page fragments are rendered with Wicket. We persist the widgets you build as JSON and then transform them on the server into native Facebook, MySpace, iGoogle, etc.
The team has some future plans building on top of an already very cool site:
We have a bunch of features we are rolling out, such as calling JSON and piping the results into different components, repeating table, paging, cut/copy/paste, z-order control, live dataflows in the builder, a background process at amazon that sends out notifications like “joe just shot 2 over par at pebble beach” to newsfeeds to drive virality, more platforms such as the iPhone, etc.
I wonder if this should somehow integrate with Yahoo Widgets, Apple’s Dashboard, and other desktop widget platforms… maybe emit a bundle you can download and install into these services?
The best news is that, based on numerous discussions with both app developers as well as container sites, we believe OpenSocial 0.7 has all the necessary pieces to launch OpenSocial apps to users at scale. In fact, both hi5 and orkut will be using OpenSocial 0.7 for their upcoming user-facing launches.
There are two major pieces to this release:
Updating OpenSocial
The OpenSocial APIs have been upgraded:
Standardized profile information fields. This release adds a slew of standard fields that you can access about a Person. These include location, schools, pets, movies, sports, and more. However, keep in mind that a container may not have all of this information available so your application should always check first by using the supportsField method.
Support for viral growth. Two new methods allow your application to send messages on behalf of a user. You can invite a user’s friends to install your application with the requestShareApp method. You can also send an application-specific message with the requestSendMessage method. Both of these methods require the user sending the message to authorize the request first.
Activity templates. You can now define activity messages with placeholders for pieces of applicaton or user data. This separation of data and presentation allows multiple activities to be combined into activity summaries—consolidated bundles of activities that let users know what their friends are up to without having to wade through a flood of messages. For example, instead of seeing five new updates about friends that installed a new application, you would see one update that says five of your friends added the application. For details on how to use activity templates in your application, see opensocial.Activity in the OpenSocial API reference.
Simplified persistence API. Support for global and instance-scoped application data has been removed from the API. Global application data can be implemented using feeds (that can be prefetched for performance) and other web standards. Instance-scoped application data can be implemented on top of user-scoped data by including the module ID of the application in the key.
Gadgets Open Sourced
As promised, the full Gadgets engine has been open sourced:
As part of the Apache Shindig project, gadgets have been open sourced. The new Gadgets Specification defines the gadgets.* JavaScript namespace where you’ll find that some of your favorite methods from the Gadgets API have been re-namespaced into a cleaner API for your convenience and clarity. For example, _IG_Adjust_IFrame_Height is now available as gadgets.window.adjustHeight
Would you like to be able to make a quick call to get a JSON response that ties together a social graph made up of resources available on the Web?
Brad Fitzpatrick, Kevin Marks, and others at Google have released a new Social Graph API that does just that:
The new Social Graph API makes information about the public connections between people on the Web easily available and useful. You can make it easy for users to bring their existing social connections into a new website and as a result, users will spend less time rebuilding their social networks and more time giving your app the love it deserves.
Here’s how it works: we crawl the Web to find publicly declared relationships between people’s accounts, just like Google crawls the Web for links between pages. But instead of returning links to HTML documents, the API returns JSON data structures representing the social relationships we discovered from all the XFN and FOAF. When a user signs up for your app, you can use the API to remind them who they’ve said they’re friends with on other sites and ask them if they want to be friends on your new site.
This is exciting to me as:
It actually uses the microformat standards such as XFN
Wei Zhu seems to be cooking with gas recently, and has released the JavaScript Client Library for Facebook API, which is a client side JavaScript library that mimics the other language client libraries (PHP, Python, Java, Ruby, etc):
An application that uses this client library should be registered as an iframe type. This applies to either iframe Facebook apps that users access through the Facebook web site or apps that users access directly on the app’s own web sites.
// Create an ApiClient object, passing app’s api key and
// a site relative url to xd_receiver.htm
var api = new FB.ApiClient('<insert_your_app_key_here', '/xd_receiver.htm', null);
// require user to login
api.requireLogin(function(exception){
window.alert(“Current user id is “ + api.get_session().uid);
// Get friends list
api.friends_get(function(result, exception){
Debug.dump(result, 'friendsResult from non-batch execution ');
});
});
It is good to see a JavaScript API like this. Now you can stay in JavaScript land and write code that works with OpenSocial, Facebook, and more. NOTE: If you live in FBML? No cigar.
Facebook is slowly adding features that allow you to do more JavaScript in their world. This started with FBJS (after mock ajax), and today they have announced FBJS/Animation, an open source animation library that not only works inside Facebook, but also can be used stand alone.
There is a nice writeup of Animation which includes tweening, easing, and checkpoints.
<ahref="#"onclick="Animation(document.getElementById('container')).to('height', '0px').to('width', '0px').to('opacity', 0).blind().hide().ease(Animation.ease.end).go(); return false;">Hide this div</a>.
It is great to see open source libraries like this come out of Facebook. I am curious why they decided not to use one of the other animation libraries out there. If you know, comment below!
Facebook released FBJS as a way to do more than just the simple Mock Ajax that you could do before hand. It didn't go as far as Caja (hopefully Facebook will work together on it), which seems to be the natural step wrt sandboxing code.
Many apps already use FBJS in innovative ways, and as part of this release we offer improved AJAX capabilities in FBJS. The new feature is a local proxy that allows you to make direct async requests back to your application server. This trick lets you to gain all the advantages of FBML without needing to use an embedded IFrame. To make this ability even more useful, we also now provide a DOM function setInnerXHTML that lets you to modify your canvas page by adding a string of HTML.
The more that we can do in our applications without having to jump into iframe land, the better.
Didier Durand wanted to check the compliance of various OpenSocial containers, so he decided to create a tool, IGCheck, that will do the checking for him:
The purpose of IGCheck is to test and report which functions of the Google Gadget API (i.e., prefixed with _IG_ in their Javascript name) are available in which containers. IGCheck then produces a report comparing the current test with reference data.
To get current status, check this page to see the most current result that we can produce concerning igoogle, orkut, hi5 & ning.
As the number of opensocial partners that are open for tests remain limited as of now, the following conclusions can be drawn as of now :
Hi5 does the same and as such seems to have "outsourced" the task of running its opensocial container to Google (see the line "host" in the result array)
Ning has followed a more independent approach by implementing a fully independent container named "proxy.ning.com" (see the line "host" in the result array)
The choice of Ning has currently drawbacks: IGCheck finds only 6 _IG_ functions whereas 55 are present in the others. (see the line "count" in the result array)
Ning seems to have created its own function(s) with _IG_Prefix: a function "G_Tabs" is present in the Ning container but nowhere else(see the line "_IG_Tabs" in the result array).
The conclusions above are preliminary results only:
the current and future containers will have to converge after the current pioneering phase in order to reach the promise "Write Once, Run Anywhere" although the fact that IGCheck itself is a proof of partial achievement (IGCheck source code is unique for all containers)
the opensocial initiative will have to get more precise on Google Gadget API requirements: the debate on this topic is currently hot on the opensocial discussion group as nothing (at least to my knowledge...) has been clearly and officially stated in this area until now . A poll is under way. The target is to get opinions of developers and eventually to define to which extent opensocial containers have to implement the _IG_ API.
See the current results, and help Didier get this running in other containers.
I put a lot of trust in sites like Facebook to do the right thing when it comes to privacy. After all, the only stuff that gets out into the public is the stuff that I actually put in. Until now.
Earlier this week, I bought a coffee table on Overstock.com . When I next logged into Facebook and saw this at the top of my newsfeed:
I was pretty surprised to see this, because I received no notification while I was on Overstock.com that they had the Facebook Beacon installed on the site. If they had, I would have turned it off.
I used my personal email address to buy the coffee table, so I was puzzled why and how this "personal" activity was being associated with my "public" Facebook profile.
Chris Chabot has been doing a lot of experimentation with the new OpenSocial APIs. He has written up his experience and created two prototype wrappers.
The second article includes the first library you can tell to load (owner, viewer, ownerFriends and/or
viewerFriends) information, and presents this information in an uniform way (instead of having to do different type of calls for different information fields) and with proper consistent error handling. With it you can very easily create your first OpenSocial container application in a friendly prototype style environment. You can take a direct look at the library itself.
The third article contains a Ajax.Request implementation, since Prototype's version won't work well or even at all in the cross domain environment of open social containers, it allows you to re-use your current Prototype based programs by trying to mimic Prototype's Ajax call as well as possible given the constraints of the situation. Under the hood, _IG_FetchContent is used to talk back to the server.
It is good to see people take the raw APIs and make them feel more like their library of choice.
If you are already used to Javascript, you will find that most of the syntax and functionality that you have come to know and love (or hate) is available in FBJS. Additionally, we've created hooks into our higher-level AJAX and dialog implementations which allow you to easily create dynamic experiences while maintaining the look and feel of Facebook.
We hope that FBJS enables you to build deeply integrated Facebook Platform applications in new and interesting ways.
FBJS does munging on the JavaScript that you provide, as it tries to stop naughty things.
With respect to Ajax, they give you an object to work with that sits on top of XHR, and is proxied by Facebook servers:
FBJS supplies a very powerful AJAX object for developers. Facebook will proxy all AJAX requests and optionally run useful post-processing on the data returned, such as JSON, or FBML parsing. To use it, just instantiate a new Ajax class. It supports the following properties:
ondone(data)
An event handler which fires when an AJAX call returns. Depending on .responseType, data will either be an object, a raw string, or an FBML string.
onerror
An event handler which fires when an error occurs during an AJAX call
requireLogin
If you set this to true the AJAX call will require the user to be logged into your application before the AJAX call will go through. The AJAX call will then be made with the regular fb_sig parameters containing the user's identity. If they refuse to login, the AJAX call will fail.
responseType
This can be one of Ajax.RAW, Ajax.JSON, or Ajax.FBML.
Ajax.RAW
The response from your server will be returned to your callback in its original form.
Ajax.JSON
The response from your server will be parsed as a JSON object and returned to your callback in the form of an object. Properties of your JSON object which are prefixed with "fbml_" will be parsed as individual FBML strings and returned as FBML blocks. These blocks can used on a DOM object with the setInnerFBML method.
Ajax.FBML
The response from your server will be parsed as FBML and returned as an FBML block. This block can used on a DOM object with the setInnerFBML method.
And one method:
post(url, query)
Start an AJAX post. url must be a remote address, and query can be either a string or an object which will be automatically converted to a string.
Here's an example showing most of the functionality of Ajax: Ajax Example
It is interesting to see more and more platforms wanting to open up and give users more abilities, but keeping the balance wrt security, privacy, and general abuse.
There are also rumors of new functionality to come, such as a data storage API.
As soon as Joe Hewitt was part of the Facebook team, we contacted the local bookie to put some money on the number of days before an iPhone view of Facebook would appear. Joe was slacking off, so my guess of 3 days was a little off. ;)
Joe and team did a great job though. It is a beautiful UI, and is nicer to use than the site in some ways. My only peeve is the sliding effect that happens more often than I would like (e.g. when I click on a tab I don't want a wipe!). A great use of iUI.
Jason Schuller has created a new social chat app for the iPhone called Minglets.com.
Neil Mix was skeptical that FBJS could be secure. He then quickly found a couple of holes but didn't disclose them until he had chatted with the Facefolk.
Neil is publishing the exploits after they are fixed. What a nice white hat he wears:
The first security hole was the easiest and least interesting hack. It bypasses access control #1 by making use of an old, arcane behavior of the setTimeout method, namely that you can pass a string as the code to execute:
Neil has four more in the bag, so hopefully we will see then as soon as Facebook fixes them. It is good to see the community working with Facebook on the issues, instead of just throwing up arms.
Below is an example of a Me.dium widget that is bound to ajaxian.com as the central point. Me.dium is now opening up to your signups, so go ahead and try it out. To add a widget yourself, click on the "manage widgets" section.
Mock Ajax? Huh. That is what I thought when I first read the documentation on building Facebook applications. It was a little sad to see that your choice was either to use the "mock ajax" calls, or to jump into iframe land and do everything on your server, thus not interacting with the Facebook shell.
Well, now JavaScript is going to be a first class citizen with FBJS:
FBJS is Facebook's solution for developers who want to use Javascript in their Facebook applications. We built FBJS to empower developers with all the functionality they need, and to protect our user's privacy at the same.
And an Ajax object is available:
FBJS supplies a very powerful AJAX object for developers. It supports retrieving JSON, FBML, or raw text from remote servers. To use it, just instantiate a new Ajax class.
ondone
An event handler which fires when an AJAX call returns
onerror
An event handler which fires when an error occurs during an AJAX call
requireLogin
If you set this to true the AJAX call will require the user to be logged into your application before the AJAX call will go through. The AJAX call will then be made with the regular fb_sig parameters containing the user's identity. If they refuse to login, the AJAX call will fail.
responseType
This can be on of Ajax.RAW, Ajax.JSON, or Ajax.FBML.
Ajax.RAW
The response from your server will be returned to your callback in its original form.
Ajax.JSON
The response from your server will be parsed as a JSON object and returned to your callback in the form of an object. Properties of your JSON object which are prefixed with "fbml_" will be parsed as individual FBML strings and returned as FBML blocks. These blocks can used on a DOM object with the setInnerFBML method.
Ajax.FBML
The response from your server will be parsed as FBML and returned as an FBML block. This block can used on a DOM object with the setInnerFBML method.
And one method:
post(url, query)
Start an AJAX post. url must be a remote address, and query can be either a string or an object which will be automatically converted to a string.
Hopefully this will mean richer Ajax apps on the Facebook platform.
Salil Deshpande has announced a bold move with the Facebook AppFactory. Bay Partners is announcing The AppFactory, a seed program to fund Facebook application developers via a fast-track process.
This program shows that Bay Partners believes that Facebook, in essence, has become the Social Operating System. And historically the creation of an operating system, or platform, has always led to the creation of an applications market atop that platform. "We think that the Facebook platform is broad enough, technically sound, appealing to businesses, and such a culture-fit for today’s internet ecosystem that it will become a significant and meaningful social operating system platform, if not the dominant one."
We asked Salil, Partner at Bay Partners, a few questions on the news:
What are you investing?
We will award between $25,000 - $250,000 to between 10 and 50 entrepreneurs with a flexible, fast-track process. Because early investments of this size are really bets on people and concepts, Bay Partners looks at the AppFactory as a fantastic relationship starter with tomorrow’s innovators. Because the investments are small, when compared to traditional venture investments, and because the amount of due-diligence that be done on kernels of ideas is often also small, Bay expects entrepreneurs to invest no more than a few hours into the process, and expects to make go no-go decisions in days rather than weeks.
What does this mean for Ajax developers?
With announcements such as this, and Google Gadget Ventures, firms are putting money where their mouth is. We are seeing the birth of web platforms, and these platforms become distribution mechanisms for entrepreneurs. The technical bar is lowered, as it is easy to create applications on top of Facebook, Google Gadgets, and the other platforms out there.
Currently we see simple, almost trivial apps. As time goes on those apps will become more and more sophisticated, and will be a blend of on-platform and off-platform experiences, and will likely involve a lot of Ajax.
What types of applications do you foresee coming from this platform?
We definitely see the open Facebook platform resulting in real, valuable applications. We believe that the Facebook apps of the future will be deep and sophisticated and will strike the right balance between adding value to the Facebook fabric, and having value independent of Facebook. For example, a shipping app that lets Facebook friends transparently use a service such as LicketyShip to physically lend and borrow books listed as favorites from each other, can monetize by charging for the shipping. A stock picking app that lets friends view each others’ stock portfolios could monetize at the point where friends want their own portfolio to reflect a friend’s picks.
And can people really make money from Facebook applications?
Yes! Incorrect conclusions are being drawn from the unmonetizability of some apps that have spread fast on Facebook to date. Some apps are like jokes that get forwarded around by email – and will always be unmonetizable. But meaningful apps will be monetizable just as meaningful web 2.0 websites are monetizable. We are interested in backing entrepreneurs that will be imaginative about what types of applications can be built on Facebook’s Social OS.
Facebook’s user interface is critiqued as being sterile - not very rich , flexible, customizable, or personal. Will this change things?
First off, the Facebook apps we are looking to fund are not necessarily those that focus only on jazzing up the user experience. Having said that, yes, we definitely think that the open API will allow a whole new level and set of rich experiences to be available on Facebook. Now that Facebook has put itself in the platform business, the application developer community is bound to create rich user experiences, whether they are enhancements to Facebook’s current user experience, or alternative user experiences.
What will the other social networks’ APIs look like?
Here’s some bold speculation. By the time other social networks open up their platforms, Facebook may have a sizeable lead in developer mindshare, and in the number of applications on their platform. The other social networks may struggle if they introduce APIs that are not compatible with Facebook’s. We think that the other networks should consider making their API compatible, if not identical, to the FaceBook API. This will allow one-click deploy of apps written for the FaceBook platform, onto the other platforms, thus mitigating Facebook’s lead. And we think they will seriously consider this.
This once again shows what a great time it is for Ajax developers. Everyone wants us!
, Social Networks
