Here’s the situation: As specifications and virtual DOMs move ever so quickly, keeping ones chops sharp is paramount. Yet another hot new frontend thingie needs to be test-driven around content. What better suited to the task than your basic news aggregator? While ingesting textual content through an ever growing number of channels, the problem of managing image assets remains the same. Especially if you need dynamic images based on content. It's time we get better favicons to drive the open web forward.
News items need the brand identities of their respective content providers to shine. Brands should jump users faces with flying colors and instantly recognizable icons. Especially in the buzzing environment of a news feed, where text is reduced to a headline, icons are anchors for the saccading eye to scan effectively. While I keep a good amount of local icon data around, oftentimes a new medium appears and messes up my neatly arranged feed. This closed amount of icons, prone to failure, could be maintained within each app, but I find that to be very unwieldy. Favicons are small and unbecoming. Also, providing meta tags is totally up to the domain owner and requires additional full page requests for every icon. And you can’t rely on app icons either.
To solve this problem, I made a thing called iconbin. Basically a small API done over the course of a weekend, iconbin maps domain names to large icons directly through
manipulation of a URL endpoint. The New York Times icon shown here is served via iconbin, the path is simply
/api/nyt.com/src. Leave out the
/src and you get a JSON object.
Every domain has its icon. If not, there’s a fallback. And users can fill in the blanks through a collaborative code repository on Github. Once added by the user, icons will be distributed to the cloud. And it doesn’t have to end there – with infinite virtual subdomains available, every type of icon could have its own unique address in the domain namespace.
Iconbin is technically trivial. Borrowing from a common UNIX concept, it should „do one thing and do it well“. Still, while its use case may be somewhat limited, iconbin follows a few important principles. Firstly, it is capable of scaling with use. Secondly, it acts as a third party making claims about disparate unique resources. This is crucial. While metadata tied to domain names would ideally live in the aforementioned meta tags, those tags see limited use – if not proposed by the major league like Facebooks Open Graph. In my opinion, building open third party layers and logic around URIs makes a lot of sense. I hope you can extract any use from this. Feel free to check if your blog or publication has an icon associated with it at iconbin.com already. If not, please contribute!