While at GSP East, I presented on Muddl, a light fun word game that is anagram like in nature. I received lots of great feedback on the game from folks and encourage everyone to check it out.

It’s currently available on Facebook and Bebo. I’ll be finishing the port to MySpace and other OpenSocial containers soon.

The game play is very simple. After you go to the app you’re presented with some scrambled up letters. You then try to figure out what the word is. If you don’t get the word correct the system gives you a clue. If you’re still wrong you’ll get the first letter of the word revealed. After 3 tries you’ll be provided with another word. The game continues to challenge you as you play by increasing the length of the word.

Photo of Erik © James Duncan Davidson used with permission.

This week at GSP East the big names in the OpenSocial space came forward and basically gave a brief sales pitch on why they’re the platform to build on. Allen Stern has a nice synopsis of the panel. As a developer making decisions on where to focus time and efforts it seems like OpenSocial itself is really just playing catchup to Facebook. Most of the development folks I know are focused on Facebook still and are waiting for OpenSocial. The philosophical discussion aside, OpenSocial is looking stronger and stronger each day. Facebook recently open sourced their platform, but they’ve yet to announce any partners (beyond Bebo) who are adopting it. So their late foray into openness may be moot now.

OpenSocial, a group effort to create a widget platform spear headed by Google, has a few glitches that I’d love to see fixed. They are largely comparison items from Facebook, who has recently announced that it will open source it’s own platform. Regardless of the motivation, there are a couple of items I’d like to see ported from Facebook to OpenSocial.

1. Support for FBML like syntax: “Hold on a second! Standard HTML is the benefit of OpenSocial over Facebook” folks are probably thinking. While that’s true, without an effective way to capture and store user information for more than 24 hours (pesky terms of service documentation) developers are left querying for friends pictures etc over and over and over again. While this isn’t inherently a problem, if you wanted to display a 1,000 profile pictures for some unknown reason, you need to call the API a large number of times. Then generate the HTML and pass it to the client. This makes applications painfully slow. It’s great to store the numeric id (12345678) and be able to pass it back to the pre-client for parsing. The best examples are and . These really are very handy.
2. Support for FQL like syntax: OpenSocial does a great job of providing methods for gathering most of the information you would want from the social graph, but it’s lacking in the ability to remix the data in new and interesting ways (easily). OpenSocial requires all of the heavy lifting to be done on the client (or the application backend if their API allows it). Most clients have a reasonable limit as to how big data structures can effectively be and have the application still function. Processing on the applications infrastructure negates another advantage of OpenSocial which is requiring very little in the way of hardware to operate.

There are also some learnings here for Facebook. I’d like to see a few OpenSocial conventions ported from OpenSocial to Facebook.

1. OAuth Signature: To be fair, Facebook does provide signed requests, but it would be great if they’d use a standards based signature instead of their own homegrown version.
2. External JavaScript Libraries: Facebook’s FBJS is powerful and provides most functionality that developers need. It’s even been open sourced so it can be used outside of the Facebook universe. However, developers who’ve been working with jQuery, ProtoType or any of the other numerous javascript libraries have to start at the beginning again. Additionally, they may be missing the functionality in the FBJS library that they need.

Both platforms still have a ways to go in terms of making developers life’s easier and users application experiences more robust. I think it’s great news that Facebook is opening their platform more. It’s really more symbolic than anything, because they still ultimately control what they do or do not implement on their platform. Bebo is the only other social network using Facebook’s model and it still requires some re-writing for developers because of syntax difference and lack of some features.

Hi5 (yet another social network) is launching their OpenSocial based platform today (well really tomorrow and over the next few weeks) and have done a really great job communicating with developers how stuff is going to work. For example, letting developers know what will and won’t be working in their release plan. Facebook and MySpace could learn a good lesson here in communication. Stop being vague with your plans and let your developers and advocates know what’s up. Facebook has made some great strides with their notifications around larger platform changes, but the small stuff is still an open question.

Today I noticed a new tab in the application editor making it infinitely easier for developers of OpenSocial applications to adopt the MySpace platform. I first said they should be doing this two weeks ago and I’m happy to announce that they are. They now allow for the simple monolithic XML file to define your application. This is a great step forward. Their platform is becoming more robust and stable each day. Kudos to them, but they still have a lot to do as Nick O’Neill pointed out yesterday.

This evening I had the opportunity to implement what should have been a simple OAuth signature validation until I ran into trouble parsing the parameters of the request. I decided to use one of the many pre-built libraries instead of rolling my own (perhaps that’s where I went wrong) but I found that it wasn’t as easy as I had expected.

A quick primer for those unfamiliar with PHP, there are multiple variables that hold request information. The two most common for passing parameters to a PHP script are $_GET and $_POST, which are both associative arrays. PHP handles the encoding of the values and brings everything back to regular strings. This is very handy for passing data. There is one more useful structure called $_REQUEST that actually holds both sets of values in one structure - also very handy if you don’t know where your data will be coming from on a given request. Now back to my issue.

OAuth augments your parameters with a few specific values that are unique to it’s implementation and uses a shared secret key system to digitally sign requests providing a level of trust with any request. If your lost with OAuth, I wrote a quick primer about it a month or so ago. OAuth takes any data you pass and signs them into a hashed value by concatenating the data with the shared secret and a few other parameters. The resulting hash is then very unique and very difficult to guess. On the server side, you can now validate the request by looking at the parameters and re-calculating the hash value.

While that’s simple in theory, it’s a bit more difficult in practice, especially with MySpace’s implementation of OpenSocial and OAuth. Yesterday I blogged about how to make AJAX requests using OpenSocial. As a habit, I always default requests to POST when possible to get around any arbitrary data size limits that might be present and to keep data out of my log files. This resulted in quite a bit of drama trying to implement the signature because the library wanted to evaluate the POST parameters and MySpace sends them as GET values. I tried tweaking the library to use the generic $_REQUEST parameters, however, the $_POST values weren’t included in the hash! As a result I ended up moving all requests over to use get - which was very simple.

Below you’ll find the revised GET friendly code:

function ajaxRequest(url, callback_func, post_params){
   var queryString = "";
   for (k in post_params) {
      queryString += "&" + k + "=" + encodeURIComponent(post_params[k]);
   }
   url += "?" + queryString;
   var osParams = {};
   osParams[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;
   gadgets.io.makeRequest(url, makeRequest_callback, osParams);
   function makeRequest_callback(data){
      renderStatus("Handling ajax response with typeof: " + typeof(data.data));
      var json = gadgets.json.parse(data.data);
      if(!json){
         alert('Unable to parse JSON object');
      }
      callback_func(json);
   }
}

Now you can use the OAuth libraries to parse your signature in PHP and verify who’s posting to your data points. Don’t forget to s/_POST/_GET/g your code to update all POST references. It seems like a bug to me in the implementation that if the request is made via POST the parameters wouldn’t also be passed in the same way. Perhaps there’s a method to the madness I’m not aware of?

Two MySpace developers posting on a thread regarding requestNavigateTo within the MySpace environment need credit for this one. Kristaps and Eric posted a discussion which included some nice brief code snips. The code is short and sweet. All that’s required is a surface name and any optional parameters you would want to pass to that surface. Note in OpenSocial 0.7 “surfaces” are now known as “views” which might throw some developers for a loop as they make the transition.

function navigate(surfaceName, params){
   var surfaces = gadgets.views.getSupportedViews();
   var surfaceRef = surfaces[surfaceName];
   gadgets.views.requestNavigateTo(surfaceRef, params);
}

Valid views within MySpace (as of this time) are home, profile, and canvas. Sample usage for moving to the Canvas view from the profile (or home) would be as follows:

<a href="#na" onClick="navigate('canvas',{});" title="Move to canvas">go to canvas</a>

After much frustration debugging a tweak from OpenSocial 0.6 to 0.7, I decided I’d capture the essence of my code in one location for others to look at it. This walks through the basic structure to make an AJAX request using MySpace’s implementation of OpenSocial. It should work with other OpenSocial 0.7 compliant sites as well.

This is the core of the functionality - where all the magic happens - a function called ajaxRequest(). As you see it takes 3 parameters, the URL to post to, a call back function and an object/array containing any data you would like passed via post.

function ajaxRequest(url, callback_func, post_params){
   var queryString = "";
   for (k in post_params) {
      queryString += "&" + k + "=" + encodeURIComponent(post_params[k]);
   }
   var osParams = {};
   osParams[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
   osParams[gadgets.io.RequestParameters.POST_DATA] = queryString;
   osParams[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;
   gadgets.io.makeRequest(url, makeRequest_callback, osParams);
   function makeRequest_callback(data){
      renderStatus("Handling ajax response with typeof: " + typeof(data.data));
      var json = gadgets.json.parse(data.data);
      if(!json){
         alert('Unable to parse JSON object');
      }
      callback_func(json);
   }
}

Now that we have this tool, using it is very simple, first create a call back function that takes your JSON result and does something with it, then invoke the ajaxRequest by calling the ajaxRequest function using your parameters. That’s it.

function ajax_callback(jsonData){
   // do something with the data!!!
}

ajaxRequest("http://www.af-design.com/", ajax_callback,{});

I hope this saves some developers some frustration reading through the OpenSocial documentation and helps them get their apps up and running more quickly.

Today MySpace announced that the shift to OpenSocial 0.7 is completed and now they’re actively debugging it. The problem is, that most of the critical components, such as the ability to make AJAX requests, for any company looking to more widely leverage their existing databases are unable to do any testing at all! After setting aside my fears that OAuth wouldn’t be implemented in time, MySpace delivered yesterday OAuth signed requests. I’m really thankful that we can now use OpenSocial 0.7 within their container, but I’d be much happier if it all was working more than 48 hours before the soft launch. Their relay proxy machines have been down for nearly 12 hours now, putting a great crimp in development time. Does Rupert Murdoch own a pizza delivery chain or a significant interest in Red Bull?

MySpace, often considered noisy, brash and childish, is moving their platform into the hands of their users on Thursday (3/13) and developers are scrambling to get their widgets together. This is critical because of a serious first mover advantage that exists. MySpace has a huge daily user base, larger than Facebook, and will make or break widget companies who aren’t ready.

Compete’s metrics are revealing, an audience size roughly 2x larger than Facebook’s is nothing to sneeze at. Watch out Thursday as the gloves come off. What remains to be seen, is the growth rate that is possible with MySpace. Facebook apps had huge viral success due largely in part to very few early limitations on application interactions. That has all changed and apps are finding it harder and harder to grow their userbase. Now apps are limited to organic channels and may find branching into different networks more challenging.

Presumably, MySpace has learned from some of Facebook’s early mistakes. However, existing companies already have access to large networks of users through the Facebook audience with which they can promote their new MySpace applications. Of course it remains to be seen how large the overlap of users is from one network to the next.