Taking a look at FeedLounge - part three

I've been auditioning online RSS readers as potential replacements for Bloglines. In part one of my look at FeedLounge I examined the default data views, and also came across a couple of bugs. In part two I looked at the tagging features of FeedLounge, and some of the different ways of manipulating individual entry items. In this final part I want to look at the way the service handles Flickr photostreams, how the associated bookmarklets work, and give my conclusions about the service.

The first of these, viewing Flickr photostreams, was a very positive experience. Apart from the slightly odd display that the item was authored by nobody@flickr.com (which is down to the way Flickr supplies the RSS data rather than any interpretation on FeedLounge's part) the photos were displayed well within the understandable space confines of the FeedLounge interface.

Using the bookmarklet was more frustrating. It was easy to add to my browser from FeedLounge's support pages. However the bookmarklet doesn't support the demo.feedlounge.com infrastructure. Attempting to subscribe to a blog takes the user to the login interface for the production environment of FeedLounge, where the demo login details are not valid. I'm sure it would only be a minor re-write to get a version of the bookmarklet that pointed at demo.feedlounge.com instead.

One thing I really liked about FeedLounge as an overall proposition was their blog. When selling a product having a pseudo-blog that is full of stilted sales or corporate talk can be a real turn-off, but I found that feedlounge.com/blog had a really authentic feel.

I particularly loved the let's-do-the-show-right-here narrative of getting a new trial Sun server up and running, and empathise with plugging it in before reading the manual, which then turns out to say don't plug the machine in until you have done 'x'

Another handy thing is that at the end of your demo you are emailed with an exported copy of the OPML file you have generated whilst using the system. That means you can immediately subscribe to the full version and synch it with where you left off on the demo, or you can take those feeds and add them into your regular reader if you've decided not to go down the FeedLounge route.

I completely understand the reasons for seperating the production architecture from the demo architecture in order not to compromise the experience of FeedLounge's paying customers. However, I must question the value of offering a demo service that doesn't quite have the full working functionality. After my trial run of the service I wasn't able to judge whether any of the glitches were due to the demo environment itself, the demo environment simply having a 'bad hair day', or whether they would also be bugs in the paid-for versions. As the principle marketing tool of the service the demo is not, in my opinion, currently doing the job properly.

I also think there are two things that would very quickly improve the user experience of the FeedLounge demo. One would be accepting logins from the feedlounge.com homepage (i.e. if a login attempted failed on the production environment, handing the details on to demo.feedlounge.com before completely failing it). The second would be the fairly trivial task of converting the bookmarklets to work with the demo.feedlounge.com domain, and then linking to them prominently from within the demo interface in order to give the 24 hour trial user the closest possible experience to the paid-for-product.

I very much wanted to like FeedLounge, as I like the interface, and think that both tagging and the history view would be very powerful additions to the tools I currently have available to aggregate RSS feeds. However, because of a few glitches with the demo, I did't feel I was given the confidence to migrate from the free version of Bloglines which works just fine, to the paid for version of FeedLounge. Not yet, anyway.