Designing RSS Feeds for Information-Heavy Organizations: Non-Web Distribution of Your Content

Does your organization have a lot of information to share with your users/customers/members?  

If so, you probably want to distribute your content via RSS.  Not only can individuals subscribe to your feeds using Google Reader, NetNewsWire, Netvibes, or whatever, but your content can then be re-used on other sites.  

When asked about providing RSS, the technical team may be tempted to say "Of course, our platform can generate RSS" and provide whatever is possible out-of-the-box.  The marketing or other team may not know enough to ask for more.  This quick blog post attempts to at least list some questions to make sure you address when designing (or re-designing) your RSS feeds.  Note that many of these questions are appropriate just for large organizations with a lot of information to provide, but all organizations may get a better understanding of providing RSS by reviewing these questions.

Questions to ask yourself when designing RSS Feeds for Information-Heavy Organizations:

•  When a site visitor signs up for a feed, what will they see (raw XML?  a nicer view)?  Will you have an HTML page listing all of your RSS feeds?  For each page, what will the auto-discover RSS feed be (and will it change on different sections of your site)?
•  Will you provide RSS and Atom?  If both, how will the user select which?
• If you have a lot of information, then people will want to slice and dice that information (for instance, by country).  Do you have solid and consistent metadata, across all your systems?
• What systems do you want to pull from?  A CMS is obvious, but what about document repositories or other systems (and will it be clear to the user what content will be in the feed and what won't)?  If your organization is federated, will you be able to pull content across the organization?
• How will you collect stats on your feeds?  For instance, will you know how many people subscribe to your feed (they may be reading your blog but very rarely/never coming to your site)?  How will your feed stats integrate with your normal Web stats?
•  Will you provide the complete content in your RSS or just some intro text?  What does "complete" mean (if your site aggregates many pieces of content onto one page for example)?
• What will the url structure be for your feeds?  Will users be able to see the pattern in your url feeds, and do their own queries (for example, if it's feed.company.com/countries/td for a feed of Chad content, then can the user put in feed.company.com/countries/us for a feed of US content)?  How will this url structure relate to other syndication (for example APIs) you may be doing?  Can you guarantee that the urls will be permanent?
• Will your feeds be cached or generated dynamically?
• Can you use the same mechanism for determining if content shows on your site and when it should be in the feed?  In general, what will be the trigger for including content in a feed (a change in content, only a significant change, or perhaps just the fact that a state change occurs)? 
• How will you handle multiple languages?
• How will you test and monitor your feeds to ensure they are up and have the correct information?
• Will you allow your internal users to create (and publish) custom feeds (perhaps with some sort of wizard for querying the system(s) and then providing a feed url based on that query)?

I would be interested in your comments, which you can provide below (and also please let us know if you would be interested in a fuller article on this).