Ziv Caspi: Atom 0.2 is out. Although not an official spec, it looks like it's now solid enough to comment for people who are, shall we say, wiki-shy. So here's mine.
Lots of good feedback here. Ziv talks about two types of weblogs - "take that" and "phone home". I think the distinction is more subtle than that, and deserves further exploration.
But first, I'd like to point out that there are at least two types of aggregators out there: most fall into essentially two camps: "single page", and "three pane". This difference will be explored in a bit.
Back to the "two types of weblogs", let me explore this by looking at two specific blog tools, namely, Radio UserLand and Movable Type. Radio UserLand was my first blog tool. While you can do many things with it, let me focus on two: posting to your weblog, and creating a story. Posts tend to be short. Stories tend to be longer. Posts are included in your RSS feed. Stories are not. To get a story to appear in your RSS feed, you merely link to it in a Post.
Movable Type is different. Not necessarily better or worse, merely different. There is one type of entry. It can be any length. Once completed, it the results can be made to show up in three places: your front page, a page dedicated to this entry, and one or more feeds. By default, all three show the exact same thing. This may be suboptimal for essay length content, so this can easily be overridden. In fact, one can separately control the content that shows up in each of the three places. What this means is that you can create a story with a separate lead in blog entry entry. You just do it using a different series of steps than you do with Radio UserLand.
Now lets look at this from a user of an aggregator perspective. If you are an online user of a single page aggregator, then what generally best suits you is a a short lead in with a link to the rest of the story should you be intrigued enough to follow it. If you are an offline user of a three paned aggregator, seeing only the short lead in is - to put it quite bluntly - a tantalizing and quite frustrating tease.
If you are a content producer (i.e, you have a blog), it is not possible to serve both audiences with a single RSS 0.91 feed. RSS 0.91 had one "slot" for a description. This tended to favor the online users of single page aggregators. With RSS 1.0 and 2.0, it became possible to address this need via namespaces. In fact, the most popular module that is used in both versions to address this need is mod_content. The conventional usage pattern is to put the summary in the description and the full story in the content:encoded element.
This allows a single feed to address both audiences.
The Atom 0.2 Snapshot provides both a summary and a content element in the core.
This weblog post is longer than most of the ones you typically see on my weblog. In my RSS 0.91 feed, you only get the excerpt. In both my RSS 1.0 and RSS 2.0 feeds, you get both the excerpt and full content. On my front page, you will initially see the entire content. Once it moves down the page, it will be replaced by the excerpt. Ultimately, it will drop off the front page completely.
In either case, the link will take you back to the full content on a separate page. Furthermore, what you will find there is often far more valuable than the original post: comments. On my weblog, that's often where the "good stuff" happens.
In some sense, neither user interface is optimal, is it? A single page aggregator allows only snippet styles, while a 3 pane spend precious real estate on channel names, surely something that dosent deserve such precious space. Further it dilutes information density by just having titles in another large part of land. Most people arent going to have the best titles. This is worse in email interfaces and threads as the whole thread has the same god-damn title which fills up 1/3 of the screen.
I think the UI is the place to focus on, not the feed, because any aggregator pught to be able to auto summarize a description by truncating at the nearest sentence bounday or m words greater than a maximun n words. The structure of the feed should depend on bandwidth considerations, not aggregator, as the aggregator should be capable of following up to pull full descriptions from site, or get them from feed itself.
So focussing on UI forn aggregators, why not 2 pane sliding container interfaces? At start the summary-radio like interface could be the left pane, and on choice, the detailed reading could be the right frame. One could even blog items, or create linkfests(ala diveintomark) in this right frame. Or if one prefers, start with channels in left and radio like summaries in right. Find an interesting article from summary, click, summary slides over to left, article shows up in right. Read.
Now, there are to activities one might want to do to individual items. Do something individually to them, like blog them with transclusion, or add them to bookmarks, linkfests, or even a blog without editing. The challenge now is to do this in one pane freeing the other pane to go find other relevant stuff. This transforms the 2 pane into a really useful 3pane compared to todays poor outlook copies...
I saw this method first in Haystack from MIT, under the name UI continuations, where the example is of people being added to a party invitation in the left pane, while the right pane is free to get these people from anywhere, such as web pages, emails, etc. By splitting into panes, and decoupling stages, haystack allows places in the history of the action to be bookmarked and resumed. Thus the name continuations.
My claim is that such UI advances would help in aggregators. The question is which pane to make the primary frame: the content frame, or the container frame (article or summaries).
These are things, IMHO, to think about and play with. Both 1 pane and 3 pane systems are poor, they have poor per-tem usability and poor information density respectively.
Rahul Dave, "I think the UI is the place to focus on, not the feed", thats the point.
There can be two processes for reading posts,
Browse all the posts opening interesting ones in a seperate tab/window, Read all open tabs/window. OR
Browse and read all posts one by one.
The first case likes short posts, the second case likes the whole post in the aggregator.
The solution is to give a single pane and also giving the user the option of changing the display size of each post.
If one of the goals is to encourage the user to visit the site, it can be done by setting the default value of the post's display size to 3-4 lines. If the user wants to read every thing in his aggregator, the comments problem becomes a feed problem. Everyone need to give out the number of comments a post got in the feed (it should be given, because it is displayed on the html page), we can then have a seperate view for that in the aggregator.
But I personally think, the user should be rewarded for visiting the site by displaying the comments on the page only.