iGoogle Developer Blog

Saying Goodbye to iGoogle

2013-11-01T00:35:00.000-07:00

As we announced on the Official Google Blog nearly a year and a half ago, today we’re retiring iGoogle. Moving forward, iGoogle will redirect to www.google.com. If you’ve been using iGoogle gadgets to access information from Google products like Gmail and Finance, you can continue to do so via our new app launcher.

We know that many of you enjoyed your customized iGoogle experience, so if you’re looking for alternatives, there are some options that might fit your needs.

Sincerely,

The iGoogle Team

________________________

Frequently-asked questions

1. What will happen to my iGoogle data?

All iGoogle data will be systematically deleted from Google servers.

2. Will there be any way to retrieve my data from Google in the future?

No. All user data will be permanently, and irrevocably deleted.

3. Will this affect my other Google services?

No. It simply means you will access them in a different way. You will still be able to use Google Chrome as your web browser, and you will still be able to access all Google services, such as Gmail, Google Search, Google Bookmarks, Google Calendar, Google Finance, Google Translate, etc., by opening them directly.

4. Why was iGoogle discontinued?

Please refer to our blog post for more information.

5. What will happen with third party gadgets?

Gadgets provided by third party developers will continue to be served. Google Sites, and other third party sites that have installed these gadgets will not be affected.

An update on iGoogle

2012-07-03T12:44:00.000-07:00

As we announced on the Official Google Blog, on November 1, 2013, we will be retiring iGoogle. To ensure a smooth transition for your users, you may want to update your gadgets and direct users to your site or offer the ability to export user data. You may also consider launching your application on one of our other platforms.

As part of this sunset, we will no longer accept new theme submissions after July 31, 2012. Similarly, we will stop accepting new gadgets after July 31, 2012 - but you will be able to update and maintain existing gadgets, as before.

Feel free to reach out to us at the iGoogle Developer Forum if you have any questions or need assistance, and thank you for supporting iGoogle over the years.

Posted by Conrad Lo, Product Manager

More new features for the Gadget Dashboard

2011-05-27T17:48:00.000-07:00

Did you know we are continuously adding new features to the iGoogle Gadget Dashboard? Today I’d like to let you know about a few of them.

First of all, we added two new data sets to the details page of your gadgets. Now you can see intuitive graphs in the “Installations and Removals” tab, which shows the number of gadget installations and gadget removals, and in the “Browser Errors” tab, where you can see errors recently reported by our end users’ browsers.

As you may have guessed, adding this information made the gadget details page too long, so we introduced a tabular view for that page.

(The tabular view, showing the new “Installations and Removals” data)

(“Browser Errors” table showing the top errors reported by our users’ browsers)

Additionally, the dashboard had been only available in English, but we added 7 other langueges a while ago, so it is now available in 8 languages: English, Spanish, Japanese, Korean, Portuguese, Russian, Simplified Chinese and Traditional Chinese. The localized iGoogle developer documentation will lead you to the localized dashboard. For example, after you select Japanese at http://code.google.com/apis/igoogle/, you will arrive at http://code.google.com/intl/ja/apis/igoogle/, which has a link for the Japanese version of the dashboard. Alternatively, you can explicitly add the URL parameter “?hl=ja” to the dashboard URL.

Lastly, in the next few days, we will start sending you weekly summary e-mails of your gadget usage. If you don’t want to receive these summary e-mails, you can opt-out from this service by just clicking a link at the bottom of the e-mail. The e-mails look like the following.

Gadget name: Weather

Author email: googlemodules@google.com

Pageviews: 1,000,000 (+5.00% compared to the week of May 30, 2011)

Unique users: ...

Installations: ...

Removals: ...

Browser errors: ...

Gadget name: Youtube Gadget

Author email: …

Pageviews: …

Unique users: ...

Installations: ...

Removals: ...

Browser errors: ...

…

...

As you can see, iGoogle is still evolving! Happy coding. :)

Posted by Takashi Matsuo, Developer Advocate

Live Gadget Previews in the iGoogle Directory

2011-04-04T08:48:00.000-07:00

The iGoogle Gadget Directory just got better. Users can now interact with a gadget in the directory before adding it to their page. Have a look at a couple examples like the Google News or Google Hot Trends gadgets.

Your gadgets can have live previews too. Gadgets that use Content view="default" already have a live preview in the gadget directory. Remember, view="default" can match any view supported by the container. Similarly, if the Content element in a gadget doesn't specify the view attribute, that's treated the same as if view="default" were present. Up until now, the only views that were supported on iGoogle were home and canvas; remember, home is the smaller version and canvas is the larger version.

Some gadgets are customized to display differently for the home and canvas views. If your gadgets do this, you can update the gadget XML spec to add a unique view for the preview or reuse an existing content element.

For gadgets with an element <Content view="home,canvas">
In this case you can just add preview, so you'll have view="home,canvas,preview".

For gadgets with <Content view="home">
Here too, you can reuse the home view for the preview by changing your spec to view="home,preview".

There are some other restrictions on the way the preview works. A preview can't use OpenSocial calls - since the user hasn't set the OpenSocial permissions before installing the gadget. You may want to address this in your gadget by making a special preview version that uses some dummy data, or you can opt out of the live preview and stick with a static screenshot.

Like all gadget views, the preview is cached. This reduces load and speeds up serving for users. But if you're working on your gadget and don't see a recent change in the preview, you can disable caching temporarily by adding the parameter "nocache=1" to the url.

Gadgets displayed as a preview also can't navigate to other views using requestNavigateTo(). If your gadget has a link that triggers changing the view it won't work in the preview.

If you feel a preview isn't the right choice for your gadget then specify the other views (home & canvas) and be sure that your screenshot does a good job of conveying what your gadget will do for users.

As always, come to the iGoogle Developer Forum to talk about live gadget previews with other iGoogle developers.

Posted by Rob Russell, Developer Relations

OpenSocial Development Environment 1.0 Released

2010-06-23T09:47:00.000-07:00

OSDE (OpenSocial Development Environment) is an Eclipse plugin for developing and testing OpenSocial applications.

It's an Apache-2-licensed open-source project hosted at:

http://code.google.com/p/opensocial-development-environment/

Its milestone version 1.0 was released on June 22, 2010.

OSDE provides a rich set of features that both enable and enhance OpenSocial application development. It helps people building for both the client within a gadget, or even on another server using the Java RESTful client libraries. Its features include:

A built-in Shindig server for local testing.
An integrated database for storing and managing social data.
Simple project and gadget code generation wizards to quickly generate your OpenSocial application projects and application code.
A multi-paned gadget spec editor to facilitate gadget development.
A new "OpenSocial" Eclipse perspective that provides enhanced editing and debugging with easy access and control of the local Shindig and social database.
An OpenSocial REST Java client wizard that can quickly generate a new project along with sample code that uses the OpenSocial RESTful Java client library to connect to the local OpenSocial server.
Live testing against iGoogle server.
Performance Analysis.

For details of installation and how to use it, please read the user guide at: https://sites.google.com/site/opensocialdevenv/user-guide

For bugs reporting or feature requests, please visit: http://code.google.com/p/opensocial-development-environment/issues/list

Thanks for your support.

Post content Posted by Albert Cheng, iGoogle Engineer

HTML5 in Gadgets on iGoogle

2010-05-26T14:26:00.000-07:00

Did you know gadgets can use html5? The key is in the doctype. Normally the doctype of a gadget isn't mentioned. Specify the html5 doctype in the gadget and it will be used when the gadget is rendered. Let's look at a quick example using the popular canvas drawing API:



<?xml version="1.0" encoding="UTF-8" ?>

<Module>

 <ModulePrefs title="html5 canvas">

 </ModulePrefs>

 <Content type="html" view="home,canvas">

  <![CDATA[

   <!DOCTYPE html>

   <script>

    var demo = {

     init: function() {

      var drawcan = document.getElementById('drawarea');

      if (drawcan.getContext){

       var context = drawcan.getContext('2d');

       var xmax = drawcan.width;

       var ymax = drawcan.height;

       context.strokeRect(0,0,xmax,ymax);

       for (var dotix = 0; dotix < 100; ++dotix) {

        var x = Math.random() * xmax;var y = Math.random() * ymax;

        context.strokeStyle = "#888888";

        var blueness = Math.floor(Math.random() * 256);

        context.fillStyle = "rgb(10,90,"+ blueness +")";

        context.beginPath();

        context.arc(x,y,5,0,Math.PI*2,true);

        context.closePath();

        context.stroke();

        context.fill();

       }

      }

     }

    };

  

    gadgets.util.registerOnLoadHandler(demo.init);

 

   </script>

   <canvas id="drawarea" width="150" height="150"></canvas>

  ]]>

 </Content>

</Module>

The top of the gadget still has the usual XML prolog because the gadget spec is, as always, an XML document. The html, in this case html5, is inside a CDATA block. The CDATA block means the structure of the html5 content is pretty much ignored when parsing the XML. iGoogle doesn't do anything extra for compatibility with html5; features specific to html5 will still only work in browsers that support them. Gadgets have the same cross-browser compatibility concerns as any other web page. Have a look at the When can I use guide for an idea of compatibility of features across browsers.

The content of this gadget is pretty straightforward. It includes a canvas element. In the init method it tries to get a drawing context. If it's successful (meaning the browsers supports html5 canvas) it will draw a rectangle around the extents of the element then draw 10 randomly placed dots inside. Use this gadget as a starting point to get your own html5 gadget running.

And yes, this gadget has a canvas in your canvas so you can render when you render.

Posted by Rob Russell, Developer Relations Team

OSAPI on iGoogle

2010-05-13T18:40:00.000-07:00

The OpenSocial 0.9 specification introduced a simpler API called OS Lite (also known as OSAPI) which uses a syntax that's friendlier for Javascript developers.

Some steely eyed developers have already noticed that iGoogle works with most OpenSocial 0.9 features. The implementation of OSAPI should work as documented at opensocial.org.

Here's a basic example to play with so you can get started with the OS Lite API. In this example we will execute a request to fetch and display a list of the user's friends.



<Module>

 <ModulePrefs height="800" title="osapi friends" title_url="http://code.google.com">

<Require feature="opensocial-0.9" />

<Require feature="osapi" />

<Content type="html" view="home">

<![CDATA[

<script>

var result = '';

osapi.people.get({userId:'@owner', groupId:'@friends'}).execute(function(response) {

result += 'You have ' + response.list.length + ' friends:<ul>';

for (item in response.list) {

result += '<li>' + response.list[item]';

document.getElementById("output").innerHTML = result + '</ul>';

});

]]>

</Content>

</Module>

To keep it short we've omitted detailed error handling in our example. It should be pretty clear what the script is doing but it's good to check response.error and gracefully handle problems.
The first call, osapi.people.get({userId: '@owner', groupId: '@friends'}) constructs a request object to get a list of people for the current user from their friends group. The call to execute will make a call to the service, passing the results to a callback function. Our callback is a simple anonymous function that across the result set.
When running the code, look at the JSON response from iGoogle and you'll see that the data structure is pretty straightforward. Use some of the tools built into your browser such as:

Firebug if you are using Firefox
Chrome or Safari Developer tools.
Opera Dragonfly
Internet Explorer 8's debugger

These tools help debug your Javascript but also can show you the HTTP messages that are going to iGoogle from your gadget and the responses iGoogle sends back. There's also the OpenSocial Developer App which is a gadget that will build arbitrary messages that you can incorporate in test code.

As we get more OpenSocial 0.9 tested out on iGoogle, we'll update the documentation to reflect the current functionality.

If you like OSAPI and you're going to be at Google I/O 2010, you can find us in the Hack Alcove on May 20 2010 from 2-3:30pm. We'll give a walk through of a gadget built with osapi for iGoogle gadget developers. There's also a talk for iGoogle developers at I/O on May 20 2010 at 10:15am.

Posted by Rob Russell and Paul Kinlan, Developer Relations

Images In RSS Around the World

2010-05-10T09:58:00.000-07:00

We announced a couple weeks ago that iGoogle now supports images in RSS. The initial launch was for the US only, but we're launching globally over the next few days. All users will now be able to use our two new views (headline and lead story and slideshow) to display images directly on iGoogle for any feed using MediaRSS or enclosures. If you're a feed provider, have a look at the iGoogle Feed Gadgets Publishers Guide to engage users with your feed.

Post content Posted by Rob Russell, Developer Relations

Variable Substitution and getMsg

2010-05-03T18:55:00.000-07:00

Gadgets use messages, stored in messagebundles, for internationalization. The most common way to access the messages your gadget has is with variable substitution. For example, a message called north can be specified as

<msg name="north">Nord</msg>

and accessed by using __MSG_north__ your code. The copious underscores lead to the affectionate term “hangman variables” for this substitution notation. Before your code runs, the exact text __MSG_north__ is replaced everywhere with the appropriate value from the messagebundle. In this example it will be “Nord” (French for North, no quotes). This happens in the appropriate places in the XML of your gadget spec as well. So your enum values can be replaced before the controls are made that will show them and everything works as expected. But suppose you have some text in your code that uses a message, something like

dirbox.innerHTML = '__MSG_north__';

This will work fine as well because the substitution happens before the code runs. Now let’s take another message

<msg name="dinername">Chez Sophie</msg>

And some similar Javascript

dinersign.innerHTML  = '__MSG_dinername__';

Everything works fine until we add the English translation

<msg name="dinername">Sophie's Place</msg>

And the code the gadget tries to run is

dinersign.innerHTML = 'Sophie's Place';

where of course the string ends early and the browser will correctly emit some odd error on seeing the first s after the apostrophe. This could be cited as an unterminated string literal, a missing semicolon or an illegal character (if you get a different character for your apostrophe).

The gadgets.Prefs.getMsg() function will correctly read the dinername as the string which it’s meant to be.

var  init = function () {

var prefs = new gadgets.Prefs();

dinersign =  document.getElementById("dinersign");

dinersign.innerHTML =  prefs.getMsg("dinername");

};

gadgets.util.registerOnLoadHandler(init);

The getMsg function should help make more reliable, robust gadgets in many cases and it might help resolve some of those errors your users get using languages translations that you don’t use so often.

Sometimes blue text just isn’t enough

2010-04-22T10:20:00.000-07:00

Nearly every iGoogle user has an RSS feed or two on their homepage - from top news to celebrity gossip, recipes, and much much more. In true Google fashion, we originally launched RSS support with a simple headline-only presentation. However, we all know the power of pictures, and so, we're happy to announce the addition of image support to our standard RSS gadget.

With this new feature, users have three different display views.

Headline only

SlideshowHeadline and lead story

When users go to iGoogle today, they’ll notice that not all feeds have the same view. We default each feed to what we believe is the optimal display based on the images currently available in the feed. Of course, users can change the display setting by choosing "edit settings" in the drop down menu for each feed.

These new views not only create a better experience for users, but also give publishers an opportunity to more easily expose rich content, often already present in their RSS feeds. To take advantage of this new feature, publishers simply need to add images and associated Media RSS and/or enclosure elements to their existing RSS feeds. We’ll then grab the images, resize them down as necessary, and provide hosting/caching. Additionally, we’ll make the images clickable and display a 150 character snippet in the “Headline and lead story” view.

Here are a sampling of feeds to try out:

CNN
NYTimes
BBC
The Economist
Time.com
People Magazine
Entertainment Weekly
Wikihow
National Geographic (try it in slideshow mode)
Simply Recipes (try it in slideshow mode)

This feature is launching in the US over the next day with full international support coming soon. Please see our feed publisher instructions for more information.

Posted by James Lee, iGoogle Engineer

UserPrefs in Gadget URLs

2010-04-20T19:43:00.000-07:00

There's been a change in the way we send parameters to gadgets which use Content type="url". In short, we started sending the user prefs parameters after a # - the URL fragment identifier. As it turns out, this change caused problems for developers who rely on using URL parameters in server side code - since the url fragment isn't sent to the server.

If this change caused trouble for your gadget then we have figured out a way to exempt gadgets individually for up to about two weeks - that's until May 4. So time is still tight but not as tight. Read on to the end of this post for details.

We didn't intend to break any gadgets and I would normally announce changes like this on the blog and in the forum earlier. The team discussed ways that affected gadgets can deal with the new location of the parameters for type=url gadgets and have a couple ideas for fixes.

First, if your gadget can deal with the user prefs completely in Javascript without another trip to the server then do so. Use the documented apis for user prefs. Gadgets that are already using these API functions to retrieve user prefs are not affected by this iGoogle change.

The other, hopefully less common, case is if you use the parameters in server side code in a way that slightly alters the delivered content. An example would be setting up location-dependant data with the user location stored in their preferences. In this case you can have the gadget read the parameters from the URL in Javascript and send an AJAX request to your server for the data you need to render the relevant sections of your gadget. Of course your gadget should use the documented user prefs apis as above.

A side-effect of the second fix may be that your gadget's initial render can happen sooner which can improve user-perceived performance (while taking roughly the same time to load overall).

We realize this unintended consequence may be difficult to deal with immediately. So we've figured out a way to exempt specific gadgets for up to two weeks if you need the time. Just give the URL of your gadget in this forum thread and we'll add you to the list.

I encourage anyone to post specific questions about fixes for your code in new threads in the iGoogle Developer forum. While it's not normally the best place for help with server-side code, in this case you may find other developers in similar situations.

Posted by Rob Russell, Developer Relations

Migration made easier

2010-03-25T13:30:00.000-07:00

Last year we released a legacy migration guide for converting legacy gadgets to gadgets.* by hand. At the time, we promised a migration tool to help perform these migrations automatically.

Today, I’m happy to announce the legacy gadget migration tool, which will convert existing XML and JavaScript code to use the gadgets.* API. The tool will accept raw XML and JavaScript to convert, or a publicly visible URL, read the code, and replace references to the legacy API with their gadgets.* equivalents. In the rare case where a migration cannot be automatically performed, it will output per-line warnings indicating what changes developers must make by hand, along with a relevant link to the migration guide.

Of course, please test migrated code before deploying to all of your users.

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

Posted by Dan Holevoet, Developer Programs

The forums, they are a-changin'

2010-03-04T10:41:00.000-08:00

iGoogle developers, your lives are about to get a bit easier. For the last few years, the iGoogle Developer Forum has been the place for gadget developers to discuss development of gadgets for iGoogle. Despite the name, the forum only provided help and answers for one of the two iGoogle APIs. For themes questions, developers turned to the Google Themes API group, fragmenting the development community in two.

Starting immediately, the iGoogle Developer Forum will now be host for all iGoogle developer discussion, for both gadgets and themes. The Themes API group will be put into a read-only mode in a few days, and the welcome text will include a reminder to everyone to visit the combined group.

In addition, we have created a new shared issue tracker for reporting issues with the Gadgets and Themes APIs. The igoogle-legacy tracker is to be used exclusively for issues pertaining to the deprecated legacy gadgets API, and will remain active until the API is no longer supported. All gadgets.* API, Themes API, and directory issues should be posted in the new issue tracker.

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

Posted by Rob Russell, Developer Relations

New features on the Developer Dashboard

2010-02-16T11:03:00.000-08:00

Last November we launched the iGoogle Gadget Dashboard, a tool to give our gadget developers more insight into how their gadget is used in the wild. For starters, we gave developers the ability to track their user count, pageviews, canvas views all over time, as well as the geographic distribution of their users. When we launched we promised more to come, and we're pleased to announce the release of several of the most requested features by our developer community.

You may have already noticed the newest additions to the dashboard, which we rolled out over the last week. Developers can now subscribe to their gadget's directory comments with their favorite RSS reader, so it's easy to stay current with your user's concerns and desires. If you're a developer with a lot of gadgets, we've added sorting options so you can keep gadgets ordered in the most useful way. Finally and for the first time, developers can easily submit and withdraw gadgets from the iGoogle directory, giving them even greater control over their presence on iGoogle.

We're firm believers in the principle that empowering our developers is the best way to bring a great iGoogle experience to our users, so we'll be listening to our developer community about the tools and data they need the most and the dashboard will continue to improve. In the meantime, you can play with the new version at: http://code.google.com/igoogle/dashboard/

Happy developing!

Posted by Sascha Haberling, Tech Lead

Last phase of inlined gadget deprecation

2010-01-22T11:41:00.000-08:00

The deprecation of inlined gadgets which began in November 2007 is ready to enter its final phase. Over the next 30 days, we will be disabling the remaining inlined gadgets on iGoogle, starting immediately with those that are broken or have zero users. If you’d like operation of your gadget to continue, please follow the instructions in the gadgets.* migration guide.

If you have any questions on the deprecation, please visit the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

An update on the legacy API deprecation

2009-12-17T17:25:00.000-08:00

Three months ago we announced the deprecation of the legacy gadgets API. Since then we've released a legacy migration guide for converting legacy gadgets to "gadgets.*" by hand, and we're continuing to work on a migration tool to help perform this conversion automatically.

Since the migration tool isn't yet available, we've decided to delay the next step of the migration process, the requirement that all new gadgets be written using gadgets.*, for an indefinite period. So, while we still recommend using the gadgets.* API, as it will save you time later, we're holding off on this requirement. Stay tuned for another update on the migration process, with a link to the migration tool, in early 2010.

Posted by Dan Holevoet, Developer Programs

Amigos! Freunde! Friends! Друзья!

2009-11-23T15:07:00.000-08:00

Googlers live all over the world, and so do Google's users. In fact, more than half of iGoogle's users are outside the US, which is why we're pleased today to announce the release of support for social gadgets on iGoogle in more than 30 languages, from Bulgarian to Vietnamese.

That means if you're developing or thinking about developing a social gadget to help users connect and collaborate on iGoogle, the size of your potential audience more than doubled! Now is a great time to explore our developer's site to learn about developing social gadgets for iGoogle. Or, if you already have a social gadget, you can click here to learn how to make it accessible to an international audience.

To learn more about how to make iGoogle and even more fun and personal homepage, you can check out the video below.

Posted by Tyler Odean, Product Manager

Launching the iGoogle Gadget Dashboard

2009-11-20T15:03:00.000-08:00

As Googlers, we love data. More data lets us make better decisions and make improvements to our products. As fellow gadget authors, we know that once you've developed a gadget, it can be difficult to get data that lets you know how your gadget is doing. The stats and comments in the directory are tailored for users, not developers, to help them make better decisions about which gadgets to install. Developers deserve a way to get data that lets them improve their gadgets.

Worry no longer! We're pleased to announce the launch of the iGoogle gadget dashboard, a place where developers can manage their gadgets and see detailed analytics about their gadgets' usage. Right now the dashboard allows you to see user numbers over time, number of gadget loads in home and canvas view, as well a geographic break down of users. We plan on adding more features to the dashboard in the near future which will give developers even more detailed information.

If you've already built an iGoogle gadget, go to the dashboard and add it. All you have to do is log in and enter the URL of any gadget you own or developed. Enjoy!

If you have any questions about the gadget dashboard, please visit the iGoogle Developer Forum.

Posted by Chris Pedregal, Product Manager and Kevin Liu, Tech Lead

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 its 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