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.
Sam Ruby: There are at least two types of aggregators out there: most fall into essentially two camps: "single page",......
[more]
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.
Something Sam Ruby wrote today gives me an opportunity to attempt a related point I've been meaning to make. Sam wrote:If you are an online user of a single page aggregator, then what generally best suits you is a a......
[more]
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. ... [Sam Ruby]...
[more]
Sam Ruby: "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...
Rahul Dave, not only do I agree with you, but I personally believe it is time for the whole process to get smarter. It seems to me that the reason there is so much dialogue over the follow-up to 2.0 is that we are reaching an important threshold in the way people and machines communicate. An improved reader interface would couple well with a semantically intelligent aggregator. I think the cursed things should be able to figure context out for themselves, and I think it's possible.
Ziv wrote about types of weblogs, and Sam followed up about two types of aggregators. Andrew Grumet weighed in on aggregators that scale. I'm interested in timeboxing my RSS reading. The more items I can read per unit time, the better. Having to...
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.
Sam Ruby: Two types of aggregators (via Haiko) 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...