Favicon Hell: Small Feature, Big Code

A couple years ago, FeedDemon started displaying favicons – you know, those little 16x16 icons that web sites use to brand themselves.  It was a popular addition, because it’s much easier to tell your feeds apart when they don’t all use the same generic feed icon.

It seemed like such a simple feature at the time.  Just check the root folder of the feed’s homepage for the favicon, download it if it exists, then display it in FeedDemon.  No big deal, right?

Bah.

The first problem was web sites that lied when I requested the favicon.  They’d use the wrong MIME type, so I couldn’t rely on that to determine if I was actually getting an image.  And all too often they’d indicate that the favicon existed by responding with an HTTP 200, but instead of returning a favicon they’d give me an HTML document that contained a 404 error message.  So that meant writing code to handle that situation.

The next problem was the sheer number of favicons that used the ICO file extension but turned out to be bitmaps.  Or GIFs.  Or PNGs.  Or JPEGs.  Or some undiscoverable format.  Which meant writing code to detect the true image format, and more code to convert them to Windows icons (something I didn’t get right until last week’s FeedDemon 2.8 Beta 3).

Then came the fact that not all versions of the Windows API play nice with truecolor icons, and the version of the development tool I’m using doesn’t handle them well, either.  More code to handle that situation and fail gracefully. 

And, of course, I had to reflect changes to a site’s favicon, as well as detect when a site that didn’t previously have a favicon suddenly got one.  And this had to be done in a way that was bandwidth-friendly, both to the client and the server (not as simple as it sounds given that many sites don’t correctly return an HTTP 304 when a file hasn’t been modified).

Oh, and I also had to scale the 48x48 and 64x64 favicons that some web sites inexplicably use.  Not to mention the fact that ill-mannered anti-virus software would sometimes lock the downloaded favicon file right after I created it, resulting in a “file in use” error which I had to capture and work around.

Etcetera, etcetera, etcetera.

The end result is that it took thousands of lines of code just to display favicons.  And that’s often the case with features that seem simple at first glance.  It’s not until you dive into the code and find all the weird problems and bugs that you realize your little feature is actually a big PITA.

So what’s the point of this seemingly pointless blog post?  Really, it’s just to explain my response to customers who ask when I’ll be adding a specific feature:

“I’m planning to add that to the next version, but I can’t promise anything until I’ve actually started coding it.”

I know that response sounds glib to those who hear it, but it’s really me being honest.  If I haven’t tackled a feature in code yet, then there’s no way I can reliably estimate how long it will take to complete it.

Related post: Start Coding Like a Cowboy

Comments

[FDFan]

Please add a feature to turn off favicons.
I hate them. Its makes the subscription list look messy. Many of the feeds that i have subscribed to dont have favicons.

[FDFan]

This is what i did to turn it off.
In the Favicons directory, I replaced each favicon with a simple rss icon. Then I made all the favicons read only so that feed demon doesnt replace them when the feed are updated.

Its the only thing about feed demon that i strongly dislike.

[MenoRikey]

That is the hardest thing about software development, estimating time. Its almost impossible to do. Features you think are easy, take forever and features that you think are hard, you finish quick.

[Niall Kennedy]

Are icons explicitly specified in Atom any better or more reliable?

[Nick Bradbury]

@Niall: yes, although it's a real pain having to correctly display the xml:lang of a favicon :)

[Chris]

Wouldn't it be far better to not display a broken or wrongly made favicon? It's not like it would be a hardship for the sites owner to fix it themselves, and really, they're relying on the time and efforts of other people such as yourself to work around bad design.

Uphold the standards?

[Nick Bradbury]

@Chris: That was my approach when I first started FeedDemon, but I changed over to "the dark side" after seeing how much non-standard stuff exists on the web (see http://nick.typepad.com/blog/2006/11/web_30_does_not.html ). These days I figure part of my job is making sure my customers can get the information they want regardless of whether it's perfectly valid.

[!&#]

Thre are no favicon standards. The W3C has a document that is still a draft, and the favicon began as an IE feature that was already in violation of fundamental web standards.

[Chuck Brooks]

Thanks for the warning! We were toying with this for an extractor product we're using internally and getting ready for public release, but not any more.

[Nick Bradbury]

@Chuck: depending on your product, the fact that this feature is such a PITA may actually be a selling point/differentiator for you.

[Tgt]

This sounds related to Joel Spolskys talk about in "Where There's Muck There's Bras"

[Nick Bradbury]

@Tgt: I'm guessing you meant to say, "Where There's Muck There's BRASS" :)