We need better favicons to drive the open web forward. A way to manage dynamic icon assets by code, through collaboration and cloud storage. Iconbin is an attempt to achieve this.

Icons by API

3 min. read
  • UX

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.


Favicons are degraded to the sidebar, while the stream of items can only by scanned textually. Shown here is the popular newsreader Feedly.

Brand recognition

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.


Google News. While not totally practical, this unsolicited redesign by George Kvasnikov is peppered with large brand assets to great effect.

Teamwork

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.

An icon served through iconbin.

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.


Metalayers

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!


Share