Dean: Like a lot of ideas, HTTPflies appeared almost entirely by accident. I saw a tweet a few months ago, from someone who had seen an obscure HTTP status code. The tweet jokingly said something like, ‘you rarely see this in the wild’. The notion of ‘rare code’ got me thinking.
This got me thinking about the documentation and classification of animals – could we do something fun, along these lines, but for code? So Tom and I started chatting about butterfly collections, and whether we could do something to experiment with generating multiple versions of something, from a few basic graphics.
That last point is interesting. There’s something in that about how “designers” and “coders” work together and how SVG forms an interesting span across that gap. You could create the graphics entirely in code (with combination of squares and circles etc) but I like the fact that an artist can create something in illustrator and that it pops out in a form which is perfect to be coded with. With PSD’s etc you have to translate the pixels into code, but with SVG the graphic is already code. Not that SVG would be good to do web design in, but just it’s an interesting half-way point somehow.
Tom: We reduced the anatomy of a butterfly down to some component parts. Deciding that a single body would suffice and that for each wing-type we’d want at least two layers. As every school-child knows you only need to paint half a butterfly and so it was here with one set of wings being enough to create a full butterfly. Once we had these components in place we could pick out the wings shapes we wanted, duplicate and re-colour the different parts and present as many different butterflies as we needed all with pure code. Using SVG as a repository of reusable elements like this seems like it might have interesting possiblities for the future.
Dean: We wanted the colours to be generated kind of randomly, but it soon became clear that some combinations and types of colours were pretty hideous. We needed some logic to ensure the HTTPflies were all beautiful, and harmonious, while at the same time not too similar to others. Tom was able to omit certain colours and make some rules around how we worked out each HTTPfly’s palette. Also, it was important that after each HTTPfly’s palette was assigned, it would be the same each time (and not randomly created on page refresh).
Tom: As one of the main aims was to create a lot out of very little it was important that the initial download of the site would be as small as possible. Not only that but also it was vital that we made as much of that download as possible.
Now, this would obviously not always for desirable for larger websites (where caching benefits kick in) but for an experiment like this it seemed to fit nicely within the overall idea, to serve the whole thing as one file.
So we hope you like it. It was great fun to make.
We need to give credit to a number of giants on whose shoulders etc etc...
Tom: There was a moment in the middle where I thought I was going to have to serve the whole thing as xHTML. This came from a problem I had with my version of Safari (5 — for some reason) and I found a question on stackoverflow which seemed to point to this as the solution. I did quite a lot of work to make everything xHTML compatible (escaping various characters & using CDATA blocks for JS and CSS) and it was only when I implemented Modernizr at the end to check for compatibitly that I realised that Safari 5 isn't considered a browser that supports inline SVG. So we dropped support for it and went back to serving HTML5 instead. You live and learn.
If you've got any thoughts or suggestions we'd love to hear from you, tweet us @httpflies.