RSS Bandwidth: Make the Aggregator Smarter

I was just reading Brent Ashley where he talked about dropping Scoble's RSS feed.  This made me think more than a bit about aggregators and I'm wondering if I'm missing something here.  I've NEVER dropped a feed.  Never.  And I also rarely go into the aggregator.  I like to read blogs as their author intended me to -- in the context of a page, not through an aggregator.  Now don't get me wrong, I think aggregators are great but for whatever reason they just don't feel right to me.  And I know that I'm not the only one.  I've heard this from others. 

So, while I don't want to demean the move towards etag and format extensions to save bandwidth, isn't there another option here?  What about making the aggregator smarter like this:

• If the aggregator url isn't getting viewed when you click on it in Radio / Drupal / Whatever just stop pulling down feeds.  Since feeds are purged anyway (at least in Radio) then this really wouldn't make much difference now, would it?  So if the user doesn't use it then automatically turn off.  I think a lot of Radio users are like me -- we start with an aggregator, come to dislike it or just plain not like it and then stop using it -- but we NEVER think to unsubscribe feeds.  Periodically we'll flirt more with the aggregator adding feeds but we again rarely unsubscribe.
• If a user never clicks on a link from a feed then turn the feed off.  Perhaps ask the user first but turn the feed off.  This would require rewriting links in the aggregator to pass though a logging redirector but that's not hard.  And it could have other substantial benefits for adding future intelligence to the redirector as I wrote here back in April.

Sidebar: Extend this Concept to More of Radio

I can understand Userland's concerns about bandwidth all too well.  I've had machines in hosting centers before and I've paid the piper myself.  It seems to me that a lot of features in Radio communicate regularly with the servers but users generally use only about 20% of the features in a product.  (80% of your users will use only 20% of the features)  So what you want to do is make Radio smarter about keeping track of features used and turn off the features that aren't being used that contact the servers. 

Example: Pointers to 279 changed sites received shows up in my Radio Event Log every hour on the hour.  This is apparently for the internal server version of Weblogs.com.  You know something?  I don't think I've used this feature in Radio more than 5 or 6 times.  And I'm the author of a book on Radio for heaven's sake.  Again the 80/20 rule. 

We don't use most features in a product and often not the features the authors of the product focus on.  One of the huge issues that Dave had when I wrote the chapters in the O'Reilly Essential Blogging book was that I didn't focus on the aggregator in Radio.  I looked at Radio as a writing tool and that's how I focused the chapters.  Heck the company's motto is:

We're turning the Web into a fantastic writing environment.

So there I was, an advanced user, writing a book on the product and not using a key feature.  But I'll definitely acknowledge that Dave was right and the aggregator was / is a key feature and should have been covered. (I was also told by O'Reilly that aggregators were being covered in Chapter 1 and I should leave it out but that's another story).

Ok this turned out kind of random -- Bandwidth ==> 80 / 20 ==> Essential Blogging.  Sorry about that.

 

 

8:01:05 AM      Google It!   comment []    IM Me About This