Archive for the 'HCI topic' Category

The Design of CruiseControl.rb

Tuesday, March 13th, 2007

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.

Songbird is sweet

Tuesday, March 13th, 2007

Get SongbirdI’ve been playing with Songbird, the music player made by Mozilla. For those of you who don’t know, Mozilla is the brains behind Firefox & Thunderbird, for browsing and email, respectively.

My experience so far with Songbird is that it is awesome, especially given the fact that it’s still in early beta. It already does most of the stuff I get from iTunes, and a handful of things that have changed the way I think about music players…and the idea that a music player can help hook you in to the “media web.”

Anyway, if you’re up for the adventures of beta software, have a look at Songbird…it just might replace your current music tool.

The Devil’s in the Details: NYTimes.com edition

Tuesday, March 6th, 2007

Imagine the situation: you’re reading the newspaper online. Great article. It’s filling you in on the big story that everybody is talking about over at the water cooler. In a few seconds you’re going to go over to them and fill them in on this juicy new detail.

But then - wait - what was that word?

“Fed” What the heck? Not as in, “I Fed my dog,” but Fed as in “In so doing, he seemed to distance himself from Ben Bernanke, the current Fed chairman, who has been much more upbeat.” Now you’re sitting there wondering what the heck that word means so you can impress your coworkers with your knowledge…or really just not let them down by not knowing what you’re talking about with respect to their news conversation.

Then you realize the newspaper is helping you out. You double-click on “Fed” and up pops a short description of the Federal Reserve System. This isn’t only enabled for the big, important words, but all the words on the page…just in case you need a little help.

Cool idea. Implemented by Nytimes.com. Well done.

On Iteration

Friday, March 2nd, 2007

“It’s not an iteration if you only do it once!” - Fred Sampson, in the UPA Voice

Developers & designers: Please, please don’t just implement your first idea. Think about it for a few minutes. Sketch it on paper a few times a few different ways. Nine times out of ten you’ll find that your subsequent ideas are better than the first. That, my friends, is what iteration is all about.

Code Poetry

Thursday, February 15th, 2007

What a brilliant poem. Read it for yourself: StubbornSoft & MammothSoft

Some advice from Don Norman

Wednesday, February 14th, 2007

Just when you’re looking for some inspiration, a quote from someone famous is bound to help:

The most important consulting rule that I follow is: “Never solve the problem as stated.” Why? because it is invariably the wrong problem, usually being the symptom rather than the cause. Find the root cause and solve that, and then the original problem usually disappears.

- Don Norman

Good call.

Creating Visual Design Options

Tuesday, February 13th, 2007

One of the ideas that I try to progress when I join a new project is that much of my job will simply be about exploring options. If I do my job right, more than half of the options will end up in the trash bin, so that’s to be expected. Many people have a hard time with this. Questions I receive from clients and coworkers: “Why would we work on an idea that likely won’t get implemented?” and “Why would you bring up a functionality that isn’t even close to something that’s on our story list?”

The reason is that in order to get to a great design, we need to start with options. Very rarely is the first idea the best, so we have to work through early ideas in order to get to better ideas.

This is a common, fundamental thought in the world of design. The car you drive is the result of thousands of hours of clay modeling. A given advertisement in a magazine has likely been created and recreated 100s of times (in pencil, ink, and finally by a series of printers). You think the final design of the iPod just fell out of somebody’s head? They sketched and modeled that thing for months before anything physical was created.

Martin Hardee, who works and blogs for Sun Microsystems, wrote a great piece about working through visual design options. He describes how their design team walked through a series of Comps (which I learned was an abbreviation for “Compositions,” but Martin says it means “Comparatives”) in order to get to a final design.

Compare those little Comp images with the way the page looks today. Pretty different, no? That’s called iteration. Not the same kind of iteration that they do in XP, but still a similar idea. Let’s not get into that though…differences in type of iteration are for another post. Either way, I think the design looks good, and there is evidence of some ideas progressing into the present day, while others were cut right from the start.

If you’re responsible for the visual design of a website, piece of software, or really anything, try your hand at creating a few options to choose from. Even if you just sketch ideas on paper, your design is sure to improve. Giving yourself options is a great way to get to a more successful visual design.

Evolution vs. Revolution in Digital Design

Monday, February 12th, 2007

iPhone presentation
Originally uploaded by Dan_H.

One distinction many people make when defining a design project is whether the design will be another evolution of an existing technique, set of tools, or technologies, or if it will be a revolutionary implementation. This decision is most often made implicitly, generally without any direct thought about revolutionary design…the creation of ideas that enable a new paradigm of designed interactions.

Such was the case in the mobile phone industry until last month. For years we had seen absolute crap when it came to the design of mobile phones. Motorola, Nokia, LG, Samsung…they’re all guilty. Each of them simply evolved their phone solutions, simply adding functonality year after year, rather than assessing how users’ experiences might be enhanced as technology evolved.

Now, Apple has designed the iPhone, which rethinks how people can interact with their mobile phones. Apple didn’t simply sit around and design the next thing that makes sense…they did the leg work of thinking how the mobile phone could be simplified, how specific interactions could be made easier, how to make functionality make better sense.

Why was Apple able to do this? Why is it ok for them to rethink the design of the phone, while all the other big names just sat around and evolved? I’ve got a few ideas:

  1. They had nothing to lose.
  2. They’re not afraid of losing a few customers to excite many others.
  3. They realize that good design doesn’t necessarily cater to everyone, but works well for those who are meant to use it.
  4. Design is a first class citizen at Apple.

We should all take a lesson from Apple and their iPhone. Sometimes playing it safe, and simply evolving, is not the best progress. Sometimes it is ok to shock and awe…when the end product is much better than anything else available. We need to rethink our interactions with customers, and not necessarily just stand by the same ol’ same old, but rethinking the way the computer can enhance human performance.

It’s not about touch screens

Sunday, February 11th, 2007

In a few months, remember that you heard it here first: Technology pundits are sure to hail Apple’s iPhone and soon-to-be competitors for using touch screens in their designs. I submit, and will continue to maintain that it is not the touch screens, but the interactions that those screens afford.

Many others will try to compete with the iPhone, but they’ll have to do a lot more than tack on a touch screen interface to their current phones in order to keep up. Adding new technology is the lazy solution. Redesigning based on human wants and needs is the one that wins battles in innovation…

On Mobile Phones and Commitment

Thursday, February 8th, 2007

I was talking with a friend the other day, and the fact that he does not have a cell phone came up. I, of course, was amazed. Immediately I said what most mobile-toting folk would say: “I don’t know what I would do without my phone!”

His response was simple: “No, it’s easy. You know what you have to do? All you have to do is keep your commitments. You make a plan, and you stick to it.”

What an enlightened thought. It’s completely true, mobile phones allow us to be carefree and without a set plan. But maybe this isn’t always a good thing. Perhaps this is causing us to forget how to make and keep commitments. And a society that doesn’t know how to commit to something is almost certainly a bad thing. Sure, we can be unchained on a minute-by-minute basis, but don’t we lose something by acting this way?