Let me just say up front that the engineers, programmers and developers I work with are some of the most talented people in the industry. They manage to write software and code few others have the skill to create, and I am often in awe of their abilities. That being said, I’ve recently been reminded of an inequity between designers and programmers which I have to get off my chest.

Last week I watched the excellent video from the C4 developer’s conference with my friend Cabel Sasser of Panic fame called Coda Confidential. Something he said in his presentation struck home. At the 22 minute mark Cabel starts talking about Coda’s “Toolbar of Doom” and the implications the toolbar had on his developers. If you’re not familiar with the story, you can listen to the description of the problem from the C4 video, or check out Cabel’s blog post on the subject. The short version is that Cabel designed Coda’s toolbar to appear a certain way, the way he knew it looked best. But it turned out that designing it this way was hard. Very hard. After trying to bend the Cocoa toolbar implementation to their will, they decided instead to throw in the towel. And when Cabel says “throw in the towel” he means write their own toolbar code. From scratch.

Despite their impressive ability to solve the toolbar design problem, Cabel makes the point that he’s constantly “choosing his battles” between himself and the programmers at Panic. They don’t always have the luxury of writing code from the ground up to solve a particular design problem. They are constantly asking themselves is this particular design decision worth the time and effort it will take to implement? As I know from personal experience, sometimes the answer to that question is unfortunately, “No”. As a co-owner of my company, like Cabel, I’m constantly looking at the “big picture” to determine if a difficult design is worth the time and money required to implement it.

But from a creative point of view, purely as a designer, I still find it frustrating that the ideas and creations I come up don’t always get implemented. Some are considered “too difficult” or “too time consuming” to put into practice and therefore must be abandoned. I consider this to be a double-standard in our industry between designers and developers. As a designer, I’ve almost never told a developer I’m working with that a particular icon, user interface or web design is “too difficult” to implement. In my entire career, I think I’ve said “no” a grand total of 2 or 3 times. And that only happened because someone asked for something physically impossible, like making a 5 letter word legible at 16×16 pixels. I realize the programmers reading this will probably say “that’s because coding is more difficult than designing”. This may or may not be true, but that’s a whole other topic for discussion.

I know that even programmers themselves can’t always create the software or features they dream up, but it seems like they often have “outs” that simply don’t exist for us designers. We’re always expected to push through and solve the problem, while for them, something is either technically not feasible, would take too long to implement, or is simply a bad idea due to poor user behavior. Just once, I’d love to be able to tell a developer who’s asked me to solve a design problem “Nope, it’s too hard. Not gonna happen.”

I know that given enough time and money, pretty much anything is possible, and unfortunately most small software companies are not made of gold. We must therefore attempt to balance our desires as designers with what is best for the success of the product. I also know that the balance between a talented designer and a skilled programmer can transform mediocre titles into outstanding apps. I just wish I had the ability to even the score every now and then. I take solace in the fact that often as designers, we’re usually only limited by our imaginations rather than API’s or function calls. Our relationship may indeed be a one way street, but for developers, it’s often littered with road blocks.

They say you never forget your first true loves. I think that’s one of the reasons why I’ve recently gravitated to the pixel-click world of Arcade Daze once again. When I released the first Arcade Daze set back in August of 2006, it managed to combine two of my favorite things: video games and icons. I’m not talking about the photo-illustrative, super real creations that pass for icons today. I’m talking about good old fashion 16×16 and 32×32 pixel-clicked pieces of hand crafted art. Back before some of you who are reading this used a computer, icons were limited in the number of pixels AND colors they could contain. Placing each dot in the canvas was critical to the success of the final icon and something I thoroughly enjoyed doing.

Over the holiday break I started working on a new system replacement icon set for CandyBar based on Arcade Daze and I have to say it’s been a blast. I still have a way to go until it is completed, but I can already tell it will be one of my favorite sets. Every item in the collection is based off a 14×15 pixel click icon that then gets super-scaled up by various factors to flesh out all the sizes up to Leopard’s 512x512s. With Anthony’s help, I managed to create a series of Photoshop actions that take a lot of the grunt work out of creating Arcade Daze System. Thanks to these actions I’ll be able to include more icons in this collection than I’ve ever done before.

So stay tuned to the Iconfactory and in the meantime, head on over to my Flickr page for a sneak peek at what the pixelated future holds. This is gonna be fun!