Google Data » iGoogle https://googledata.org Everything Google: News, Products, Services, Content, Culture Wed, 28 Dec 2016 21:09:26 +0000 en-US hourly 1 http://wordpress.org/?v=4.1.13 Saying Goodbye to iGoogle https://googledata.org/igoogle/saying-goodbye-to-igoogle/ https://googledata.org/igoogle/saying-goodbye-to-igoogle/#comments Fri, 01 Nov 2013 07:35:00 +0000 https://googledata.org/?guid=85f68a87f2794373c192a0cd8fd6b02f

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.

]]>

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.

]]> https://googledata.org/igoogle/saying-goodbye-to-igoogle/feed/ 0 An update on iGoogle https://googledata.org/igoogle/an-update-on-igoogle/ https://googledata.org/igoogle/an-update-on-igoogle/#comments Tue, 03 Jul 2012 19:44:00 +0000 https://googledata.org/?guid=e4d8b46b1881ab5736ece0ea0d6638a8 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]]> https://googledata.org/igoogle/an-update-on-igoogle/feed/ 0 More new features for the Gadget Dashboard https://googledata.org/igoogle/more-new-features-for-the-gadget-dashboard/ https://googledata.org/igoogle/more-new-features-for-the-gadget-dashboard/#comments Sat, 28 May 2011 00:48:00 +0000 https://googledata.org/?guid=0304c421aa8b89004d1b3391bf8ede28 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]]> 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]]> https://googledata.org/igoogle/more-new-features-for-the-gadget-dashboard/feed/ 0 Live Gadget Previews in the iGoogle Directory https://googledata.org/igoogle/live-gadget-previews-in-the-igoogle-directory/ https://googledata.org/igoogle/live-gadget-previews-in-the-igoogle-directory/#comments Mon, 04 Apr 2011 15:48:00 +0000 https://googledata.org/?guid=2703e1b855ab7cfd0895cdd3390a8005 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]]> https://googledata.org/igoogle/live-gadget-previews-in-the-igoogle-directory/feed/ 0 iGoogle now replacing the Start Page https://googledata.org/igoogle/igoogle-now-replacing-the-start-page/ https://googledata.org/igoogle/igoogle-now-replacing-the-start-page/#comments Tue, 27 Jul 2010 23:40:00 +0000
Editions included:
Standard, Premier, Education and Partner Editions

Languages included:
All languages supported by the Start Page

How to access what's new:
To reach iGoogle, visit http://partnerpage.google.com/yourdomain.com. Be sure to replace "yourdomain.com" with your actual domain name.

Get these product update alerts by email
Subscribe to the RSS feed of these updates
]]> https://googledata.org/igoogle/igoogle-now-replacing-the-start-page/feed/ 0 OpenSocial Development Environment 1.0 Released https://googledata.org/igoogle/opensocial-development-environment-1-0-released/ https://googledata.org/igoogle/opensocial-development-environment-1-0-released/#comments Wed, 23 Jun 2010 16:47:00 +0000
It's an Apache-2-licensed open-source project hosted at:
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
]]> https://googledata.org/igoogle/opensocial-development-environment-1-0-released/feed/ 0 OpenSocial Development Environment 1.0 Released https://googledata.org/igoogle/opensocial-development-environment-1-0-released-2/ https://googledata.org/igoogle/opensocial-development-environment-1-0-released-2/#comments Wed, 23 Jun 2010 16:47:00 +0000 https://googledata.org/?guid=d7fc17bd403389b101d2b67707345438
It's an Apache-2-licensed open-source project hosted at:
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]]> https://googledata.org/igoogle/opensocial-development-environment-1-0-released-2/feed/ 0 HTML5 in Gadgets on iGoogle https://googledata.org/igoogle/html5-in-gadgets-on-igoogle/ https://googledata.org/igoogle/html5-in-gadgets-on-igoogle/#comments Wed, 26 May 2010 21:26:00 +0000
<?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
]]> https://googledata.org/igoogle/html5-in-gadgets-on-igoogle/feed/ 0 HTML5 in Gadgets on iGoogle https://googledata.org/igoogle/html5-in-gadgets-on-igoogle-2/ https://googledata.org/igoogle/html5-in-gadgets-on-igoogle-2/#comments Wed, 26 May 2010 21:26:00 +0000 https://googledata.org/?guid=b724d23fd57045fbb95896cef15f07bf
<?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]]> https://googledata.org/igoogle/html5-in-gadgets-on-igoogle-2/feed/ 0 OSAPI on iGoogle https://googledata.org/igoogle/osapi-on-igoogle/ https://googledata.org/igoogle/osapi-on-igoogle/#comments Fri, 14 May 2010 01:40:00 +0000
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
]]> https://googledata.org/igoogle/osapi-on-igoogle/feed/ 0 OSAPI on iGoogle https://googledata.org/igoogle/osapi-on-igoogle-2/ https://googledata.org/igoogle/osapi-on-igoogle-2/#comments Fri, 14 May 2010 01:40:00 +0000 https://googledata.org/?guid=c862ddfe19fcdea73ce9ed3da20edec5
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]]> https://googledata.org/igoogle/osapi-on-igoogle-2/feed/ 0 Images In RSS Around the World https://googledata.org/igoogle/images-in-rss-around-the-world-2/ https://googledata.org/igoogle/images-in-rss-around-the-world-2/#comments Mon, 10 May 2010 16:58:00 +0000 https://googledata.org/?guid=c4b70f069bd0cce8a9f038734e557200 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]]> https://googledata.org/igoogle/images-in-rss-around-the-world-2/feed/ 0 Images In RSS Around the World https://googledata.org/igoogle/images-in-rss-around-the-world/ https://googledata.org/igoogle/images-in-rss-around-the-world/#comments Mon, 10 May 2010 16:58:00 +0000 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
]]> https://googledata.org/igoogle/images-in-rss-around-the-world/feed/ 0 Variable Substitution and getMsg https://googledata.org/igoogle/variable-substitution-and-getmsg-2/ https://googledata.org/igoogle/variable-substitution-and-getmsg-2/#comments Tue, 04 May 2010 01:55:00 +0000 https://googledata.org/?guid=6aacc30ac2ea5c7761fece6c73a0a9ad 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.]]> 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.]]> https://googledata.org/igoogle/variable-substitution-and-getmsg-2/feed/ 0 Variable Substitution and getMsg https://googledata.org/igoogle/variable-substitution-and-getmsg/ https://googledata.org/igoogle/variable-substitution-and-getmsg/#comments Tue, 04 May 2010 01:55:00 +0000 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.
]]> https://googledata.org/igoogle/variable-substitution-and-getmsg/feed/ 0 Google acquires Labpixies https://googledata.org/igoogle/google-acquires-labpixies/ https://googledata.org/igoogle/google-acquires-labpixies/#comments Tue, 27 Apr 2010 05:50:00 +0000
Not everyone likes to start their day with just a search box and logo (no matter how cool it is!). Many users want email, videos, news, weather, games, and other information to be at their fingertips each time they open up a browser window. We launched iGoogle in 2005 to address this need by providing a truly personalized homepage with access to any RSS feed and well over a hundred thousand gadgets.

One of the first developers to create gadgets for iGoogle was Labpixies. Over the years, we worked closely together on a variety of projects, including the launch of a number of global OpenSocial based gadgets. Recently, we decided that we could do more if we were part of the same team, and as such, we're thrilled to announce the acquisition of Labpixies.

The team will be based in our ever-growing Tel Aviv office and will anchor our iGoogle efforts across Europe, the Middle East, and Africa. We are looking forward to working with Labpixies to develop great web apps and leverage their knowledge and expertise to help developers and improve the ecosystem overall.

In the meantime, have fun trying to beat me at Flood-It!

By Don Loeb, iGoogle Team
]]> https://googledata.org/igoogle/google-acquires-labpixies/feed/ 0 Sometimes blue text just isn’t enough https://googledata.org/igoogle/sometimes-blue-text-just-isnt-enough/ https://googledata.org/igoogle/sometimes-blue-text-just-isnt-enough/#comments Thu, 22 Apr 2010 17:20:00 +0000 https://googledata.org/?guid=6d2a9c3a07fd6f5b2a868692790db4bb
With this new feature, users have three different display views.

Headline only
Headline only view

SlideshowHeadline and lead story
Slideshow and Headline and lead story views

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:


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]]>
With this new feature, users have three different display views.

Headline only
Headline only view

SlideshowHeadline and lead story
Slideshow and Headline and lead story views

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:


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]]> https://googledata.org/igoogle/sometimes-blue-text-just-isnt-enough/feed/ 0 Sometimes blue text just isn’t enough https://googledata.org/igoogle/sometimes-blue-text-just-isn%e2%80%99t-enough/ https://googledata.org/igoogle/sometimes-blue-text-just-isn%e2%80%99t-enough/#comments Thu, 22 Apr 2010 17:20:00 +0000
With this new feature, users have three different display views.

Headline only
Headline only view

SlideshowHeadline and lead story
Slideshow and Headline and lead story views

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:


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
]]> https://googledata.org/igoogle/sometimes-blue-text-just-isn%e2%80%99t-enough/feed/ 0 UserPrefs in Gadget URLs https://googledata.org/igoogle/userprefs-in-gadget-urls/ https://googledata.org/igoogle/userprefs-in-gadget-urls/#comments Wed, 21 Apr 2010 02:43:00 +0000
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
]]> https://googledata.org/igoogle/userprefs-in-gadget-urls/feed/ 0 UserPrefs in Gadget URLs https://googledata.org/igoogle/userprefs-in-gadget-urls-2/ https://googledata.org/igoogle/userprefs-in-gadget-urls-2/#comments Wed, 21 Apr 2010 02:43:00 +0000 https://googledata.org/?guid=0b2015bf4efbb2fc9cce057a7b50c867
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
]]> https://googledata.org/igoogle/userprefs-in-gadget-urls-2/feed/ 0 Migration made easier https://googledata.org/igoogle/migration-made-easier/ https://googledata.org/igoogle/migration-made-easier/#comments Thu, 25 Mar 2010 20:30:00 +0000 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
]]> https://googledata.org/igoogle/migration-made-easier/feed/ 0 Migration made easier https://googledata.org/igoogle/migration-made-easier-2/ https://googledata.org/igoogle/migration-made-easier-2/#comments Thu, 25 Mar 2010 20:30:00 +0000 https://googledata.org/?guid=c7e9a03e9eb7a245723dabfc91f20295 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]]> 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]]> https://googledata.org/igoogle/migration-made-easier-2/feed/ 0 The forums, they are a-changin’ https://googledata.org/igoogle/the-forums-they-are-a-changin/ https://googledata.org/igoogle/the-forums-they-are-a-changin/#comments Thu, 04 Mar 2010 18:41:00 +0000 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
]]> https://googledata.org/igoogle/the-forums-they-are-a-changin/feed/ 0 The forums, they are a-changin’ https://googledata.org/igoogle/the-forums-they-are-a-changin-2/ https://googledata.org/igoogle/the-forums-they-are-a-changin-2/#comments Thu, 04 Mar 2010 18:41:00 +0000 https://googledata.org/?guid=01a97e8f0734d33ecf3a7d7d037b9502 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]]> https://googledata.org/igoogle/the-forums-they-are-a-changin-2/feed/ 0 New features on the Developer Dashboard https://googledata.org/igoogle/new-features-on-the-developer-dashboard/ https://googledata.org/igoogle/new-features-on-the-developer-dashboard/#comments Tue, 16 Feb 2010 19:03:00 +0000 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
]]> https://googledata.org/igoogle/new-features-on-the-developer-dashboard/feed/ 0 New features on the Developer Dashboard https://googledata.org/igoogle/new-features-on-the-developer-dashboard-2/ https://googledata.org/igoogle/new-features-on-the-developer-dashboard-2/#comments Tue, 16 Feb 2010 19:03:00 +0000 https://googledata.org/?guid=fe8b30813c7808f62b001ff8bd4bf6c7 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]]> https://googledata.org/igoogle/new-features-on-the-developer-dashboard-2/feed/ 0 ​Last phase of inlined gadget deprecation https://googledata.org/igoogle/%e2%80%8blast-phase-of-inlined-gadget-deprecation/ https://googledata.org/igoogle/%e2%80%8blast-phase-of-inlined-gadget-deprecation/#comments Fri, 22 Jan 2010 19:41:00 +0000 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
]]> https://googledata.org/igoogle/%e2%80%8blast-phase-of-inlined-gadget-deprecation/feed/ 0 ​Last phase of inlined gadget deprecation https://googledata.org/igoogle/%e2%80%8blast-phase-of-inlined-gadget-deprecation-2/ https://googledata.org/igoogle/%e2%80%8blast-phase-of-inlined-gadget-deprecation-2/#comments Fri, 22 Jan 2010 19:41:00 +0000 https://googledata.org/?guid=58dfd36c70dd51c18f2a4df83b6cd906 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]]> 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]]> https://googledata.org/igoogle/%e2%80%8blast-phase-of-inlined-gadget-deprecation-2/feed/ 0 An update on the legacy API deprecation https://googledata.org/igoogle/an-update-on-the-legacy-api-deprecation/ https://googledata.org/igoogle/an-update-on-the-legacy-api-deprecation/#comments Fri, 18 Dec 2009 01:25:00 +0000 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
]]> https://googledata.org/igoogle/an-update-on-the-legacy-api-deprecation/feed/ 0 An update on the legacy API deprecation https://googledata.org/igoogle/an-update-on-the-legacy-api-deprecation-2/ https://googledata.org/igoogle/an-update-on-the-legacy-api-deprecation-2/#comments Fri, 18 Dec 2009 01:25:00 +0000 https://googledata.org/?guid=f3d0d9e0825bdf13cb397e448392e7e2 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]]> https://googledata.org/igoogle/an-update-on-the-legacy-api-deprecation-2/feed/ 0 Amigos! Freunde! Friends! Друзья! https://googledata.org/igoogle/amigos-freunde-friends-%d0%b4%d1%80%d1%83%d0%b7%d1%8c%d1%8f/ https://googledata.org/igoogle/amigos-freunde-friends-%d0%b4%d1%80%d1%83%d0%b7%d1%8c%d1%8f/#comments Mon, 23 Nov 2009 23:07:00 +0000 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
]]> https://googledata.org/igoogle/amigos-freunde-friends-%d0%b4%d1%80%d1%83%d0%b7%d1%8c%d1%8f/feed/ 0 Amigos! Freunde! Friends! Друзья! https://googledata.org/igoogle/amigos-freunde-friends-%d0%b4%d1%80%d1%83%d0%b7%d1%8c%d1%8f-2/ https://googledata.org/igoogle/amigos-freunde-friends-%d0%b4%d1%80%d1%83%d0%b7%d1%8c%d1%8f-2/#comments Mon, 23 Nov 2009 23:07:00 +0000 https://googledata.org/?guid=f488740175e2ba40c2d128699b55a656 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]]> https://googledata.org/igoogle/amigos-freunde-friends-%d0%b4%d1%80%d1%83%d0%b7%d1%8c%d1%8f-2/feed/ 0 Launching the iGoogle Gadget Dashboard https://googledata.org/igoogle/launching-the-igoogle-gadget-dashboard/ https://googledata.org/igoogle/launching-the-igoogle-gadget-dashboard/#comments Fri, 20 Nov 2009 23:03:00 +0000
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
]]> https://googledata.org/igoogle/launching-the-igoogle-gadget-dashboard/feed/ 0 Launching the iGoogle Gadget Dashboard https://googledata.org/igoogle/launching-the-igoogle-gadget-dashboard-2/ https://googledata.org/igoogle/launching-the-igoogle-gadget-dashboard-2/#comments Fri, 20 Nov 2009 23:03:00 +0000 https://googledata.org/?guid=fe28f7090e0c3a96428135f32cf34ed8
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]]> https://googledata.org/igoogle/launching-the-igoogle-gadget-dashboard-2/feed/ 0 Hot off the press: gadgets.* migration guide https://googledata.org/igoogle/hot-off-the-press-gadgets-migration-guide-2/ https://googledata.org/igoogle/hot-off-the-press-gadgets-migration-guide-2/#comments Mon, 19 Oct 2009 21:55:00 +0000 https://googledata.org/?guid=e0e93ebbb011122708a76c4f79412cee 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]]> https://googledata.org/igoogle/hot-off-the-press-gadgets-migration-guide-2/feed/ 0 Hot off the press: gadgets.* migration guide https://googledata.org/igoogle/hot-off-the-press-gadgets-migration-guide/ https://googledata.org/igoogle/hot-off-the-press-gadgets-migration-guide/#comments Mon, 19 Oct 2009 21:55:00 +0000 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
]]> https://googledata.org/igoogle/hot-off-the-press-gadgets-migration-guide/feed/ 0 Deprecating shareable-prefs API on iGoogle https://googledata.org/igoogle/deprecating-shareable-prefs-api-on-igoogle-2/ https://googledata.org/igoogle/deprecating-shareable-prefs-api-on-igoogle-2/#comments Tue, 29 Sep 2009 23:41:00 +0000 https://googledata.org/?guid=75a936949335595e640d0f6724856da0
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]]> https://googledata.org/igoogle/deprecating-shareable-prefs-api-on-igoogle-2/feed/ 0 Deprecating shareable-prefs API on iGoogle https://googledata.org/igoogle/deprecating-shareable-prefs-api-on-igoogle/ https://googledata.org/igoogle/deprecating-shareable-prefs-api-on-igoogle/#comments Tue, 29 Sep 2009 23:41:00 +0000
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
]]> https://googledata.org/igoogle/deprecating-shareable-prefs-api-on-igoogle/feed/ 0 Reinforcements in the war on slow https://googledata.org/igoogle/reinforcements-in-the-war-on-slow/ https://googledata.org/igoogle/reinforcements-in-the-war-on-slow/#comments Fri, 18 Sep 2009 23:09:00 +0000
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
]]> https://googledata.org/igoogle/reinforcements-in-the-war-on-slow/feed/ 0 Reinforcements in the war on slow https://googledata.org/igoogle/reinforcements-in-the-war-on-slow-2/ https://googledata.org/igoogle/reinforcements-in-the-war-on-slow-2/#comments Fri, 18 Sep 2009 23:09:00 +0000 https://googledata.org/?guid=a6e4d69815407c7d06d5fe76151b02cb
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]]> https://googledata.org/igoogle/reinforcements-in-the-war-on-slow-2/feed/ 0 Legacy gadget API deprecation https://googledata.org/igoogle/legacy-gadget-api-deprecation/ https://googledata.org/igoogle/legacy-gadget-api-deprecation/#comments Mon, 14 Sep 2009 22:57:00 +0000 gadgets.* API, a re-namespaced and improved version of the original legacy, or _IG_*, gadgets API. The gadgets.* API has gained wide acceptance, both on Google and non-Google gadget containers, and is the standard API for gadget development.

However, there remains a number of gadgets using the legacy API, primarily gadgets developed for iGoogle, and the time to upgrade those gadgets is now. As of today, the legacy gadgets API is officially deprecated. For a period of one year, gadgets using the legacy API will continue to be supported, and function. After that, the legacy API will be turned off for the majority of Google containers (such as iGoogle, orkut, Gmail, and Calendar).

For more specifics on how the deprecation affects iGoogle developers, and details on coming resources to help in the API transition, check out this post on the iGoogle developer blog.

By Dan Holevoet, Developer Programs
]]> https://googledata.org/igoogle/legacy-gadget-api-deprecation/feed/ 0 The more things change, the more they stay the same https://googledata.org/igoogle/the-more-things-change-the-more-they-stay-the-same/ https://googledata.org/igoogle/the-more-things-change-the-more-they-stay-the-same/#comments Mon, 14 Sep 2009 19:08:00 +0000 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
]]> https://googledata.org/igoogle/the-more-things-change-the-more-they-stay-the-same/feed/ 0 The more things change, the more they stay the same https://googledata.org/uncategorized/the-more-things-change-the-more-they-stay-the-same-2/ https://googledata.org/uncategorized/the-more-things-change-the-more-they-stay-the-same-2/#comments Mon, 14 Sep 2009 19:08:00 +0000 https://googledata.org/?guid=82d56216bf2e3291b5aab3941d27a63c 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
]]> https://googledata.org/uncategorized/the-more-things-change-the-more-they-stay-the-same-2/feed/ 0 Going faster than a roller coaster https://googledata.org/igoogle/going-faster-than-a-roller-coaster/ https://googledata.org/igoogle/going-faster-than-a-roller-coaster/#comments Mon, 31 Aug 2009 20:27:00 +0000 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
]]> https://googledata.org/igoogle/going-faster-than-a-roller-coaster/feed/ 0 iGoogle adds support for OpenSocial https://googledata.org/igoogle/igoogle-adds-support-for-opensocial/ https://googledata.org/igoogle/igoogle-adds-support-for-opensocial/#comments Wed, 12 Aug 2009 23:10:00 +0000 Developers using the OpenSocial API can now reach tens of millions of iGoogle users! As of this week, iGoogle now supports OpenSocial in both the US and Australia, with the plan to roll it out to more users soon. In general, we think "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. These are all things that iGoogle users love to do, so making them social on iGoogle was the next logical next step.

If you're interested in getting started writing social gadgets for iGoogle, check out the full announcement on the iGoogle developer blog.

By Dan Holevoet, Google Developer Team
]]> https://googledata.org/igoogle/igoogle-adds-support-for-opensocial/feed/ 0 iGoogle is a social being https://googledata.org/igoogle/igoogle-is-a-social-being/ https://googledata.org/igoogle/igoogle-is-a-social-being/#comments Wed, 12 Aug 2009 19:56:00 +0000
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:
  1. 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.
  2. 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.
  3. 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.
  4. 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
]]> https://googledata.org/igoogle/igoogle-is-a-social-being/feed/ 0 Every happy gadget is the same, every unhappy gadget is unhappy in it’s own way https://googledata.org/igoogle/every-happy-gadget-is-the-same-every-unhappy-gadget-is-unhappy-in-its-own-way/ https://googledata.org/igoogle/every-happy-gadget-is-the-same-every-unhappy-gadget-is-unhappy-in-its-own-way/#comments Wed, 05 Aug 2009 21:13:00 +0000 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.
  1. 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.

  2. 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."

  3. 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."

  4. 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!

  5. 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
]]> https://googledata.org/igoogle/every-happy-gadget-is-the-same-every-unhappy-gadget-is-unhappy-in-its-own-way/feed/ 0 Announcing UX improvements in the sandbox https://googledata.org/igoogle/announcing-ux-improvements-in-the-sandbox/ https://googledata.org/igoogle/announcing-ux-improvements-in-the-sandbox/#comments Thu, 02 Jul 2009 23:53:00 +0000
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
]]> https://googledata.org/igoogle/announcing-ux-improvements-in-the-sandbox/feed/ 0 Stem the 401 Tide https://googledata.org/igoogle/stem-the-401-tide/ https://googledata.org/igoogle/stem-the-401-tide/#comments Thu, 02 Jul 2009 17:13:00 +0000 http://www.google.com/ig?force_sandbox=1 for a squeaky-clean and error-free sandbox.

Posted by Dan Holevoet, Developer Programs
]]> https://googledata.org/igoogle/stem-the-401-tide/feed/ 0 An update on "Updates" https://googledata.org/igoogle/an-update-on-updates/ https://googledata.org/igoogle/an-update-on-updates/#comments Tue, 26 May 2009 23:00:00 +0000
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
]]> https://googledata.org/igoogle/an-update-on-updates/feed/ 0 The importance of being unsociable https://googledata.org/igoogle/the-importance-of-being-unsociable/ https://googledata.org/igoogle/the-importance-of-being-unsociable/#comments Fri, 15 May 2009 00:53:00 +0000
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
]]> https://googledata.org/igoogle/the-importance-of-being-unsociable/feed/ 0 Gadget Checker: A simple way to make good gadgets great https://googledata.org/igoogle/gadget-checker-a-simple-way-to-make-good-gadgets-great/ https://googledata.org/igoogle/gadget-checker-a-simple-way-to-make-good-gadgets-great/#comments Tue, 05 May 2009 16:54:00 +0000
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
]]> https://googledata.org/igoogle/gadget-checker-a-simple-way-to-make-good-gadgets-great/feed/ 0 Insights for Search iGoogle Gadget https://googledata.org/igoogle/insights-for-search-igoogle-gadget/ https://googledata.org/igoogle/insights-for-search-igoogle-gadget/#comments Mon, 06 Apr 2009 13:26:00 +0000 A few weeks ago, we introduced Google Insights for Search and showed you how you can capitalise on search trends by knowing what your target audience are searching for on Google. Using on-trend search terms within your online marketing campaigns will ensure that your message is as relevant to your audience as it can be.

To make things even easier for you, we have created a search trends iGoogle gadget which displays the 'Top rising searches' and 'Top related searches' right on your Google homepage. You can change the settings to show results for a specific location, keyword, category or source in order to have the most up to date information available for your industry or product.


* Data pulled 06/04/09


The screenshot to the left shows 'Rising Searches' within the 'Sports' category for the UK and could be used for travel, retail or promotional opportunities. The second screenshot shows the 'Top Searches' in the UK for the last 7 days with the relative traffic displayed for each search term. This gives an idea of the overall trend in searches in the UK and insight into how your target audience is browsing the web and spending their time online.

Adding this gadget to your homepage only takes a few seconds and results update automatically so you can stay on top of trends, or be aware of any news story which may impact search volume for some of your keywords.

If you are currently signed into your Google Account, the gadget will automatically add to your iGoogle homepage.

New data sources - We've added additional data from Google News, Image and Product Search sites so you can see what the world is searching for beyond Google Web Search. For example, retailers could use the Product Search filter to get a better understanding of what people are more likely to buy, and then stock the appropriate products.


 Not yet created your iGoogle homepage?
 With iGoogle, you can have Google search as your homepage, but with a personal touch. Learn how you can customise iGoogle to show and organise contents such as your latest Gmail messages, chat, calendar, bookmarks, RSS Feeds, gadgets and more.


 Posted By Ruth Brennan, Google Team

]]> https://googledata.org/igoogle/insights-for-search-igoogle-gadget/feed/ 0 Signing changes in the iGoogle sandbox https://googledata.org/igoogle/signing-changes-in-the-igoogle-sandbox/ https://googledata.org/igoogle/signing-changes-in-the-igoogle-sandbox/#comments Fri, 03 Apr 2009 17:31:00 +0000 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
]]> https://googledata.org/igoogle/signing-changes-in-the-igoogle-sandbox/feed/ 0 The sandbox prods along https://googledata.org/igoogle/the-sandbox-prods-along/ https://googledata.org/igoogle/the-sandbox-prods-along/#comments Thu, 19 Mar 2009 21:34:00 +0000
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
]]> https://googledata.org/igoogle/the-sandbox-prods-along/feed/ 0 Are you in the sandbox? Here’s a quick way to check https://googledata.org/igoogle/are-you-in-the-sandbox-heres-a-quick-way-to-check/ https://googledata.org/igoogle/are-you-in-the-sandbox-heres-a-quick-way-to-check/#comments Tue, 24 Feb 2009 21:22:00 +0000
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
]]> https://googledata.org/igoogle/are-you-in-the-sandbox-heres-a-quick-way-to-check/feed/ 0 iGoogle’s getting some changes under the hood https://googledata.org/igoogle/igoogles-getting-some-changes-under-the-hood/ https://googledata.org/igoogle/igoogles-getting-some-changes-under-the-hood/#comments Fri, 23 Jan 2009 22:56:00 +0000 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
]]> https://googledata.org/igoogle/igoogles-getting-some-changes-under-the-hood/feed/ 0 New ACLs on social features https://googledata.org/igoogle/new-acls-on-social-features/ https://googledata.org/igoogle/new-acls-on-social-features/#comments Wed, 14 Jan 2009 22:29:00 +0000
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
]]> https://googledata.org/igoogle/new-acls-on-social-features/feed/ 0 REST and RPC support in the developer sandbox https://googledata.org/igoogle/rest-and-rpc-support-in-the-developer-sandbox/ https://googledata.org/igoogle/rest-and-rpc-support-in-the-developer-sandbox/#comments Fri, 19 Dec 2008 23:41:00 +0000 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
]]> https://googledata.org/igoogle/rest-and-rpc-support-in-the-developer-sandbox/feed/ 0 Sign in to MySpace, AOL Mail, and Google Books gadgets https://googledata.org/igoogle/sign-in-to-myspace-aol-mail-and-google-books-gadgets/ https://googledata.org/igoogle/sign-in-to-myspace-aol-mail-and-google-books-gadgets/#comments Wed, 19 Nov 2008 18:20:00 +0000 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
]]> https://googledata.org/igoogle/sign-in-to-myspace-aol-mail-and-google-books-gadgets/feed/ 0