iGoogle Developer Blog

Hot off the press: gadgets.* migration guide

2009-10-19T14:55:00.000-07:00

A little over a month, we announced the deprecation of the legacy gadgets API, and in the intervening time have been hard at work on resources to help with the transition. The first of these resources, a gadgets.* migration guide, has just been posted to code.google.com.

The guide includes mappings between _IG_* and gadgets.* methods, helper functions, and pointers to third-party libraries that you can use in your updated gadgets.

If you have any questions about the migration guide, or the transition from _IG_* to gadgets.*, please visit the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

Deprecating shareable-prefs API on iGoogle

2009-09-29T16:41:00.000-07:00

If you don't know about or use the shareable-prefs API, you can safely stop reading now. If you do, we want to let you know that we'll be deprecating this API and feature.

A little over a year ago, iGoogle added shareable-prefs, enabling gadgets to share state across multiple users' pages. Since then, iGoogle has rolled out support for OpenSocial, enabling a collaboration model that is more tightly integrated into an application's design. Given this, along with the low adoption of the shareable-prefs feature in gadgets, we've decided it's time to deprecate the shareable-prefs feature.

In the next few weeks, iGoogle will remove the UI elements for shareable-prefs, preventing any new gadgets from implementing this feature. A few weeks later, iGoogle will break the links between these gadgets entirely, at which point, the gadgets will behave as if they were never shared at all. However, both users will retain the data in their preferences. The gadgets should continue to function in every other regard, but gadgets that wish to share data between users should implement OpenSocial's requestShareApp (paired with appdata, or a 3rd-party storage mechanism).

If you have any questions about these changes, please let us know in the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

Reinforcements in the war on slow

2009-09-18T16:09:00.000-07:00

On the iGoogle team we're always working to balance the needs of our users with the needs of our developers, to make sure we're creating an environment where everyone benefits. We want users to have access to the very best gadgets, hence we want to make sure we provide our developers with all the tools and information they need to create those gadgets.

Recently, we announced plans to mark gadgets in the directory that were especially slow to load. We have some new tools on the way that will help make it easier for developers to streamline their gadgets. So we've decided to hold off on labeling gadgets until we've released these new tools and give developers a chance to use them to improve their gadgets.

In the meantime, there are still plenty of things that can be done to fight gadget latency — be sure to check out our latency tips on Google Code, and our Latency Combat Field Manual!

Posted by Tyler Odean, Product Manager, iGoogle Team

The more things change, the more they stay the same

2009-09-14T12:08:00.000-07:00

The legacy gadgets API has had a storied life, as both the first version of the gadgets API that drove iGoogle, and the direct predecessor of the current gadgets.* API. As with many APIs there comes a time when we must say goodbye to the past, and embrace the present. The gadgets.* API has gained wide acceptance, both on Google and non-Google gadget containers, and is the standard API for gadget development. And so, as of today, the legacy gadgets API is officially deprecated.

I'll give you all a moment to wipe away the tears of sadness (or joy as the case may be). Now, here are the details:

The legacy API is officially deprecated as of today, September 14th.
For three months, the legacy API will continue in its current state.
On or around December 14th, any new gadget submissions to the iGoogle directory must be using the gadgets.*, in order to be accepted, but existing gadgets may continue to use the legacy API.
On the same date, the remaining inlined gadgets will be disabled.
Finally, one year after deprecation, September 14th, 2010, gadgets using the legacy API will cease to function on iGoogle, and the majority of other Google-owned gadget containers (such as orkut, Gmail, and Calendar).
Reminders will be posted when these important dates approach.

We're also working on some tools to aid you in the transition: a gadget migration tool that will parse your existing gadget and convert legacy calls to gadgets.*, and a migration guide for developers who wish to migrate their gadgets by hand. Watch for announcements on these tools in the next few weeks.

For most gadgets, the changes should be simple to implement. For each _IG_* method, there is usually a direct equivalent gadgets.* method. For instance, _IG_AdjustIFrameHeight maps directly to gadgets.window.adjustHeight, and performing a find and replace is sufficient. In a small subset of cases, multiple _IG_* methods map to a single gadgets.* method. For instance, _IG_FetchContent and _IG_FetchXmlContent both map to gadgets.io.makeRequest with different parameters. Developers should refer to the relevant section of the developer's guide to find gadgets.* equivalents.

If you have any questions, as always, feel free to inquire in the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

Going faster than a roller coaster

2009-08-31T13:27:00.000-07:00

Users love fast gadgets. Fast gadgets are more likely to remain installed, and will see higher usage. Fast gadgets may also cost less to keep running.

Slow gadgets make users unhappy, both with individual gadgets, and with iGoogle. Unfortunately, there hasn't been a way to tell a slow gadget from a fast one until it's been installed. To remedy this, starting in late September, the iGoogle directory will add a "slow" badge next to the entry of any gadget that's slow enough to cause speed-related user dissatisfaction.

To help you get your gadgets in top-notch shape before the badges roll out, check out our new latency tips on Google Code.

Posted by Dan Holevoet, Developer Programs

iGoogle is a social being

2009-08-12T12:56:00.000-07:00

If you've been a devoted reader of this blog you're probably no stranger to the idea that "social is better" when it comes to the web. Activities such as reading the news, doing a crossword puzzle, sharing a todo list, or watching a video are all better when done with a friend. Coincidentally, these are all things that iGoogle users love to do, so bringing social to iGoogle is a logical next step.

Developers have had a chance to sneak a peek at what iGoogle has been doing in the social space for many months, in the iGoogle developer sandbox. As of today, social gadgets taking advantage of the OpenSocial API will now work in both the US and Australia, with other countries soon to follow. That's tens of millions of iGoogle users with access to social gadgets, if you're keeping count.

Of course, iGoogle is a little bit different than most of the sites which support OpenSocial, so here's a quick rundown of the differences:

An iGoogle page is personal, and not shared with other users. In OpenSocial terms, this means that VIEWER and OWNER are always the same person.
Friendship between two users may be non-mutual. This allows developers to use a "following" model in their applications. For cases where it's important to verify mutual friendship (sharing private data, for instance), developers can use the isFriendsWith filter when requesting the user's mutual friends.
iGoogle has users without canvas view, with canvas view but without social, and with social, all at the same time. And, some users sign in to use iGoogle while others remain signed out. Developers should make sure their gadgets work gracefully across feature sets so that users always have the optimal experience. This blog post provides more details and an example gadget for checking different cases.
iGoogle supports organic growth of applications with two mechanisms.
- Application sharing (via requestShareApp), allows developers to reach a wider audience by encouraging users to engage their friends inside of a given application. By default, requestShareApp will list all of the user's Friends and users can auto invite new friends by email. iGoogle will email recipients without iGoogle accounts, or present a notification within the UI to existing iGoogle users to add the gadget and become friends.
- Updates (via requestCreateActivity), allow developers to call out specific user actions, to share them with a wider audience. There is a current limit of 3 updates per user, per app, per day, which may be increased in the future.

To see some great examples of new (or upgraded) gadgets using social features, check out this page. Then, when you're ready, take a look at the getting started guide for details on writing your own social gadgets for iGoogle. As always, if you have questions, please visit us in the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

Every happy gadget is the same, every unhappy gadget is unhappy in it's own way

2009-08-05T14:13:00.000-07:00

Not so long ago we wrote about the need to keep your social gadgets robust to adversity. We received a lot of questions about how to detect when social conditions have broken down, and what to tell users when they have. So here's a quick cheatsheet for how to determine what might be interfering with the normal operation of your gadget, and what to do about each of them.

The user is in a domain without canvas view.
All gadgets that take advantage of canvas view should also be prepared to support those domains for which canvas view is not available. To confirm that a canvas view is available, you can insert a Content section without a view specified, as outlined in this blog post. If your gadget does not support a home view only environment, we suggest telling the user "This gadget requires a feature that is not available in your locale at this time. Please check back at a later date." For more on views, check out the iGoogle Developer Guide.

The user is in a domain where OpenSocial is not available.
If a user is in a domain where canvas view is available a good next step is to test whether that domain has access to OpenSocial functionality. A gadget can determine if the user is on an OpenSocial supported domain or not by calling gadgets.util.hasFeature('opensocial-0.8'), which will return true if the domain supports OpenSocial. If your gadget requires OpenSocial to operate correctly, we recommend you tell the user "This gadget requires a feature that is not available in your locale at this time. Please check back at a later date."

The user is not signed in.
Remember that a significant portion of iGoogle's users are not signed in and won't have any available social information to draw from. A gadget can determine if the user has signed in or not by making a request for the owner or viewer and checking the ID of the user. A logged out user is considered anonymous, and will have a viewer ID of -1. If your gadget requires access to OpenSocial information in order to operate we suggest you give users the message "This gadget cannot access the information it needs so that you can share or collaborate with friends. Please sign in to enable access." In many cases, of course, gadgets can still function even without social features. In that case - we suggest the message "This gadget lets you share and collaborate with friends on iGoogle. Sign in to use these features."

The user has not enabled the gadget's social access.
After installing a gadget a user will be prompted to enable that gadget to access their friend list and activity stream. If the gadget makes an OpenSocial request for information that the user has not enabled access to, it will fail with error code 403 (FORBIDDEN). If your gadget needs access to one or both of these datasets, we recommend the message "This gadget cannot access the information it needs so that you can share or collaborate with friends. Please adjust the gadget's settings to enable access." Similarly if your gadget can still function without access to these social features we recommend the message "This gadget lets you share and collaborate with friends on iGoogle. Please adjust the gadgets settings to use these features." Remember that all users will see your gadget displayed without social access at least once, so make sure your gadget handles this case gracefully!

The user hasn't added any friends.
Finally remember that most users will begin with no friends on their friends list. If your gadget needs friends in order operate normally, we recommend that you use tell your users "You can use this gadget to share and collaborate with friends on iGoogle. Share with friends." where you can link "share with friends" to the requestShareApp call, which allows users to simultaneously add friends and invite them to add your gadget.

By keeping these cases in mind you should be able to help ensure your users get the most out of the social functionality of your gadget. To see an example of how to detect these and other conditions in a live gadget, check out the newly updated Testing iGoogle State gadget.

Tyler Odean, Associate Product Manager, iGoogle Team

Announcing UX improvements in the sandbox

2009-07-02T16:53:00.000-07:00

Over the last few days, we've introduced several improvements to the sandbox to help flesh out what the full social experience will look like for your users.

First, sharing a gadget is a richer experience — requestShareApp invites now display notifications at the top of the invitee's iGoogle page and in the "gadget shares" link on the left nav bar. This system smoothly handles all the different use cases for you. If you invite a friend who does not yet use iGoogle, they will receive an email inviting them to join iGoogle and to share the gadget with you. Then, if your friend creates an account they will be prompted to add you as a friend. If your friend already has iGoogle but does not have you listed as a friend and/or does not have the gadget, they will see one of the new social notifications prompting them to add the gadget and/or to add you as a friend, respectively. Finally if the friend you invited already has you as a friend and the gadget, they'll get a dismissable message saying that you have invited them. As a developer you won't have to worry at all about whether or not someone uses iGoogle, has the gadget, or is friends with the user — requestShareApp will handle that all transparently for you!

Next, you can delete the "Sandbox Friends" gadget, because our real control for editing and expanding your friends list is here, living in the "Friends" link on the left hand nav bar. This, in addition to the prompts described above, is how users will add friends to their accounts.

And finally, the Updates gadget continues to improve — multimedia Updates should be displaying much more cleanly now, and you can also filter Updates for those posted by your own gadgets. Remember that the final version of Updates, like the friends control and social notifications will live on the left nav bar, and gadgets will be limited to three Updates per user per day.

Posted by Dan Holevoet, Developer Programs

Stem the 401 Tide

2009-07-02T10:13:00.000-07:00

Some of you may have noticed that OpenSocial API calls in the sandbox have started returning 401s, regardless of whether or not you've enabled social ACLs in your gadget. We're in the process of changing a few things behind the scenes, one of which has the unfortunate side effect of breaking the ACL check. While this is straightened out, make sure to visit: http://www.google.com/ig?force_sandbox=1 for a squeaky-clean and error-free sandbox.

Posted by Dan Holevoet, Developer Programs

An update on "Updates"

2009-05-26T16:00:00.000-07:00

Updates are back! As the launch of OpenSocial support for iGoogle draws ever closer, we wanted to give you guys more ability to test and refine your gadget's use of the activity stream.

To that end we encourage you to install the Updates gadget which is now actively displaying Update streams from contacts in your Friend's group. Remember, this is not the final UI - when we launch, Updates will be built into the container, rather than appearing in a standalone gadget.

As you already know, in the wild there will be limits on the amount of Updates we allow from gadgets, to prevent spam. As of right now, we are considering a daily quota of three Updates per user per gadget. This limit will not be enforced on gadgets in the sandbox so that you can continue testing your code without worrying about these protections, but be aware that there will be some anti-spam restrictions when these features go live.

For more on Updates, check out the OpenSocial tutorial's activities section.

Posted by Tyler Odean, Associate Product Manager, iGoogle

The importance of being unsociable

2009-05-14T17:53:00.000-07:00

A lot of the content we post on this blog is about social. Social is new, social is big, social is better (all true!) ... but, non-social is important too, and gadgets should behave gracefully when users have not enabled social features, or they aren't available. Not only is a large part of iGoogle's userbase not signed in, but when users add a new gadget to their pages, for the first time, it is always added without social features enabled. Users enable the social ACLs in a separate step, after the gadget has been added to the page.

Until they do that, the gadget will be rendered without social access - meaning that every single user will see your gadget without social access at least once. Plan for it! Make sure you can handle that case, even if you only display a message prompting users to sign in and enable social access so that your gadget can operate correctly.

For help with detecting whether a user's social functionality has been enabled and other iGoogle-specific OpenSocial questions, check out the Testing iGoogle State gadget. This cribsheet builds on the OpenSocial tutorial to provide a rapid way to look up example code for common social gadget tasks.

Many of the folks who contribute to OpenSocial and iGoogle will be at Google I/O in San Francisco on May 27-28. We love to talk about this stuff, so check out the Google I/O site to sign up and join us.

Posted by Tyler Odean, Associate Product Manager, iGoogle

Gadget Checker: A simple way to make good gadgets great

2009-05-05T09:54:00.000-07:00

Writing software is hard, and it's easy for bugs to creep in. Gadgets are no different. And while developing gadgets here at Google, we discovered that many gadget bugs only show up when you've finished developing -- like when Japanese users can't see that translation you worked on for ages, or when your gadget turns out to be frustratingly slow.

It's important to have great gadgets in iGoogle. To help you, we'd like to share a tool that we wrote to catch many common gadget errors: Gadget Checker. We like to think of it as a small tool with a big impact. Use it before you submit your gadget to the Directory to pick up errors such as missing ModulePrefs attributes and missing images, scripts or stylesheets. It also makes suggestions for avoiding common latency traps, like unused API libraries, and for internationalizing your gadget. Simply load a gadget and run the tests, and you may find that you've fallen into one of the common problems. If so, there's advice in the gadget on how to address the issue.

To allow developers to use the tool while developing their gadget, Gadget Checker can open a gadget saved as a local file or in the Google Gadget Editor. (Tip: Consider using a special iGoogle tab containing Gadget Checker and the GGE next to each other, just for developing gadgets.) Once you've opened a local file in Gadget Code Checker, you can save it directly to GGE to fix all the bugs you found. Gadget Checker can even check any existing gadget simply by entering its URL.

Of course, the list of checks is nowhere near complete. If there's some pet peeve that you wish Gadget Code Checker looked for, feel free to let us know. We hope Gadget Code Checker makes it easier for you to develop great gadgets, and are looking forward to developing additional tools to help too.

One more thing. We hope you'll join us at Google I/O in late May. It's a useful way to interact with Google engineers and other developers. And two days in San Francisco isn't too shabby, either! Register today.

Posted by Egmont Koblinger and Martin Strauss, iGoogle Software Engineers

Signing changes in the iGoogle sandbox

2009-04-03T10:31:00.000-07:00

In case you haven't seen the announcement on the OpenSocial blog, some changes to the way iGoogle's REST and RPC endpoints verify requests will be going live today, on the developer sandbox. If you're using a client library (Java, PHP, Python, Ruby), the latest versions will be compatible with these changes.

To ask questions about the client library changes, please check out the client libraries group. As always, for other questions, see the iGoogle developer forum.

Posted by Dan Holevoet, Developer Programs

The sandbox prods along

2009-03-19T14:34:00.000-07:00

The iGoogle developer sandbox has always served as the bleeding edge version of iGoogle. It's the place to go when you want to be the first to try out new features. Unfortunately, if a bug sneaks into a sandbox release it can grind gadget development to a halt. This puts gadgets.* and OpenSocial developers in a tough spot, because the sandbox is the only place to develop with these features. Or, at least, it was.

Following on orkut's model, iGoogle will now have a "production" sandbox, meant to provide a more stable development environment. New features and improvements will hit the regular sandbox, first. After they've had some time to simmer, they'll move over to the production sandbox.

To enter the production sandbox, first enter the regular sandbox, then append the 'force_prod=1' parameter to your iGoogle URL. If you are not already in the sandbox, 'force_prod=1' will not trigger the proper behavior.

If you're hitting the REST/RPC endpoints, you should now use http://www-opensocial-sandbox.googleusercontent.com/api and http://www-opensocial-sandbox.googleusercontent.com/api/rpc for the sandbox endpoint, and http://www-opensocial.googleusercontent.com/api and http://www-opensocial.googleusercontent.com/api/rpc for the production equivalents.

As always, feel free to discuss sandbox issues in the developer forum.

Posted by Dan Holevoet, Developer Programs

Are you in the sandbox? Here's a quick way to check

2009-02-24T13:22:00.000-08:00

Can't figure out if your account is in the developer sandbox or not? Sometimes the "Welcome to the iGoogle Developer sandbox" message is obscured. Sometimes developers are confused about the behavior of the http://google.com/ig/sandbox page (which acts as a toggle, not just a redirect). And sometimes sandbox features aren't working properly, so that even if you are in the sandbox, it looks like you aren't.

Here's a small gadget to provide a little heads up on the sandbox status. If you're in the sandbox, it lets you know and gives you a quick way to leave. If you're not, it gives you a quick way to enter. And, finally, if it thinks you are in the sandbox, but features don't seem to be working, it tells you that, too. Think of it as your personal sandbox valet.

The exact behavior relies on the current rollout of features (and using the .com TLD), so it will likely need an update down the road as launches occur. Please test it, add it to your pages, and check the status message if things aren't working properly.

For questions and comments, feel free to add to this thread in the forum.

Posted by Dan Holevoet, Developer Programs

iGoogle's getting some changes under the hood

2009-01-23T14:56:00.000-08:00

If you've had a chance to look at recent gadgets documentation, or tried out the iGoogle developer sandbox, you're probably aware that gadgets.* is the new hotness. Sadly, the _IG_* methods are all that work in production.

Starting within the next month, iGoogle will be undergoing some significant behind-the-scenes changes. The first recipients will be gadgets in open syndication, which will gain support for gadgets.*. We've worked hard to make sure gadgets work properly with the new architecture, and gadgets that use _IG_* methods should still function properly. However, there are two things that you, as a developer, should note.

First, support for datatype=location is now deprecated, and you should use another method, such as the Google Maps API geocoder, for positional data.

Second, iGoogle will dynamically rewrite some HTML and JavaScript for faster loading and rendering times. While this is generally a good thing, some malformed HTML and JavaScript can cause problems. Make sure to wrap your JavaScript code as demonstrated by the following example to avoid many common issues:


<script type="text/javascript">
<!--
  // js code goes here...
// -->
</script>

As always, if you have issues, let us know in the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

New ACLs on social features

2009-01-14T14:29:00.000-08:00

Up until today, gadgets installed in the iGoogle developer sandbox had implicit access to social data, with no way for users to opt-out without uninstalling the gadget. We've added a feature to give more finely-grained control to users and allow users to explicitly grant or deny access to social data to their gadgets.

When users install gadgets that use social data (indicated by requiring the OpenSocial feature), they will be prompted to give permission to access social data. If a gadget is released without social features and is upgraded, users will be prompted for access within the gadget when the new version is first rendered.

When OpenSocial gadgets are available to all iGoogle users, users must grant permission before gadgets are allowed access to social data. For sandbox users, we want to ease development, so sandbox gadgets are allowed access to social data before confirmation.

Developers, this is important, so take note. If users deny access to social data, the gadget should have a good error message and graceful fallback UI.

Check for the ability to access social data with this snippet of code:

gadgets.util.hasFeature("opensocial-0.8")

and fall back gracefully if permission is not granted.

If you have any questions, please join us in the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

REST and RPC support in the developer sandbox

2008-12-19T15:41:00.000-08:00

If you've got Firebug installed on your iGoogle page, you may have noticed how requests to fetch people, friends, or persistent data are formatted. These requests follow the RPC specification that's part of OpenSocial, and, while they've been part of the sandbox for a few months now, never really deserved a mention, until today.

We've just released four client libraries (Java, PHP, Python, and Ruby) for using these REST and RPC requests as part of your own gadgets. With these libraries, you can access social data without having to go through an iGoogle page (for instance, if you need to do offline processing), or even write an application without having to write any JavaScript.

To get started, download the client of your choice and try the included samples, which work on a variety of OpenSocial containers. (For reference, the iGoogle endpoints are http://sandbox.gmodules.com/api for REST calls, and http://sandbox.gmodules.com/api/rpc for RPC calls.) When you're ready to do your own iGoogle development, register your application to get the authentication keys you'll need to use the API.

If you have questions or comments, join us in the OpenSocial client libraries group. Have a RESTful (and RPCful) holiday season!

Posted by Dan Holevoet, Developer Programs

Sign in to MySpace, AOL Mail, and Google Books gadgets

2008-11-19T10:20:00.000-08:00

See your latest updates on MySpace, read and reply to messages in AOL Mail, and keep track of your Google Book Search Library.

These are the first three gadgets on iGoogle to use OAuth, which is a privacy-preserving security standard that defines how a user can give consent for their data on one website to be accessed by another website (or in this case a gadget). iGoogle never sees the user's password on the other site, and the gadget displays the user's data from the other site without storing any of it on Google's own servers (read more details about OAuth on our Security Blog). With these gadgets on iGoogle, users can now keep track of even more personalized information from across their online life. For example, the MySpace gadget shows your friends' latest updates, status messages, bulletins, and an inbox preview.

With the AOL Mail gadget, you can preview all your email messages in home view. In canvas view, read rich text email, compose, reply, delete, mark as spam, and more. The gadget even includes autocomplete, attachments, spell check, and sorting options. If you have an AOL Mail or AIM Mail account, you must try this gadget.

The Google Book Search Library gadget allows you to keep track of all the books you want to read, and also offers you personalized recommendations. Finding new books and removing books from your library is a snap. You can even preview your books from right within iGoogle's canvas view.

These gadgets are also great examples of how to utilize the canvas view, which launched last month on iGoogle. If you want to create a gadget like AOL and MySpace, this overview will get you started on exposing an API that can be accessed using OAuth. If you already know which OAuth enabled API you want to access, you can jump directly to the gadgets documentation.

Posted by Kevin Tom, Product Manager, iGoogle

The sandbox...it lives!

2008-10-28T13:12:00.000-07:00

After a slightly-longer-than-expected hiatus in the sandbox, the gadgets.* and opensocial.* APIs have been brought back from the dead, just in time for Halloween.

Let gadgets.util is undefined haunt you no more!

Posted by Dan Holevoet, Developer Programs

For every action...

2008-10-17T20:20:00.000-07:00

...there is an equal and opposite reaction. But, even Newton might not have foreseen that when pushing changes to iGoogle, we'd temporarily disable social functionality in the iGoogle developer sandbox. Access to the gadgets.* and OpenSocial APIs should return on Tuesday, along with a properly functioning developer gadget.

In the interim, watch out for falling apples, and I'll see everyone on Tuesday.

Posted by Dan Holevoet, Developer Programs

Big canvas, big opportunity

2008-10-16T09:52:00.000-07:00

Some artists say that a blank canvas is daunting. We think of it as an opportunity, which is why we’re excited to be launching the canvas view feature to iGoogle users. Canvas view will roll out to users in the U.S. over the course of the day, and to international users in the near future.

Canvas view allows developers to deliver richer content, games, and UI to users on iGoogle as well as the opportunity to monetize. We’ve seen a lot of great development in the sandbox already, and we are proud to highlight several of our developers' canvas view gadgets. To start building a canvas view, check out our how to guide, which includes sample code for views, latency tips, and suggested design principles.

In addition to canvas view, we’re also replacing the tab interface with the left navigation seen in the sandbox. This allows users to jump from one canvas view to another with only one click. Going forward, we're working hard to graduate more functionality out of the sandbox and into production, such as OpenSocial.

Giving developers new opportunities makes for better gadgets, which is ultimately great for users. We’re eager to see what you create. If you have any questions, please join the developer forum.

Happy coding!

Posted by Jake Quist, iGoogle engineer

What's the difference among friends?

2008-09-26T13:56:00.000-07:00

I'm excited to announce that we've launched two important changes to the iGoogle developer sandbox. First, we have done a major upgrade on the sandbox friends manager that allows you to import, search and create groups of contacts. To share items with a contact, make sure you are in the iGoogle sandbox, and add a contact to the group called "Friends." If you already have the sandbox friends gadget installed, it should automatically upgrade. If not, you can add it here.

For development purposes, if you are sharing with friends in Google Reader, the same contacts in your "Friends" group in Reader will also be in your "Friends" group in the iGoogle sandbox. Your old sandbox friends will have to be added again to the "Friends" group.

In conjunction with the new sandbox friends manager, we are also changing what people and sharing calls return. You can now share content with contacts in your "Friends" group, even if those contacts have not added you to their "Friends" group. For example:

var req = opensocial.newDataRequest();
req.add(req.newFetchPeopleRequest("VIEWER_FRIENDS"), "friends");
req.send(response);

Will now return some friends with ids, and some friends without. Friends with ids are those who have you in their "Friends" group, while friends without ids do not.

function response(data) {
  var friends = data.get("friends").getData();
  friends.each(function(person) {
    if (person.getId()) {
      alert(person.getDisplayName() + " is a mutual friend.");
    } else {
      alert(person.getDisplayName() + " hasn't put you in their \"Friends\" group."); 
    }
  });
};

When you post an update, it will be viewable to any person in your "Friends" group.

If you have any questions about these changes, feel free to contact us in the developer forum.

Posted by Kevin Tom, Product Manager

Getting ready for the canvas view

2008-09-16T18:02:00.000-07:00

It's been a few weeks since I've provided an update on the status of the canvas view launch. Our experiments with a small percentage of users have been going well, and we've been making some small changes and adjustments based on user feedback (such as reducing the width of the left nav). In the next few weeks we plan on ramping up the number of US English users with the canvas view.

In anticipation of this, we're going to hold a special IRC event on improving existing gadgets by adding a canvas view. During the two hour session, show us your XML and we'll offer suggestions on how you can turn it into a great canvas view gadget. And of course, its a great time to work through any issues you are having in developing canvas view gadgets. To join us, visit the #opensocial channel on irc.freenode.net next Tuesday (9/23) from 1-3 PDT. See you then!

Posted by Dan Holevoet, Developer Programs

Cleaning the sandbox

2008-08-19T11:37:00.000-07:00

Posted by Dan Holevoet, Developer Programs

As a quick heads-up, we'll be pushing a new implementation of the persistence API to the iGoogle sandbox. When this happens, it will effectively clear the data storage of any OpenSocial applications in the sandbox. Data stored in preferences will not be affected, nor will any data of applications in production.

Enjoy the fresh, clean scent of an empty datastore, and let us know if you encounter any issues in the iGoogle Developer Forum.