The Design of CruiseControl.rb


If you’ve heard me talk about work lately, you have probably heard me talk about an Open Source project I’ve been working on with a handful of other folks at ThoughtWorks. Previous to now, it’s been “privately public,” existing on servers where people could get to it, but not so public that we were letting people know that we were working on it. Well, yesterday CruiseControl.rb finally went public, and I’m proud to say that I’m an Open Source contributor. I’ve dreamed of saying that for a while…

For those that aren’t familiar, CruiseControl.rb is a tool that software developers will use to monitor whether the software they are creating is “Building.” And it helps them to fix problems when they come up. That’s probably the simplest explanation you’ll get about what CruiseControl.rb does. Notice that I said simplest, not most complete. The original CruiseControl is a ThoughtWorks-led Open Source project, and was the first Continuous Integration tool…as far as I know.

Anyway, let’s talk about what went into the design of CruiseControl.rb. For today, I’m going to talk about the concept of iteration, and how it was applied in a unique, but purely designerly way on this project. I’ve blogged on this concept before…but this will serve as proof that we’re eating our own dog food here at ThoughtWorks.

My view of design is that you have to try out similar concepts over and over again before you’ll get to your final idea. The first example I want to point out was when we were working out what the CruiseControl.rb logo should look like. I talked over some ideas with the team, sketched out a bunch of options, and then created some high-fidelity prototypes in Photoshop. Here’s what I came up with:

cruise_logo.gif

Now, the first thing you might notice is that in the end we used none of these ideas. Our final result, shown below was a conglomeration of a bunch of the concepts used in these designs. In the end, we threw out all of these designs in favor of a combination. This means that as a designer, I have to be ready to trash ideas at the drop of a hat. I’m happy to do it though, in favor of a better design.

cruise_logo_large2.png

Now, it would be easy enough to apply this iterative design idea simply to the graphic design of system elements, but we used this concept throughout development. The dashboard is a great example of this. There were endless options when it came to possible ways for the information to be laid out. In the beginning, we started with this:

dashboard1.png

Pretty straightforward solution. A table with all the basics laid out inline. An iteration later, we played with some of the graphic treatments, and had this:

dashboard2.png

A couple new concepts there. The status is in a color that helps to quickly perceive the state, even without reading. The build buttons disappear in favor of a progress indicator if a build is already in progress.

But at this point we were just feeling a bit underwhelmed with the way that each project’s information was laid out. All text was equal with respect to visual hierarchy. There was nothing to signal what was the most important information at a given moment. And we just knew there had to be a better way to lay this stuff out. So we gave it another shot:

dashboard3.png

There were a number of variations of this design. In this version, you see a thought bubble bearing information about things people said about the most recent build. Other versions had no thought bubble, but portrayed the a failing project’s name in large text displayed as negative space in the red gradient. The idea behind this was that if a team set up a monitor across the room from where they were developing, they would be able to see which project was failing at a glance.

In the end, we bounced around between a number of ideas and ended up where we are today:

dashboard4.png

I’d say it all worked out pretty well. To all the users of CruiseControl.rb: I sincerely hope you enjoy it. Your experience while using the tool was heavily taken into account. Part of ThoughtWorks’ mission is to create excellent software, and in this case the software is Open Source…a concept many of us at ThoughtWorks very strongly believe in. With CruiseControl.rb we have tried to marry an excellent User Experience with an Open Source license, and I hope that you agree that this project is a success.

Rock on.


2 responses to “The Design of CruiseControl.rb”