IR5 Interactive Piece

March 5th, 2013 by Keith Peters

Introduction by Rebecca Allen:

We are creating a new website that will be launching at the end of March. Working on our own site is always an exciting process and one that is challenging as well. Our goal was to do the following with the new site:

1. Make it memorable!
2. Create a unique and fun interactive experience that captures our brand.
3. Display quickly and beautifully no matter what size device.
4. Communicate our mission and what we do clearly.

Today, we are going to give a sneak peak into #2. Keith Peters will walk you through the steps he took to create this interactive experience. Keith, take it from here!


As part of Infrared5’s new web site design, I was asked to create an interactive piece for the main page. The mock ups called for the design that has been our trademark since day one – an abstract space made of random isometric planes and lines. This is the design that is on our letterhead, business cards, and previous versions of our site.
I was given free range to come up with something interactive based on that design. One idea floated was to have the planes connect  with the lines and rotate around in the space. I decided to go with this concept. I realized that the idea was a bit odd once I got down to coding it. I mean, isometry itself is a form of 3D projection, and we also wanted to move the planes around in a 3D space with actual perspective. It could become quite a mess if done wrong. Specifically, in an isometric system the angles do not change and objects do not change size with distance. But I forged ahead anyway to see what could be done that might look decent.
The first thing I did was just get a 3D system of rotating particles. This was something I’d done and written about before, so was relatively straightforward. As you click and drag the mouse vertically the particles rotate around the x-axis, changing their y and z coordinates. When you drag on horizontally they rotate around the y-axis, changing on x and z.

Next step was to change the particles into isometric planes. I started out with true isometric projection, meaning the angles representing each axis are each 120 degrees apart. I soon switched over to dimetric projection, which has two angles at approximately 116 degrees and the third at about 127.

This has several advantages. First, it’s easier to calculate sizes of objects as the x-axis is simply twice the size of the y-axis. This also results in smoother lines with less antialiasing.

There are three different shapes I needed to draw: a panel facing left, one facing right, and a floor/ceiling panel.

As these would be animating, I didn’t want to have to redraw them on each frame using the canvas drawing API. So I made a panel object that creates a small canvas and draws a single panel to it with a random width and height. The program can then blit each one of these mini panel canvases to the main canvas on each frame. Each panel also got its own random gray shade and the result was something like this:

Now as I said earlier, when you move things around in a 3d space, they are supposed to grow larger or smaller depending on the distance from the camera. But in isometric/dimetric projection this is not the case. So we’re really mixing two forms of perspective. Having the panels scale as they went into the distance didn’t look right at all. Having them remain unchanged wasn’t exactly correct either but gave an odd trippy feel to the piece that I actually like a lot. So that’s how I left it. Also, to mix things up a bit, I made some of the panels fixed in space and not rotating. This comes up to about one in ten of the panels being stationary.

Next was the lines. When creating the panels, I made it so that some – but not all – of the panels connect to one other panel with a line. About 40 percent of the time a connection is made. This seemed to give the right density of lines on screen. Here’s what that looked like initially:

Pretty ugly because the lines go directly from one corner of a panel to one corner of another, breaking the isometric/dimetric space. They just look random and chaotic. To solve that I forced the lines to follow the same dimetric angles as the planes. This looked a million times better.

In order to add a bit more interaction, I added a few functions to allow users to add and remove planes and to assign various color schemes to the planes (or return to grayscale). For the colors, rather than just use a random color for each plane, which would be a bit chaotic, I found an HSV to RGB algorithm. Taking an initial hue, I generate a different color for each panel by randomly varying its hue and saturation. This gives a more cohesive look no matter what hue is chosen.

The way the colors work is by redrawing each of the individual panel canvases with the same parameters, but the newly chosen color. Again, this makes it so it only has to happen a single time and the panels can then be blitted to the main canvas on each frame.

All in all, this was a fun project that I’m glad I had the chance to work on.


TXJS: A Look at Javascript as a Language and Community

August 30th, 2012 by Keith Peters

Recently, Todd Anderson and I attended TXJS, a JavaScript conference in Austin, TX. I wanted to give some general feedback on the conference itself, and then discuss a bit about JavaScript as a language and the JavaScript community.

The Conference

The conference was a one-day, two-track setup with nine slots and a day of training beforehand. Each slot was 40 minutes, which in my mind is short for a technical presentation. With a full hour, you can start to teach a few concrete techniques. But 40 minutes just leaves you time to get across a general idea, suggestion or viewpoint. In other words, in a shorter session, you might be able to say WHY you should do something, but in a longer session you could show HOW. Then again, even an hour is barely enough time to teach anything concrete and many people do not do well at it. All too often I’ve found myself getting bored and looking at my watch towards the end of a longer session. Perhaps conferences need to offer a mix of longer and shorter sessions.
It was very strange to be at a conference where I was not a speaker and knew nobody except the other person from my company I came with. I believe the last conference I attended without speaking at was Flash Forward NYC in 2004. In that sense, it was kind of a relief to just sit back and go to all the sessions and take it all in without having to worry about my own talk. Much stranger was just not knowing anybody there. Todd and I mostly hung out together and talked to a few others here and there. I’m far more used to meeting up with the usual crowd that has been present at every Flash event for the last 10 years. Also, being a speaker affords you a certain amount of mini-celebrity at an event, with people you don’t know coming up and talking to you, mentioning your talk, your site, your books, whatever. It was odd to just be another nameless face in the crowd. Odd, but probably good to get that perspective now and then.

The Training

The training on the first day was an overview of the JavaScript language from Ben Alman of Bocoup, a company located right here in Boston. Ben undoubtedly knows his subject matter and it was a solid day of training, but I would say his talk was targeted a bit more towards newcomers to the subject. I picked up on several small concepts I didn’t know and clarified several others, but it was largely a review of material for me. This is not to say that a review is bad. I went through a lot of the examples and tried out various iterations and came out with more confidence than I went in with, so that’s good.

Given the nature of the training and the time constraints of the sessions themselves, I can’t say that I walked away from the conference with a huge wealth of new knowledge of specific things about JavaScript. But I did walk away with several areas sparked with interest for future study, which I am actively pursuing. One of these subjects is Node.js.

New Interests

Node.js, for the uninformed, is a JavaScript engine outside of the browser, wrapped, optimized, and enhanced for use as a server, but also useful on a local machine. Node allows you to write server side applications in JavaScript, and also allows you to write command line JavaScript programs that run on your local machine. This can be useful for testing, build processes, automation tasks, etc. This is similar to how Ruby is largely used on the server, but commonly used for local build processes and other tasks as well. I picked up a book on Node.js and was amazed that within an hour of starting the book I was writing HTTP and socket servers. Not only did they work, but I understood every line of code that went into them. Amazing. Very simple yet powerful stuff that I’m glad to add to my knowledge base.

The next area of interest that was sparked at TXJS was WebGL. This is an implementation of OpenGL, the 3d graphics library used in many computer platforms including all iOS and Android devices, but implemented in the browser with a JavaScript API. Although I wound up missing the one WebGL session at TXJS (a tough choice between that and another session going on at the same time), I vowed to do some investigation of it on my own. Still working through Node right now, but WebGL is next on the list.

Communities and Focus

I’ve been thinking a lot about tech communities lately. I got a foot in the door of the Flash community back in the early 2000′s and while I’ve always delved into other various technologies, I never got really involved in any other tech communities. Now, I’m not saying anything as inflammatory as “Flash is Dead”, but I do think the Golden Age of Flash is in the past and it’s probably not going to see the level of excitement and support it saw in its heyday. Personally, I do not have a ton of interest in where Flash’s current road map is leading it, which is what led me to become more interested in HTML5/JavaScript. But I haven’t joined the anti-Flash crowd either. We’re still pulling in lots of Flash work here at Infrared5 so I imagine I’ll have a hand in AS3 for a good long while to come.
Anyway, when I started getting more interested in JavaScript development, I naturally started looking at the JS community. Unfortunately, I think it has quite a different dynamic than what I have become accustomed to with Flash. Firstly, the JS community is probably a lot larger than the Flash community ever was. But for a community of that size, it seems like there are disproportionately fewer well known names – JavaScript celebrities or “rock stars” if you will. I think a lot of this has to do with a lack of focus in the language and development practices. Love it or hate it, Adobe (and Macromedia before it) has always been a central point around which the Flash community revolved. They’ve held the reins on the product. You’ve always known you that you’d be getting a new version of Flash every 18 months or so, and that there would be a finite number of cool new features in that update. If you’re lucky enough, you might get onto the beta. Adobe/Macromedia have historically sponsored most if not all of the major Flash conferences and the same group of evangelists and developer relations people show up to talk and listen. Moreover, Adobe has given the ActionScript language a focus, with official components, tutorials and sample code that established a set of best practice and way to code.

Contrast that with JavaScript as it stands today. There is a standards committee that can’t seem to agree on anything. If they do agree on something today, it could be literally years before it is official. Meanwhile, browser vendors are moving forward implementing features years before they are official and sometimes before they are even agreed upon. Some are even implementing their own features that are not part of any standards process.

And that’s only the core language. Ask a group of JavaScript developers about the best architecture for an application and you will start a holy war. Classes or prototypal inheritance? The best MV* framework? AMD or CJS? Forget about it. World War III almost broke out a few months ago over the question of whether or not you should use semicolons! There’s even a growing question about whether or not it makes sense to code JavaScript IN JavaScript. With a steadily increasing list of languages that “compile to javaScript” but offer different – possibly better – constructs for managing large applications, it is a valid question. But with so many of these new languages around, and no standard, we are again back into the question of which is “the best”. And the arguments ensue…


It’s an exciting time to be into JavaScript, but not an easy one. There is massive innovation happening on so many fronts. There are dozens of new frameworks and libraries coming out daily – more than any person could possibly keep up with. Standards are evolving and there is something new to learn every day. The pace of this innovation makes it hard to keep up, and the lack of focus means that no matter what you do, how you code, or which framework or library you use, there will be countless people waiting in the wings to tell you you’re doing it all wrong. My advice is to learn what you can, don’t worry about the rest, and have fun.

Keith Peters

, , ,