Comments on: FeedLounge follow-up http://jacksonfox.org/wordpress/weblog/2006/01/feedlounge-follow-up Design, technology and community Sun, 28 Oct 2007 06:24:31 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: Scott Sanders http://jacksonfox.org/wordpress/weblog/2006/01/feedlounge-follow-up/comment-page-1#comment-8 Scott Sanders Sun, 29 Jan 2006 18:41:56 +0000 http://jacksonfox.org/weblog/2006/01/feedlounge-follow-up#comment-8 Perhaps there is a divide between the FeedLounge philosophy and the Bloglines philosophy. The major difference seems to be that if Bloglines showed you a piece of content, it is assumed that you read that piece of content. In FeedLounge, you can load up the river of news, get distracted by the first article, not come back to FeedLounge, go home, and you still have the rest of the articles to read. Is the difference here because you have used Bloglines a lot, and believe that is the way to go, or because I think you shouldn't mark an article read until you actually read it? Or a bit of both? On the pagination, it seems that the browsers (all of them) are just too slow in inserting content into an existing page. We had started with no pagination, but views longer than 100 items seemed to take too long to load, even if the backend could serve the content instantly, thus the pagination. We have tried to make pagination as painless as possible (space bar will take you to the next page if there is an unread item, for example), but perhaps the 2 usage styles are just too different? Perhaps there needs to be a 2 frame 'bloglines view' that solves this problem? We are considering marking all as read as soon as you load the view (a user preference, of course), and in the future we will attempt to aggressively cache the next 'view' client side, to help streamline the experience. From a history perspective, I had even prototyped a view where you got 20 items to start, and then they just kept loading 20 at a time on the end. It seemed too confusing to users who would watch the scroll bar continue to change size, and wait for it to 'finish'. Perhaps there is a divide between the FeedLounge philosophy and the Bloglines philosophy. The major difference seems to be that if Bloglines showed you a piece of content, it is assumed that you read that piece of content. In FeedLounge, you can load up the river of news, get distracted by the first article, not come back to FeedLounge, go home, and you still have the rest of the articles to read. Is the difference here because you have used Bloglines a lot, and believe that is the way to go, or because I think you shouldn’t mark an article read until you actually read it? Or a bit of both?

On the pagination, it seems that the browsers (all of them) are just too slow in inserting content into an existing page. We had started with no pagination, but views longer than 100 items seemed to take too long to load, even if the backend could serve the content instantly, thus the pagination. We have tried to make pagination as painless as possible (space bar will take you to the next page if there is an unread item, for example), but perhaps the 2 usage styles are just too different? Perhaps there needs to be a 2 frame ‘bloglines view’ that solves this problem?

We are considering marking all as read as soon as you load the view (a user preference, of course), and in the future we will attempt to aggressively cache the next ‘view’ client side, to help streamline the experience.

From a history perspective, I had even prototyped a view where you got 20 items to start, and then they just kept loading 20 at a time on the end. It seemed too confusing to users who would watch the scroll bar continue to change size, and wait for it to ‘finish’.

]]>