The last few weeks I’ve been doing a lot of CSS writing. While this doesn’t necessarily fall under my job role, on many projects I end up doing it because I’m the “designer”…therefore I am put in charge of implementing style. Whatever. Turns out I kind of like it, so I let it pass, but we need more developers who understand CSS like the back of their hand. We can also use more designers who understand and write CSS as well. If you’re either, send me an email (jevnin at thoughtworks.com)…we’re hiring.

Anyway, what I really came here to say is that the world absolutely, positively needs a tool that is dedicated to CSS testing. I do enough switching between browsers, browser versions, and operating systems to make one sick. In my opinion, this is a giant gaping hole in the process. If our users can’t see our content as we intend, the web-based tools we build will not be useful, if at all usable.

Of course, the browser companies could do their part to follow the standards. Some, for the most part, already do. Others blatantly defy the rules. Nonetheless, since these fellows don’t play well together, we (the builders of the web sites and web apps) are in need of a good testing tool in this area. I’ve Googled for some solutions, but really they all either look crappy or they charge up the wazoo.

There’s obviously a huge need for this tool. Where’s the open source solution?

Banana = Vision

Love it or hate it, Bruce Nussbaum makes some great points in Are Designers the Enemy of Design? I think I buy most of it.

Is Design a specialist activity? If it’s done well, generally yes. Is that likely to change? For the most part, I don’t think so. Will ‘the everyman’ have the opportunity to design more and more in his lifetime than ever before? Absolutely, so we better start learning how to share Design Strategies.

Also, can Apple move past two major strikes (closed source everything and unsustainable products) and really survive the long haul? I just don’t know anymore.

Anyway, have a read for yourself…

Update: Sorry about the dead links…I think they should be fixed now.

If you’re not looking at this entry on my site, it’s not gonna look quite right. For the best view, look here.
Just wanted to let y’all know that I’ve fixed my blockquotes so that they’re hanging. You’ll notice that I not only hang my blockquotes, but list items as well. Check it out:

This is what it looks like when I have a blockquote. Notice how the quote mark does not get in the way, and there this block of text has perfect left-alignment with the rest of the text on the page.

And what about lists?

1. Here
2. is
3. an
4. ordered
5. list

and

• Here
• is
• an
• unordered
• list

Why do I do this hanging business?

Notice how all the text on the page aligns perfectly on the left? That makes it easier for you to read the text on this page, and after all, this blog isn’t just about me…it’s about you too! Typography is fun!

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:

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.

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:

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:

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:

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:

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.

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.

“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.

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.

All sorts of automated tests happen on projects at ThoughtWorks. There are Unit Tests, Functional tests, GUI tests, and others that make sure the software we’re building runs well from the most back-end function all the way to the user’s interface.

One thing we don’t test, however, is where particular elements land on a screen. We make sure that the drop-down box you were expecting to be on a given page is there, and that it holds the values that should be there, but we don’t make sure it lines up right next to the label that explains what it is for.

I’ve brought this up a few times while on projects, and developers have told me that we don’t test for screen position because we just can’t. I wonder how true this is.

When it comes to visual design, the placement of elements on an interface does matter. When doing a visual assessment, it’s important to me that all the pixels on the left-hand side of the screen are aligned to a grid line. It’s important that that drop-down is placed right next to its label. It’s vital that the company’s logo is always on the top left. And even on a low resolution monitor, this input box needs to align with the others. On and on…there are plenty examples.

I understand that testing for screen position is a hard problem, and is impossible with our current automated testing tools. But is it really impossible altogether?

Hey all you developers out there, weigh in with your opinions. And for anybody else out there…how important would a tool that does this be to you?

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.

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.