Sometime during the past week, the number of downloads of RSS Bandit from SourceForge crossed 100,000 for the most recent release and 300,000 total downloads since the project moved to SourceForge a year and a half ago. This isn't bad for a project that started of as a code sample in an MSDN article a few years ago.

However even though Torsten and I have been improving the original code for about two years now there is still a bunch of work to do. Some of these areas for improvement were recently pointed out by Jack Vinson in his posts RSSBandit Thoughts and More RSSBandit Experience. Below are his comments and responses from me.

"Next unread item" means the oldest unread item, rather than the youngest.  This seems to run counter to most of the aggregators, which present the newest unread item.  Interestingly, the "newspaper" view shows items in reverse chronological order.

I like to read posts in the order they were written especially when a newer post might be a follow up to an older post [as is the case with the latter post by Jack]. In general, I don't think anyone has really complained about this before.

Space bar goes to "next unread," rather than doing a "scroll" in the current reading pane window when viewing in newspaper mode.  If the reading pane has focus, it will scroll there.  When reading a single post, it does scroll as expected.

The behavior of going to the next unread item on hitting space bar predates the newspaper view. The problem we had when coming up with newspaper views was how to integrate both features in a way that was intuitive. The main issue here being that if the space bar scrolls you through the newspaper and you scroll half way down then click somewhere else, do you expect that half the posts from the newspaper view should be marked as read or stay unread? We didn't have a good idea of what the right choice would be so we punted on the problem by not scrolling in the newspaper view when you hit space but instead keeping the old "Next Unread" behavior.

RSS Bandit is much more sensitive to errors in the feeds - more accurately, it tells me that there are errors in some feeds.  They provide a "feed error" folder that lists problems as they arise.  But I see that the feeds it has trouble with work fine elsewhere.  Not good.

Some of the errors we report really aren't worth showing to end users. Things like HTTP timeouts and the like are really transient issues that are more likely due to the user's network than a problem with the feed. We need to do some filtering of these errors in future releases.

I can't get the full text on excerpt-only feeds.  This is probably the biggest loss of moving from the old reader.

If the feed only has excerpts, how do we get the full text of the entry?

I like the newspaper view, when I select a folder (they call them "categories").  Articles are listed in descending order, but are grouped by feed.  I don't quite understand how the feeds are sorted (it's not by the feed with the most recent article is at the top.)  This is a handy mode for reading unread stuff once or twice a day.

I like this feature as well. In the next version we'll be adding the ability to flag or mark items as read/unread from the newspaper view. The feeds should be sorted by the order the appear in the tree view.

RSS Bandit is a stand-alone application, but it uses the Internet Explorer engine to render HTML and XSLT.  By default, it opens links in tabs within the app.  You can also have it open links in the default browser.  I like the tabs in the application.  Now I need to find out if there are keyboard shortcuts for navigating the tabs.

Tabbed browsing is definitely cool. You can navigate between tabs by pressing the Ctrl+Tab or Shift+Ctrl+Tab keys. It's pretty sweet.

The BlogJet This plug-in works in the reading windows.  But the BlogJet This plug-in for IE does not work in the tabs that open within RSS Bandit

Weird. I'm not sure why this is the case but can look into it.

Email this only emails the URL of the post.  I'd rather it give the entire text (HTML) of the item (along with the URL). 

I've kind of wondered about this myself but since no one has ever really complained I never changed it. Are there other RSS Bandit users out there that would prefer that "Email This" sent the body of the post and not just the URL as it does today?

I'm not quite clear on how the user interface is responding. Sometimes I will select a folder/category that has updated feeds, and I will get a view that lists just the new entries. Other times the newspaper will show both new and old entries. The topic list always shows both the new and old.

For search folders the newspaper view shows all the items in the folder while for regular feeds or folders/categories it shows the unread items.

One can create search folders to display ONLY unread messages, for example.
It seems slow, but this is my complaint with many of these apps. Maybe I just read too many feeds. Marking about 80 unread items read (when in the "unread view") took quite a while. Even 28 unread items took 10-15 seconds to "process." This seems to be a memory issue, because the next time I hit "mark all read" in the same usage session, it is much faster.

I agree that it does seem to take far too long for an operation like "Mark All Read" to be performed in a search folder. I'll work on improving the performance of this for the next version.

There seems to be no easy way to tell the software that I'm offline and to not bother downloading.

Go to the File menu and select "Work Offline". We also detect if you select this option directly from Internet Explorer as well.

When it's checking feeds, it eats a lot of resources. So much so, that I can't even scroll the current window, much less select a new feed to read. (Outlook has been doing the same thing to me lately.)

Downloading feeds is pretty CPU intensive for us. Not because of the actual downloading of the files but because we run the algorithm that infers relationships across different posts so we can show them as threaded conversations. I hacked on this code during the last release but only made it slightly less CPU intensive. I've considered just having an option to turn off this feature for the folks who'd rather have a more responsive UI than the threaded conversation feature.