Greg Smith, the developer of FeederReader, offers some tips for feed publishers to optimize their RSS feeds for best performance in offline aggregators like his software.
pubDate will tell the aggregator exactly when the item was published. Otherwise, the only hint the aggregator has is the time the feed was updated. In many cases, the user can look at the download time and get a general clue about when the item was published because the user is updating anywhere from hourly to weekly. But when the user first pulls down your feed and you don't have a pubDate, all items will be marked as published at the download time. If you have any items that were published five weeks ago, for instance, then the user has to mentally sift through items to determine when they might have been published (or be left to wonder).
Additionally, the user can list items from multiple feeds in chronological order. If you have individual pubDate elements, then your items will be listed correctly among other feeds instead of lumped into groups of items downloaded at the same time. Be careful to use the correct format of the pubDate element and the correct time/time zone relative to Daylight Savings Time (aka "summer time"). It is probably safer to automatically generate UTC times rather than using "PST" or "PDT" (which
you would likely have to change back or forth every six months).
It is important that the title of the RSS channel be relatively short and displayable (no markup) and yet specific enough to differentiate from any other of your feeds. For instance, if you have multiple video feeds with different enclosure types, then the titles of your RSS channels should indicate "Cool Videos WMV" or "Cool Videos MOV". Or if you have a text-only feed, an audio-only feed, and a mixed feed "Great Greg Info - text only", "Greg Greg Info - audio only" and "Great Greg Info - text and audio".
The image of the RSS channel is optionally displayed at the top of every message. It is scaled to be displayed at a maximum of 30 pixels high and the width of the device (generally around 230 pixels). It is best that your image be horizontally oriented, possibly with your logo and the name of your feed or organization within the image.
dc:creator is the name of the person or group that created the item. This should be just a simple "First Last" name or a relatively short group name. The dc:creator (for display purposes) is useful even when you have an author element because the author element is specified to be the email address of the author, while dc:creator is simple display text.
The pubDate, dc:creator, title and image elements all work together to present a useful item display to the user. The display consists of the image on top, followed by the title (as a link using the link element), followed by a byline that reads " - 1 hr ago by Greg Smith from Cool Videos").
This "Global Unique Identifier" allows you to republish or update specific items without duplicating these items in an aggregator. If you change an item without using the guid element, then the aggregator has no way of determining that the new item is replacing an old item. In that case, the aggregator will retain the old item and the new item, forcing the user to read it twice. If the guid element exists (and is the same as a previous item's guid) then the aggregator can (at the user's option) replace the old item with the new one. If the user has not read the item yet, then all they will see is the updated item. If they have read the old item already, then they can optionally read the update or ignore it.
This is the URI of the RSS feed from which you got a particular item. When the source element exists in an item, the user is presented with an easy way to subscribe to this link. This would also be an alternative way (to OPML) to present a list of feeds that a user can optionally subscribe to. If you have a list of 5-30 feeds that you want to recommend to a user, you could create an RSS feed that contains those feeds including a title, description, and source elements. The user could then scan the list of titles to see which might be interesting, and subscribe easily to each one that is interesting.
comments is specified to be the URL of the web page that contains comments and an HTML form that allows comments to be posted. For offline aggregators (users reading your RSS feed while disconnected from the web), this is a big problem. If a user is not connected to the web, they cannot comment on any items in your feed. If they wanted to (and remembered to), they could wait until they got an Internet connection, then go back to your item and select the comments page to view and post. How likely is that? A much better way to support comments is to implement the CommentAPI.
If your server supports the CommentAPI, you can publish the wfw:comment element with your item. This allows offline aggregators to present a standard form, collect the user’s comment, and save the comment until the next time the user connects to the internet.
This contains the URI of the RSS feed that contains the comments for this item. This URI can be presented to the user while reading the item and if interested, the user can subscribe to the comments in this feed to be notified of and be able to read (offline, if desired) any comments on this item. Unfortunately, the link within the Well-Formed Web page lists this element as "wfw:commentRSS" and the Chris Sells Specification lists this element as "wfw:commentRss".
