Search

At the Forge - OpenSocial and Google Gadgets

The past few months, I've written about the Facebook API, which
allows third-party developers to integrate their applications into
Facebook. A large number of such applications exist already, and
more are being created and released every day.

However, Facebook isn't the only social-networking site out there.
Indeed, Facebook isn't even the largest social-networking
site—although it is the fastest-growing and seems to have a great deal of
momentum. This is due in no small part to developers' ability to
create and integrate new applications into Facebook. And, although most
Facebook applications are (I think) pretty silly, that hasn't stopped
people from trying them and even using them on a regular basis.

Facebook's offer of a developer API definitely was a good thing for
Facebook users. But, it was bad news for at least three other groups
of people. First, users of other social-networking systems
suddenly were faced with the prospect of using a less-popular system. (In
the world of social networking, a less-popular system also is less
desirable.) Second, the people running non-Facebook
social-networking sites, such as LinkedIn and MySpace, suddenly
were faced with the prospect of their users leaving for Facebook.
Finally, software developers began to look at Facebook as the most-desirable platform for which they should develop, because it had the
largest user base. Even if one or more of the competing sites were to
unveil an API, and even if it were as rich as the Facebook API, it
probably wouldn't reach enough users to make the doubled effort
worthwhile.

So, I was fascinated to learn, via Marc Andreessen's blog, that a number
of social-networking sites were responding to Facebook in a way that
satisfied all three of these populations. They announced an API that
would allow an application to work across many different
social-networking sites. This API, known as OpenSocial, can be added
to any site (“container”) or application. If you write a Facebook
application, it'll work only on Facebook. But, if you write an
OpenSocial application, it'll work under Ning, MySpace, Orkut
and nearly a dozen other systems.

Of course, OpenSocial isn't exactly the same as the Facebook API. And,
in fact, it has some disadvantages when compared with the Facebook
API. Also, as I write these words in mid-December 2007, OpenSocial
still is stuck in an early beta release.

However, OpenSocial is interesting from a few perspectives. First,
it's an interesting shot across Facebook's bow, and one that
deserves our attention, if only because it demonstrates the lengths to
which companies now will go to attract developers and users. But, it's
also interesting because it's the first application standard I
can think of that is based on HTTP, JavaScript and HTML. That is, I
believe OpenSocial is the first Web development API that is
completely client-side, rather than server-side. If nothing else,
this shows how important JavaScript has become to Web developers.

This month, we start looking at OpenSocial from the perspective of
an application developer. OpenSocial builds on work done at Google;
thus, it's based on several technologies developed at Google,
including Google Gadgets. So, let's begin our discussion of
OpenSocial by looking at Google Gadgets and how we can create and use
them. Next month, we'll look at how to turn a simple gadget into
a social gadget and connect it with OpenSocial containers.

Google Gadgets

An OpenSocial application is, at heart, a combination of XML and
JavaScript, using a special version of Google Gadgets. The code
is written in JavaScript, and preferences and guidelines for the
gadget are set using XML. The simplest possible gadget, taken from
Google's on-line documentation, is the following:

The above gadget, as you can imagine, doesn't do very much.
The first line shows that it's an XML document and that it's
encoded using UTF-8. This means we can write gadgets in any
language we like, and they should work correctly. The gadget is
then contained inside <Module> tags, apparently because gadgets
were called modules when they were under development. The content
of a gadget sits inside a <Module>.

There are three potential sections inside a gadget:

ModulePrefs: defines the settings for a particular gadget.

Content: contains the HTML that is displayed for the user, as
well as any JavaScript code with which the user will interact.

UserPrefs: used to store user preferences.

The above test gadget doesn't contain any UserPrefs, and its Content
section contains only HTML, but it still is valid.

To see this gadget in action, you need to create an
iGoogle page. This requires having a Google login. (I'm familiar
with the privacy concerns that are increasingly raised about Google.
OpenSocial will not be tied to Google; thus, it doesn't require a
Google login. However, for the time being, it's easiest to create a
gadget for an iGoogle page.) Go to your personal iGoogle page:
google.com/ig.

On the right side of the screen is a link called Add stuff. This is
how you add new gadgets to your personal iGoogle page. By default, it
shows the most popular gadgets, and you're obviously welcome to add as
many or as few of these gadgets as you want. However, if you're
going to be developing gadgets, add the My
Gadgets gadget, which gives you some additional control and
functionality. Use the search box to find My gadgets, and when
you find it in the search-result listing, click on the add it now
link. You will be brought back to your iGoogle page, with this new
gadget now available.

Publishing Your Gadget

Google has tried to make gadget development as easy as possible. One
way it eases the learning curve has been
through the creation of many on-line tools that remove the editing and
storage needs for many developers. Thus, although many Web developers
(like me, and possibly you) are happy to write programs in Emacs and
put them on their own private Web servers, Google realized that not
everyone has access to (or familiarity with) such tools. So, Google
provides a Web-based editor (GGE, the Google Gadget Editor), which
not only lets people edit their own gadgets via a Web browser, but
also provides free storage for gadgets.

I'm going to take a more traditional route to storage in this column,
although you're welcome to ignore my example. I'll be putting my
gadgets on my Web server (atf.lerner.co.il). To incorporate
these gadgets into my iGoogle page, I must go to the My Gadgets
gadget and enter the complete URL of the gadget. For example, I
stored the above “Hello, world” gadget on my server as
rmlgadget1.xml. Thus, I entered the following URL into My Gadgets:
http://atf.lerner.co.il/rmlgadget1.xml.

Sure enough, after a moment of loading, I saw “Hello, world!” on
my iGoogle screen. Each gadget is displayed inside an iframe, an
HTML entity that allows the developer to create content that's
independent of its surroundings. Or, thinking about it in
a different way, the iframes ensure that gadgets cannot interfere with one
another but stay “locked” inside their frames.

More Interesting Gadgets

It goes without saying that most developers would not be content to
produce “Hello, world” programs. Rather, we typically want to do
something a bit more substantive.

In order to do that, we need to create a bit more HTML inside
the <Content> section. We probably should create some JavaScript
that manipulates that HTML as well, given that we have a completely
open canvas.

Note that I'm going to modify the original gadget I
created, which I named rmlgadget1. Google caches gadgets, which means
that once you have loaded one on to your iGoogle page, modifications
made to the gadget won't show up. This is when you must fire up your
trusty My Gadgets gadget, and uncheck the cached check box for the
gadget (in my example, rmlgadget1). Reloading the iGoogle page will
reload the gadget from the Web server,
allowing you to have a more interactive and productive development
experience.

Here's one update that demonstrates how to use JavaScript inside
the gadget:

Once again, there's not much content to this widget. We simply use
JavaScript and the DOM to modify the contents of a div. So, let's make
things a bit more interesting and retrieve the latest headlines from
Linux Journal's RSS feed. Then, we can display the first few
headlines, even making them linkable:

The above gadget code begins with the same sort of static code as our
previous gadget, although I did change it from saying “Hello,
world”
to something a bit more useful (“Loading feeds...”), because this text
will appear while the feeds are loaded.

The JavaScript in this gadget is somewhat interesting, mostly because
it depends on the _IG_FetchFeedAsJSON function, which Google provides
to gadget developers. This function takes four arguments, and the first
two are mandatory—the URL from which to fetch the
arguments and the callback function that should be invoked when the
feed is retrieved. For our example, I'm using the RSS/Atom feed URL
for Linux Journal as provided by FeedBurner.com.
Thus, we will get
the list of recent www.linuxjournal.com headlines, as defined by the site
administrators.

The callback function, which I've named callback here, is
invoked with a single argument, the JSON (JavaScript Object
Notation), representing the feed that was retrieved from our URL. That
JSON contains an array named Entry, whose elements contain the feed
information. Each element contains Title and Link properties, which
we will use to construct the output HTML.

When callback is invoked, we first go to FeedBurner.com and
retrieve the five most-recent headlines:

_IG_FetchFeedAsJSON(url, callback, num_entries, get_summaries);

Then, we iterate over the elements of Entry, appending them to a
variable we've conveniently named html and putting each Title
inside an HTML link, which opens the target URL in a new tab or
window (thanks to target="_blank"):

Finally, we assign our div (the one that starts by saying “Loading
feeds...”):

_gel('content').innerHTML = html;

Sure enough, our gadget works very nicely, providing us with a
dynamically updated list of headlines from Linux
Journal. What could
be better?

One of the most interesting characteristics of Google Gadgets is the
way in which they are completely self-contained, insulated from the
surrounding page and application. As I mentioned previously, this is
because each gadget sits inside an iframe, and it undoubtedly was one
of the reasons gadgets were used as the basis for OpenSocial.

However, we already can see how this will lead to a situation in which
the application, rather than the hosting OpenSocial
“container” site,
determines the look and feel. This means if you include six
OpenSocial applications, each one will have its own look and feel.
This is a big difference from Facebook, in which applications are
forced, to a large degree, to adhere to Facebook's look and feel,
creating a rather pleasant user experience. Time will tell whether this
causes problems or whether developers and users will reach a happy
medium on this issue.

A separate issue is the fact that each gadget contains only a single
page of HTML. Any updates that take place within the gadget, as we
saw, happen thanks to JavaScript manipulation of the DOM. This is not
a bad thing, and it is becoming increasingly common as Ajax becomes more
pervasive among Web developers. However, it may be slightly foreign
for developers who are still using the one-page-per-click paradigm.

Conclusion

Google Gadgets are small, self-contained mini-pages written in a
combination of XML, HTML and JavaScript. They may be hosted by
Google or on your own server, and to date, they primarily have been
used for the personalized iGoogle service. However, Google Gadgets
now form the foundation of OpenSocial, an open application standard
used by social-networking sites other than Facebook. Next month, we
will see how to convert our Google Gadget into an OpenSocial
application.

Extensive information about Google Gadgets can be found at
code.google.com/apis/gadgets/docs/basic.html, including many
examples. Some of the examples and instructions were
slightly out of date, but with a bit of digging, you should
be able to figure out what is going on.

Marc Andreessen, who cofounded Netscape and is now running the Ning
site for creating social networks, writes a blog about the software
industry, startups and OpenSocial at blog.pmarca.com.

Reuven M. Lerner, a longtime Web/database developer and consultant, is
a PhD candidate in learning sciences at Northwestern University,
studying on-line learning communities. He recently returned (with his
wife and three children) to their home in Modi'in, Israel, after four
years in the Chicago area.