Sometimes blue text just isn’t enough

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

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