Posts in: June, 2005

In FeedLounge, there is a link titled ‘My Account’ which pops up a window that shows your account details and preferences (currently only one, but more are being added).

From the feedback received in the forums so far, I think people are not thinking to look in ‘My Account’ for options or preference settings. Would titling this link ‘Preferences’ or ‘Options’ would make you more likely to click on it when looking for various options? Perhaps another term?

The comments are open…

It looks like we got FeedLounge working in Safari again (it worked for a while, then broke for a while) - at least Safari 2.0 seems to work.

If you’re alpha testing and want to try FeedLounge in Safari, please give it a whirl and let us know how you fare.

I posted a couple of Greasemonkey scripts (and bookmarklet equivilents) for FeedLounge on my blog today. Here at FeedLounge we have the following attitude about user scripts:

1. They’re awesome
2. They’re awesome

It’s a high compliment when someone loves a tool enough to take the time to write a customization for it. Of course, if there any scripts that cause performance issues, etc. for the service we’ll try to address them on a case by case basis.

Stephen O’Grady wrote recent blog entries about Gmail and Greasemonkey. Some of the basic points that resonated with me as a service provider were that these scripts are really useful for power users and that, if possible, service providers should do their best to work nicely with the script developers whenever possible. Makes sense to me. As previously mentioned, I’d love to see an outside developer create a notifier app before we get around to it - it’s a win-win situation. Users get the notifier app faster and we can continue working on core features.

Because I think that FeedLounge is the kind of app that people will write scripts for, we’re working hard to try to get naming and other details set before we get into our beta release. Building on top of an application that is still in rather rapid development is a receipe for frustration - both for developers and for users.

I look forward to seeing what kinds of scripts and add-ons people create for FeedLounge.

Here is a new bookmarklet that gives you the option to add tags to the new feed you are subscribing to. Enter the tags like normal (as many as you like, separated by spaces) and they will be applied to the new subscription.

Add to My FeedLounge

To use the bookmarklet:

1. Drag the link above to your bookmarks bar.
2. When you come across a feed you want to subscribe to, click on the link to the feed (this should load the feed in your browser).
3. Click the ‘Add to My FeedLounge’ bookmark.

Yes, auto-discovery of feeds is on the list - however it isn’t in the current alphas so you do need to load the feed in your browser before clicking on the bookmarklet.

Welcome to the second of a series of posts on the development. If you missed the first one, check it out here: FeedLounge development: the parser.

The feed validator

We have feeds being parsed, but we also wanted to help make the world a better place by allowing the end user to know whether or not the feed is valid. As Geof rightly points out, we MUST follow Postel’s Law when parsing feeds (”be conservative in what you do, be liberal in what you accept from others”). Why not give a quick heads-up to someone that might be able to help fix the problem?
So, in FeedLounge, there is a banner near the item content that tells the user the feed is invalid. The user is given a link to click on to see for themselves what is wrong with the feed, using the service from feedvalidator.org.

Hopefully someone will come along that knows the person publishing the feed, and helps nudge them to fix the problem, to make the world a better place for all feed reading entities. If this banner gets too annoying, it can be hidden down to a small icon, and the user can go on with her feed reading. And of course this setting is persistent, so the user does not continue to be annoyed.

Quick Note to Sam and Mark: First, thank you from the entire FeedLounge team for the excellent code that is feedvalidator. Second, I hope you will yell at us if we are not using feedvalidator.org according to your Terms of Service, we believe that we are, as it takes the end user clicking on the link to activate feedvalidator.org, all of our backend validation is done on our own server.

Interesting stats around validation

Of all the feeds that FeedLounge is currently parsing, validating, and tracking, 34.5% have some issue, 22.5% are NOT valid, and 17.8% are completly broken (404, 304, no response at all, etc). That’s 1/5 to 1/3 of all feeds that FeedLounge might not allow the users to read if we were using a strict feed parser!

As a side note, a large portion of the invalid feeds so far are from some version of WordPress. There are a lot of users out there that haven’t felt that upgrading is important. Please upgrade!!! The security fixes alone are worth it. I hope in a future release that the WordPress team might use one common codebase for feed creation, rather than separate code for each feed format. Disclaimer: dotnot.org uses WordPress 1.5.1.2, and will not change to something else anytime soon. I like WordPress, just offering constructive criticism, and I just want to give the WP team a friendly nudge from time to time

The code is looking a lot better now, and we would like to add another wave of users to test the load of the system. If you are a daily reader of feeds, and are willing to switch completely to FeedLounge (with the caveat that it is alpha software), and are willing to post a lot of feedback in the forums, come on in. Since you are reading this on Sunday, you probably are a heavy reader.
Post in the comments before comments are turned off, and you’re in. Couldn’t be easier. And yes, I do need a valid email address to send the invite information to.

Update: Wow, that was fast, I step away for 2 seconds and everyone is all over it Expect your invites soon.

We have noted in our alpha invitations that we intend for FeedLounge (company, people and application) to be as open as we can possibly be. So along those lines, I will be posting here and on the FeedLounge Blog about architecture, features and development of FeedLounge, so that everyone can see inside the beast, so to speak.

Which feed parser should we use?

When are you building a web based feed reader like FeedLounge, having data to read is step one. Luckily, there are many feed parsers already out there, so the “build vs. buy” decision was fairly easy. Focusing on the development of the user experience of the feed reader, the feed parser part of the application is only a ‘necessary evil’ in the scheme of things. After checking out several possiblities, including using my own Java/SAX framework, we decided on feedparser, the canonical namesake of the feed parsing world. Built by Mark Pilgrim, and currently at version 3.3, this is probably the most forgiving feed parser on the planet. Had I gone with my own solution, I would have spent months and months creating something as good. And with a liberal open source license, I am allowed to use it in a commercial project like this.

feedparser features

• feed format support - v3.3 has impress support of 4 feed formats and 15 different versions of those formats. This probably would have taken a good chunk of time to come up with support for.
• encoding detection - Anyone who has done this understands the difficulty without any explanation.
• tidy support - Want clean HTML content as output? No problem, it’s in there
• translated access between specific terms - If you know channel instead of feed, these are the same thing in feedparser. Use the terms that you are comfortable with.
• relative url support - Useful to us since we are ripping the feed apart to store it. Having no relative URLs is a great relief.
• great documentation - Mark produces some of the best, most-useful documentation in the open source world. feedparser is no exception here. Terse, but covering what you need to know. Need to do 401 auth? Here. Wondering about E-Tag support? There.
• over 2000 unit tests - I may run into some arcane case not covered here, but the likelihood is not very high.
• HTML sanitizing - Extremely useful for a feed reader, to prevent bad things. You don’t want to let someone else’s JavaScript run inside your app. Debugging that would be a nightmare, and maliciousness is also a concern.
• date parsing - Support for every date format they came across. You get a simple date format, consistent from feed to feed.
• It just works!- The best is saved for last, as this point cannot be made often enough. In the months of development so far, feedparser has never been the spotlight of a single problem. The closest we have come to some kind of problem is not checking for the existence of some item before accessing it. feedparser has been a huge net positive on development, with an almost nil overhead. To have alpha testers say that some of the feeds that don’t open in nearly anthing else show up in FeedLounge, that wasn’t us, it was feedparser and its magic voodoo.

Mark, thanks a million. I know you have ‘gone dark’ in the blogging world, but you are still rocking mine.

I have decided to move the FeedLounge devlopment series from my blog to the FeedLounge blog, since I had published 2 already, they seemed to fit here better. I will keep the already published articles on dotnot as well. Happy reading!

It’s important to us that the initial FeedLounge user experience rocks right from the start when the FeedLounge beta is released. To that end, we’re asking you to send us your OPML file (an XML file with your feed subscriptions, most applications have an export capability) so we can test it within FeedLounge.

This will allow us to:

1. test our OPML import capabilities with the OPML output from a variety of feed readers, which is very important for anyone transitioning from an existing reader
2. look for additional “broken” feeds and see if we can work around them
3. begin gathering content from these sources
4. continue to load test various parts of the system, and we prefer real data to fake test data

Send your OPML files to opml at feedlounge.com, and let us know what application generated the OPML (NNW, Bloglines, custom code, etc). We will load them up and use that as a test to make sure there are as few problems as possible.

Just for clarification (we’ve received a number of e-mails asking), we will absolutely be supporting browsers other than Firefox (and Mozilla and Camino) as we get closer to the beta release.

Early Browser Stats

If anyone is curious about the browsers being used to visit the FeedLounge web site, here is the current breakdown:

Mozilla/Firefox/Camino - 57.16%
IE - 11.72%
Safari - 8.39%
Opera - 0.28%
NetNewsWire 2.0 - 0.27%

The rest of the numbers are various other UAs and search bots, etc.