One of the features we’d planned (and built) for FeedLounge was the ability to save feed items from feeds you are subscribed to. We thought it would be a pretty cool feature, and one that Scott was particularly excited about.
However, as we talked to more and more people about features they wanted in a feed reader and how they use their current feed readers, this feature was rarely one that got people excited. Smart people like Steve actually considered it an anti-feature because of the way they use a feed reader.
The vast majority of people I’ve spoken to view their feed data as transient web information. If they want to store it, they’ll bookmark it via del.icio.us or some other system. If they want to find it again, they use a normal search engine. There were even people I spoke to that thought that no stored data at all would be just fine with them – once it’s out of the feed, it’s no longer relevant.
We’re certainly not going to go to that extreme, but when we get overwhelming feedback in one direction like this it doesn’t make sense to ignore it either1. In alpha 6, we removed this feature from FeedLounge2.
As we work towards our beta release, we’re going to be setting up scripts to remove item data older than 60 days from the production item stores as well (to help with performance and scalability). Once an item is removed from the production store, some combination of an excerpt and URL will still be available… we still haven’t worked out the details completely.
We may look at adding the “save” feature back in at some point, but it is out for beta. In the meantime, if you want to save individual items, you can flag them or tag them.
- Especially when removing the feature will help with initial scalability issues. [back]
- We had announced it would be removed a few months back, to very little response. [back]
This post is part of the project: FeedLounge. View the project timeline for more context on this post.
I vote for adding it back in when you get a chance and can make it scale nicely. This is a great feature if you ask me. Sad it’s going, but I can understand.
This is something I thought I’d use – but I really haven’t. I’ve pretty much been convinced this is a “nice to have” for some minority of users and a “must have” for only a handful.
Yeah, I use it a lot actually, but from what I’ve heard so far, about 2 people have mentioned it as being “Cool to have”. I only have 35 saved articles in my database out of a couple hundred users. Probably … half of those saved articles are mine, heh, so obviously it’s not a majorly used feature for most users.
I vote for adding it back in when you get a chance and can make it scale nicely. This is a great feature if you ask me. Sad itâ€™s going, but I can understand.
I think Steve might be right about it beening a mis-feature. I certainly don’t find that feature useful in my aggregator.
I think it is the wrong way around for me. I almost never think I want to remember something when I read it the first time. It is usually a couple of days later when I am blogging I think, “oh, I read something that is related to this” and I wish I had bookmarked/clipped it. Something that has been missing in every aggregrator I have tried (I have not tried FeedLounge so I do not know if it supports this) is a good search of all the articles I have ever read.
Peter, I think your “search” request pre-supposes a “saving items” feature. One cool feature of Feedster is the ability to upload your OPML and search only within those sources.
So, you’ll have no archives of feeds? I thought you were saying that you wouldn’t have FeedDemon-style NewsBins (where you can keep favorite posts in one area). If you’ll really delete older items, it sounds more like a rationalization of what you’ve needed to do to scale this application rather than a response to user needs. I can’t imagine it being a very popular move.
But hey, I also didn’t build such an awesome RSS reader. You’ve obviously made a lot of good choices already.
The scalability benefits were certainly part of the decision, as noted above. However, much of this feedback was received early on – before we realized the scope of the scalability issues or were looking for areas to reduce data size. Also, the number of items stored is not one of the primary scalability bottlenecks – surprisingly enough.
One more note: I didn’t say we wouldn’t have archives, I said they would be removed from the production data store. We haven’t made any decisions on specifics of archived storage yet – just that 60 days will be kept in the the “production” store.
Alex, my search proposal pre-supposes a â€œsaving items” from your perspective, not mine. I do not want to flag something to be saved. Rather, I want my aggregator to remember everything I have ever read. From the aggregators prespective both are “saving items” but from the users perspective they are completely different.
Peter … whether you meant to or not, your request would entail a save feature. You’re just saying it should be transparent to the user (from what I can tell). And honestly, saving every article you’ve ever read … well, that seems quite wasteful in my opinion. He might as well just never delete an article from the database if that’s how it would be implemented.
The method Alex is suggesting for saving articles doesn’t seem as intuitive to me as hitting a “Save Article” button would be, but I think with minimal retraining of my brain I could get used to it.
Matt, I would now like to disagree with my self. 🙂 A search does not pre-suppose article saving. Saving articles, or not, is an implementation detail that is of not material importance to the search feature. For example, you could off-load the search to some other search, such as feedster, by specifing the OPML of the feeds to which search. Or just save the url and word indexes. Or any number of other possible implementations.
So anyway, you might say that is it a bad idea or that it would be too hard to implement well, but I do not think you can say that it requires article saving.
Relying on an external service to do the search would in general be considered … unreliable and poor taste if you ask me, HOWEVER, your point is made, given the options you gave, I could see how it’s conceivable. Horrible implementation if you ask me, but, possible I suppose.
Peter: as I explained, Feedster already offers that feature.
Alex, thanks for pointing that out. I had not noticed that feedster could do that before you mentioned it.