Netvibes Developers blog

Netvibes  users were long used to using the Feed Reader widget which, combined with the internal full-page feed reader, makes for the greatness of Netvibes as a feed agregator, and from there on, as a complete digital dashboard.

Feed widget in normal view

Back in December 2008, we updated our Feed Reader widget with three new views (Ticker, Carousel, Magazine) ; we added four more feed views in March 2009 (Classy Slideshow and its black-background version, Headline, and Quick Details), bringing a total of 8 possible views for your feed. Netvibes users can then choose the most appropriate view for a given feed, and bring more variety to the whole page: feeds can now stand out, image-centric feeds are better than ever, it makes it easy to discernate between two feeds, etc.

Feed widget in Magazine view

All in all, these new views not only bring a whole better feedreading experience to the Netvibes users, but they can also prove to be very handy for those whishing to build some greate public pages based solely on feeds – with a the help of Flexible Layout tool that was also released in December 2008.

Feed widget with Ticket view

So, users can choose to set their page with different views, public pages editors can present their content in a great fashion of ways, but one point remains: how to you make sure that YOUR feeds can work properly with these new views?

How can you make use of them?

The best way for your feeds to be correctly handled by our various views, is to have them carry a proper link to your media content (most of the time, an image, but it could also be audio or video). This way, the feedreader can display more than just text, which in turn will make your feed stand out in the crowd of those without an image. Simple as that.

Feed widget in Classy view

There is a handful of way to do this in the world of feeds, the most popular being:

• enclosures ;
• MediaRSS ;
• parsing of the post’s content.

…which are all supported by Netvibes, of course!

Let’s explore each of these solutions…

Enclosures

Enclosures rely on a special type of XML tag, which have been supported by the RSS and Atom formats for a long time, and that all major feed readers now understand. In these two popular feed formats, enclosures simply point to one (or many) media files, along with useful metadata about these. Feed readers can in turn make use of these informations to display the media files along (or after) the post’s content.

The <enclosure> element was added to RSS back in 2000, when broadband was still rare and it would make better sense to let feedreader download a feed’s huge files during idle time (at night, for instance), allowing the user to come back to his/her feed reader with all files downloaded.

Using enclosures, an editor (or editing tool) can add an absolute URL to a file, to be dealt with by the feed reader accordingly. In the case of podcasting, that enclosed file would be an MP3 file (or some video format for “vidcasting”), file which the feed reader would download silently and make available to the user for his listening (or viewing) pleasure. Nowadays however, thanks to omnipresent broadband and cheaper bandwidth, files can just be listened through directly – such as is possible with Netvibes, with the podcast player.

Feed widget with Slideshow view

Even for non-podcasters, enclosures can be useful simply in order to point the feedreader to a thumbnail image, which would bring more life to the feed in some feedreaders, and help it stand out in the crowd…

MediaRSS

MediaRSS is an extension to the RSS 2.0 file-format, trying to solve one issue: enclosures in RSS could only link one media file per files. While one was enough at the birth of podcasting, now podcasters like to spread their audio/video files over more than a single, or include some more interesting media content besides the main file itself. This was solved right at the beginning in Atom, but the RSS format being frozen, extensions where needed.

In these case, the Yahoo! developers stepped up and proposed MediaRSS, which immensely improves on RSS enclosure tag, adding support for such much-needed data as thumbnail, title, description, keyword or even player source URL, for each link file.

Sadly, not all feed readers do understand MediaRSS, which leads to some CMS and feed-generators to not put this extension to wider use.
Why so? Once you build upon a much-successful format, having your extension of that format adopted by the very people it targets can be hair-threatening. It’s very much like a Catch-22 – or a chicken-and-egg dilemma, if you will:

• Why would data publishers implement your extension if no tool support it?
• Why would tools support it if no data publishers implement it?

We at Netvibes chose to support that extension as much as we could, since it the best way to benefit our users. Therefore, we fully encourage you to make use of MediaRSS, and help spread its usefulness.

Parsing

Alas, not all feeds/CMSs do implement MediaRSS — or even enclosures, for that matter. Still, there is no reason why these feeds would not have their image nicely thumbnailed for all to see. In this case, feedreaders cannot rely on standardized tags, and therefore have to rely on magic.

Magic, or in our case parsing, which means that the post’s content is scanned by the Netvibes feedreader, all the images are gathered, and the first one in the post is then used as a thumbnail. Problem solved. Magic, I tell you.

One recurring pitfal that you should strive to avoid: smileys. Along with social network buttons, they represent the culprit of badly-chosen thumbnails, and would most of the time happen when parsing is necessary (no enclosure nor MediaRSS tags to be found). While this misshap is pretty much unavoidable for image-less posts (we’re working on a solution), bloggers who use images in their posts can sometimes be surprised to find a smiley instead of their beautifuly crafted illustration.

Smileys gone bad

The explanation is easy: as said earlier, the post parsing makes a list of all images in the post, then uses the first image as the thumbnail. Therefore, in order for the first big image to be used as a thumbnail, you should try as much as possible to either…

• put the image as for the first content of the post, even before the text itself ;
• never use a smiley before the first image of the post.

Still, this remains a constrains, and we’re currently working on a solution around that issue…

How it all works out in the end

Because some feeds can propose both enclosures and MediaRSS tags, it’s up to the feereader to sort the wheat from the hay. Here’s how we decided to make it work at Netvibes :

• In the case of thumbnails :
  1. use the first <enclosure> tag ;
  2. use the first <media:thumbnail> tag ;
  3. use the first image within the <media:content> tag ;
  4. use the first image within the post’s content.
• In the case of videos :
  • we exploit the <media:content> tag that has a content-type of “application/x-shockwave-flash”.

As you can see, the best way to have your media files be correctly handled by the Netvibes feedreader, is to use the great MediaRSS extension to your RSS feed. Since not all CMSs support it out-of-the-box, you might have to dig for existing extension – here’s one for WordPress, and another one for Drupal, for instance. Know of more? Come and share them in the comments!

This entry was posted on Tuesday, September 1st, 2009 at 1:46 pm and is filed under Articles. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.