Images In RSS Around the World

Monday, May 10, 2010 at 9:58 AM

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

Post content Posted by Rob Russell, Developer Relations

Variable Substitution and getMsg

Monday, May 3, 2010 at 6:55 PM

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

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

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

dirbox.innerHTML = '__MSG_north__';

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

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

And some similar Javascript

dinersign.innerHTML = '__MSG_dinername__';

Everything works fine until we add the English translation

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

And the code the gadget tries to run is

dinersign.innerHTML = 'Sophie's Place';

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

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

var init = function () {

var prefs = new gadgets.Prefs();

dinersign = document.getElementById("dinersign");

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

};

gadgets.util.registerOnLoadHandler(init);

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

Sometimes blue text just isn’t enough

Thursday, April 22, 2010 at 10:20 AM

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

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

Headline only

SlideshowHeadline and lead story

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

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

Here are a sampling of feeds to try out:

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

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

Posted by James Lee, iGoogle Engineer

UserPrefs in Gadget URLs

Tuesday, April 20, 2010 at 7:43 PM

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

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

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

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

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

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

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

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

Posted by Rob Russell, Developer Relations

Migration made easier

Thursday, March 25, 2010 at 1:30 PM

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

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

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

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

Posted by Dan Holevoet, Developer Programs

The forums, they are a-changin'

Thursday, March 4, 2010 at 10:41 AM

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

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

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

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

Posted by Rob Russell, Developer Relations

New features on the Developer Dashboard

Tuesday, February 16, 2010 at 11:03 AM

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

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

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

Happy developing!

Posted by Sascha Haberling, Tech Lead