stressfree - rss

Google Reader is now my primary RSS experience

David — Mon, 19 Feb 2007 19:37:54 +0000

I have been using NewsGator's NetNewsWire for Mac RSS reader for years but yesterday I moved all my RSS feeds over to Google Reader and closed NetNewsWire for good. There are lots of things to like about NetNewsWire like its tabbed windows, responsiveness and polished look and feel, but even with these things in mind it struggles to compete with the best online RSS readers out there today.

I played around with Google Reader in its first carnation last year but its interface went over my head. It seemed to me they were trying to be clever with news rather than give users an interface they were used to and actually wanted. Recently Google re-released Reader in a far more conventional guise making the overall experience very similar to traditional RSS readers with a few added bonuses.

Google Reader with the Google Reader Firefox extension visible in the bottom right corner of the window (click to enlarge)

So how does Google Reader, a Web-based application overcome NetNewsWire's OSX savvy advantages?

Responsiveness

Thanks to a hefty dose of AJAX Google Reader is almost as responsive as NetNewsWire even though it is running in a browser. Also to keep an eye on unread news I have also installed the Google Reader Firefox extension which gives brief summary of the current unread news without having to open Reader.

Aesthetics

Google's aesthetics with Reader seem to be significantly more polished than that of its more mature products like search and GMail. Sure it does not have all of the OSX bling that NetNewsWire supports but it is clean and stylish enough to be used without getting sore eyes.

Always synchronised

Being Web-based Google Reader is always available and synchronised no matter which computer you maybe using. NetNewsWire supports synchronisation to NewsGator's online reader and between different NetNewsWire instances but it has never quite worked. This all stems back to the fact NewsGator does not appear to be focusing on sorting out these bugs and seems quite content to let their users struggle along or move to another service.

Web-centric functionality

Google Reader offers little pieces of Web-centric functionality like a one-click option to share a selected story with other people via RSS or embedded within a web page. This means you can go through your news highlighting and sharing things that maybe of interest to others with minimal effort. Easy to use functionality like this just is not available in NetNewsWire without signing up to a third party service like del.icio.us.

Resource Usage

NetNewsWire can also be a resource hog once it has been running for a while with multiple tabs open. Generally this equates to about 100meg of RAM and anywhere between 300-600meg of swap space consumed. Google Reader on the other hand works within an Internet browser so it only uses as much as what its host browser needs. With Firefox this can equate to a lot of resources but by not having NetNewsWire open the overall system resource hit is not nearly as bad.

Conclusion

Given these benefits and the functionality of Google Reader making the decision to switch from a program I have used for many years was not that difficult. So far I am enjoying the experience and my Mac is welcoming the extra system resources. Rather ironically the only thing Google Reader needs now is search functionality and the ability to tag news items based on these search results and I will be content.

google
rss

Searching across websites with OpenSearch

David — Mon, 18 Dec 2006 01:14:36 +0000

Providing search services that span a number of disparate websites is a challenging problem that in the past has been left to the big-boys such as Google. However Amazon's OpenSearch RSS format is changing this reality and providing a means for effective multiple website search to be deployed at low cost by small development teams.

Background

Most organisations comprise of a number of different interest groups (I like to think of them as factions) and when it comes to external and internal websites it proves far more efficient to let these groups build and maintain their own independent sites rather than combine them under a single unified banner and management structure. The reasons for this are pragmatic rather than technical, in fact from a purely technical perspective it is far easier to concentrate on building a single massive website as this means one architecture, one management group and a homogonised user base.

In reality the idea of a single website that rules them all is almost impossible to realise. Because the stakes are so high and the number of participants so diverse making decisions is a slow and politically painful process. Such a minefield can be avoided if the management team is lead by a strong willed, 'my way or the highway' personality who can make clear decisions that allow the technical team to produce the best possible solution. Unfortunately the chances of being involved with a management team that has a strong leader who is also capable of juggling Web, technical and business needs gets even lower, and without such skills the project maybe even more danger than one without such a personality.

Consequently it is generally preferable to allow the individual groups to develop their own websites independently of each other thereby spreading risk and distributing political friction. From a user perspective such a strategy is beneficial because it allows solutions to be tailored to the specific business needs and technical capability of the group rather than satisfying the imagined needs of the 'average' user. Unfortunately from a technical perspective this distributed architecture not only dilutes resources but it also raises a number of questions around identity management and areas where organisation resources should be unified such as search. With good planning the problem of identity can be resolved through intelligent use of directory systems, for example eDirectory and its associated technologies. Searching multiple, perhaps dramatically different websites however is a different problem altogether.

Providing dynamic search without a Google-like infrastructure

The traditional approach of solving cross-party search is to use an independent search index such as a Google appliance or in-house created solution. The primary drawback of such an approach is that this independent system requires as much ongoing maintenance as the websites it is intended to service. From the perspective of the user search results from a cached search index can also leave out the latest content or be out of date. From a productivity and user satisfaction perspective this can almost be worse than having no search functionality at all. A more effective solution that provides up to date results without the need of an independent search system is provided by Amazon's OpenSearch format and RSS aggregation as illustrated by the diagram below:

Instead of providing a separate search architecture OpenSearch is intended to be applied within existing search mechanisms present in the individual websites. Rather than presenting traditional HTML formatted search results an OpenSearch enabled search engine returns results as a specially formatted RSS feed. RSS is a simple XML standard for sharing information about website content that is rapidly gaining widespread industry acceptance. Because it is formatted in a manner computers can read RSS allows content on a website to be processed and acted upon automatically without human intervention. The upside of this is that multiple OpenSearch RSS feeds from disparate organisation websites can be aggregated (retrieved and combined) by the computer and presented to the user as a single set of up to date and relevant search results. This standardised process negates the need for a dedicated, organisation-wide search index as each of the websites in question can perform this task easily themselves. The added benefit of such a model is that results can be tailored to the needs of the user group in question rather than being returned in the one size fits all format an independent search index provides.

Implementing OpenSearch aggregation

Considering its benefits implementing OpenSearch style searching is getting easier by the day. For example the Drupal content management system now offers two open source modules that provide both OpenSearch search results and multi-site OpenSearch aggregation. Consequently this functionality can be implemented in minutes instead of the days needed in a traditional independent search index approach at a fraction of the cost.

Whilst Amazon's OpenSearch may not be the ultimate incarnation of the RSS-based search concept it is mature and signals the way ahead for the technology. Considering the rate of development in the field the next few years will definitely be very exciting when it comes to simple, syndicated search that is accessible to the masses. If the concept proves successful it may herald the downfall of the global search index as the best way of finding things on the Internet.

Dave Winer's views on the acceptance of RSS

David — Mon, 23 Jan 2006 04:16:32 +0000

A few days ago Dave Winer wrote a good post on the real drivers (from his perspective) of RSS apart from himself was the publishing industry, namely the New York Times in 2002. His reasoning is quite interesting, the tech industry couldn't drive the adoption of a new standard because it would make the playing field too even. It makes sense for competitors to use different standards because it creates lock-in and along with lock-in you have control. It took the publishing industry, who at the time did not feel threatened by the online environment like they do today, took take the standard and put it to use.

thesis
rss

RSS Feed Online

David — Tue, 30 Aug 2005 01:48:40 +0000

After a bit of tinkering I have a FeedBurner (RSS & Atom) feed for this subject online. It can be subscribed to here. The issue was my content management system (Mambo 4.5.1) only natively supporting feeds of the site frontpage. Fortunately there is an add-on that supports multiple site feeds but setting this up is far from intuitive. Oh well, its up now I guess.

It's actually interesting to see the development of the different RSS/Atom standards. RSS begun development as a group project but then a difference of opinion between Dave Winer and a number of other members split the project in two. Dave Winer produced RSS 0.91 whilst a little while later the working group came out with RSS 1.0.

I've listened to a few podcasts with Dave Winer and I definitely would not want to get on his wrong side. What he does firmly believe in is that things should be simple, not complex and that is just what his subsequent RSS 2.0 set out to achieve. Whilst RSS 1.0 was based on RDF tag syntax RSS 2.0 dropped that in favour of very simple, comprehensible syntax. Consequently RSS 2.0 wiped the floor with RSS 1.0.

Atom is a later development that has begun to tackle the difficult problems of transactions and different payloads, especially as RSS has begun to be acknowledged as a very good way of communicating (syndicating) information across a wide audience. Like RSS 2.0, Atom has left RDF syntax behind and is focusing on practical needs rather than academic principles. Unlike RSS, Atom uses a far stricter XML syntax that has led it to be incompatible with the RSS 1.0/2.0 standards...