Miron's Weblog

Executive Summary

• OpenSocial applications will have diverging look-and-feel, from each other and from the containers. This is because the containers do not provide common elements to blend the application into the container.
• OpenSocial applications may not be vertically resizable, since they will exist in an iframe. However, Google has an API For resizing that some or all of the networks may implement
• Facebook has additional API functionality that is not present in OpenSocial
• The Facebook API is server oriented, whereas the OpenSocial/Google Gadgets API is client-side JavaScript oriented

Common container features

• Application directory
• User’s active application page
• Left side application link
• Canvas page
• Profile box
• News feed

Common API features

Basic feature in common include getting data for a person, getting friends and publishing user actions.

OpenSocial UI programming model

The OpenSocial UI programming model is based on Google Gadgets. The Google Gadget platform puts your application inside an iframe. This provides isolation between the container and the application. However, this also means that the size of the containing frame is fixed. It is not clear if resizing will be available on the various social networks.

Because your application lives in an iframe, you can have arbitrary HTML, Javascript and other objects inside your application.

OpenSocial applications can be wholly or partially server-less. State information can be manipulated by the JavaScript of the application. The application’s gadget can be cached.

Functionality available as part of Google Gadgets: state (aka user-preferences), tabs, drag-and-drop, inline alerts (aka mini-messages), grid, internationalization, content fetch from URL, RSS fetch. Google caches any content fetches, but there is a refresh function.

Functionality available as part of OpenSocial JavaScript API: Activities (aka News Feed), People Data (aka Social Graph), Persistence (aka key-value pairs). There seems to be a 1-1 correspondence between functionality in the JavaScript API and the server API.

Facebook UI Programming Model

Facebook profile boxes and non-iframe canvas pages use FBML, which is based on HTML. No iframe is built. Rather, FB sanitizes the HTML and sandboxes the JavaScript to ensure that applications do not misbehave on the page. FB also caches the profile box content, so that profile load times are predictable.

Facebook provides quite a few UI elements to make application development easier and more consistent with the FB UI:

• Friend multi-select and invite widget
• User name generation, with possessive forms
• Tabs and headings
• Error/warning/dialog boxes
• Editor
• Wall-like message board widget
• Easy to use Ajax library (proxied by FB)
• Automatic visibility controls

These elements make it easier for an application to look like part of FB and eases initial development. I predict that OpenSocial apps will have diverging look-and-feel because the container does not provide default look and feel elements to the apps. In other words, each app will look different, even for common tasks.

OpenSocial Server-side API

OpenSocial functionality requires authentication with Google’s AuthSub. It remains to be seen how this is implemented in the context of an open system like OpenSocial. The API uses REST. The functionality of the API is very similar to the OpenSocial JavaScript API.

Facebook API

The Facebook API is accessible on the server side part of the application. The JavaScript part does not have access to the API. The API provides the following additional functionality over that of OpenSocial:

• Reading events
• Reading a person’s groups
• Reading/writing photos
• Reading/writing marketplace listings
• Setting a person’s status
• Setting content elements to be cached on Facebook

Presumably, OpenSocial will add some of this functionality with time.

Tags: Social Networks // 4 Comments »