Need icons for filetypes? Hotlink from stdicon.com
August 28, 2009
This is about ten days old, but still worth mentioning. I was working on PostBin trying to support file uploads. I realized I really wanted to have icons for the files to help differentiate them from other POST params and make it feel more polished. Of course, this would mean I’d have to find icons for the popular file/mime types … and if I were going to do that, I might as well build a service … but I didn’t want to build a service.
I turned to Twitter. In that past, I’d mentioned wanting something and somebody actually built it (using my tools no less). I figured this was a bit more work than last time, but it couldn’t be that much more. So I gave it a shot and tweeted it. Next thing I know, Paul Tarjan is on it. Some hours later: stdicon.com
I’m credited at the bottom, but really, I just had the idea and came up with the domain. Paul wrote all the code and even collected all the icons (and manually uploaded them to the app). We discussed implementation details over IM, but that was it. Pretty rad!
The idea is that given a file extension (“txt”, “gif”, etc) or a mimetype (“text/plain”, “application/zip”, etc) you can get a resizable icon by putting together a simple URL, like http://www.stdicon.com/mp3?size=16 or from a particular icon set http://www.stdicon.com/neu/html?size=64. Here are some examples from various sets:
Nuvola set:
Apache set:
Crystal set:
And that’s it! Paul wrote a post about it. Somebody requested a simple API for just doing the mimetype to file extension conversion, so Paul added it. Strangely, the same day, MIME API was released. That’s fine. Just means stdicon can focus on icons.
Anyway, I pulled this same stunt just the other day, using Twitter to get more cool infrastructure built, but I’ll have to write about it later.
Subscribe to Blog
December 9, 2009 at 6:20 pm
[...] 9, 2009 In my post about stdicon.com, I hinted at something else I built in collaboration with a few people starting from a Twitter [...]
December 12, 2009 at 9:16 pm
I wouldn’t hotlink the site’s images; that’s wasteful of their CPU and bandwidth, and means your site is full of dead images if stdicon.com is down (temporarily, or some day, permanently).
A better idea might be to write a couple lines of code to download the appropriate icon from stdicon, and once it’s done that once per file type and size combination, cache the image on your own server for future use.
December 12, 2009 at 9:21 pm
It’s a community service, so the whole point is to waste the CPU and bandwidth. It’s running on App Engine.
Think of it like Gravatar. The whole point is to hotlink. Your avatar image there is hotlinked in this way. Caching is fine, perhaps even a Good Idea, but it’s generally more effort than it’s worth.
December 13, 2009 at 12:20 am
FWIW, from a rendering performance perspective, the images should all be combined into a sprite and that single image cached on the server.
December 13, 2009 at 12:41 am
Thanks for the tip! We’re too busy to bother with premature optimization. If the service renders too slow, be sure to bother us!