Here’s what I think is essential for a corporate RSS reader:
1. It must support individual authentication in order to access secured feeds. Preferably using a digital certificate to identify the user. This rules out all browser-based aggregators
2. Most users will want to get started straight away and will not want to spend a long time managing their list of feeds. We need a way of managing centrally a user’s OPML file and adding a feed for them if they request it.
3. We need the Read/Not Read status of the content to follow the user around, whether he is using his regular desktop machine, working from home on his laptop, or in an internet cafe using a server-based computing environment or a VPN.
4. The consumption of new content needs to be efficient. My aggregator supports Space Bar single-key reading. I just hammer away at the Space Bar until I find a post I’m interested in. This enables me to consume a large number of feeds in a short amount of time. We will be accused of creating an UNproductivity tool unless we can demonstrate this!
These things are pretty important for this technology to get accepted in the corporate environment. For my own benefits I would also like to see a feed aggregator that has the following feature:
5. Feeds are organised by tagging them, not by creating a hierarchical folder structure. Individual posts could also be tagged.
(1) rules out all browser-based aggregators, but (3) appears to rule out all non-browser-based aggregators.
Hello Neil and welcome to the conversation.
You are right that the server component of a browser-based corporate aggregator would be able to store the user’s Read/Not Read status centrally (unless the developer went for a brain-dead cookie-based state machine).
I don’t believe browser-based apps have a monopoly on central storage for state, though. I’m talking about a corporate environment where a user’s home drive (for instance) might be expected to be available in all contexts. I guess most aggregators store their state in a file somewhere. Just needs to be somewhere on the corporate network.
Lets face it, we are not going to get the ideal corporate aggregator any time soon. In the mean time lets just go with the flow and support the RSS bandit as the prefered solution for now as it is being used by research.
Any technical people who have other preferences can use what they like (they will anyway) but for us less techy (well less time to play and experiment anyway
) a supported aggregator that we dont need to spend 1/2 a day working out how to install and use will be most useful…
In the context of the organisation that you and I work for, Andy, I quite agree. It would be better to get a sub-optimal aggregator in widespread use than wait for jam tomorrow.
The only proviso would be that we should consider how we would upgrade the aggregator when a better one becomes available. In other words how do we preserve everybody’s feed collection without a lot of manual effort?
The context of my post arose from ongoing discussions with a particular aggregator vendor. Today we are discussing feature sets rather than deployment strategy
I dont know a lot about thes things but RSS Bandit is open source I believe, could we not add functionality to that, in house and avoid getting tied into another potentially expensive external vendor?
This is an awesome idea that I think would work wonders in the enterprise world, especially when you need to spread knowledge and help people understand what RSS is.
Shees I hope someone develops this!