On the Floor

Of paramount importance to designer-programmer harmony is an understanding within each camp of the other's capabilities. It is not enough for a designer to know what websites look like in order to design websites, despite where the bar may appear to currently rest. The designer has to know what capabilities the programmers have, what features are possible, what is worth the time and effort and what isn't, and how all of this can change overnight.

One major area in which this is especially pertinent is browser support. Countless hours have been spent and are still spent by programmers squashing bugs and jury-rigging websites to work in browsers like IE6. However, designers are also affected by legacy support; newer browsers boast a raft of features that expand support for everything from transparency to typography. In many instances, though, especially where clients are using older browsers or have less web-savvy audiences, these new features must often go unused. Never mind going from print design to the web -- the real hassle is in going from a static mockup to a live website. Web developers are understandably averse to anything that is trivial to create in Photoshop, but hard to implement in code. This often leads to programmers making design decisions on their own in order to comply with older standards.

To avoid this nigh-apocalyptic nightmare scenario, designers must be informed not just of their programmer colleagues' capabilities, but of the limitations that are often placed on those capabilities. As designers, we expect, or at least hope, programmers will come to us with design questions. This is an unreasonable expectation unless we are also willing to make sure our designs are not impossibly idealistic visions of an alternate reality in which hard-boiled internet cops arrest browser developers for refusing to comply with web standards.

It's not all about putting ideas on the chopping block, though. Designers aren't just responsible for how a website looks, but also for how it performs. The way things highlight, react, move, expand and contract, and animate are all within the designer's scope. New developments in programming often translate into new features in the designer's toolbox. For example, our website makes use of animated sliding elements and drop-shadows on text, two features that are standard features now but would have been impossible or represented an enormous effort in years past. However, designers can only implement what they're aware of. Working within traditional limitations often leads designers to behave conservatively.

The best way to foster this level of understanding is to communicate often and openly, to sit down together and discuss why this decision was made and why that change was necessary. Occasionally something may be thrown across the office, exasperated remarks might be found in the code comments, and designers may grumble about their layout not being exactly what they had in mind. But just as designers appreciate a programmer who can slice layouts in Photoshop and understands the use of leading and whitespace, programmers respect a designer who can write a style sheet, kill an Actionscript bug, and refrain, no matter how difficult it may be, from adding drop shadows to elastic rounded-corner drag-able gradient boxes.

For a couple more months, at least.