FeedLounge follow-up
I don’t think the FeedLounge guys ever sleep. Every comment I’ve made about the site (on this site or in the FeedLounge forums) has been answered with amazing speed. Sadly, I think FeedLounge just isn’t for me. It sounds like pagination isn’t going away and that marking all items as read on viewing isn’t coming anytime soon. I never liked mutt or vim, so it might not come as a suprise that I’m not a big fan of keyboard shortcuts. I’ll play around with FeedLounge some more and see if it grows on me, but Bloglines just seems to fit my reading habits better.
Update 2/5/06: My new goal is to use FeedLoung for one week (starting now) in place of Bloglines.
Update 2/24/06: Well, things didn’t work out between FeedLounge and I. It’s nice enough, but it took me a lot longer to wade through my feed items than it normally takes me with Bloglines. I’ll check back in a little while and see how things have shaped up.
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’.