Programmer for Hire

Yesterday I wrote about how developers owe it to designers to respect the PSD, or in other words to implement their original designs in HTML with pixel-perfect fidelity.  Today I want to turn the tables a little and explore how a design can be particularly good or particularly bad for implementation in HTML.

A designer who knows the gotchas of HTML implementation can make it drastically easier for a developer, and usually with little compromise of their artistic liberties.  Here now is a laundry list of the themes I’ve seen come up over and over.  With a clear understanding of these, a designer can make minor alterations that lets the developer sidestep all kinds of complications and tedious work.

Non-web standard fonts – Most browsers can’t render them and must fall back to a more generic stand in.  Ok, granted this first one does impose on artistic liberties.  Unfortunately support for embedding arbitrary fonts with the super cool @font-face tag is not quite ready yet for prime time.  (That, and to embed downloadable fonts in your site one must be certain all the legal i’s are dotted and t’s are crossed with respect to licensing.)  Bits of text that need to be that special font can be sliced out of the PSD and rendered in HTML as images.  It’s a little more work, the text isn’t searchable, there’s more to download, and can’t be changed as easily, but it can be done.  For some things this is entirely appropriate: a big shiny title for the site, for example.  It’s not great for menu items if you expect lay users to be able to update them (think content management system were non-technical folks can add pages to their heart’s content and their titles are automagically added to the site’s nav menu).

Fits-like-a-glove text – Sometimes text looks so good in a PSD: it fits right in the space it’s given, nestled up as one tidy line in it’s column on the side.  So long as it doesn’t wrap, all will be well.  If the text will never change, it can be sized to fit just right in HTML.  But if the PSD portion is a mock up of,  say, the name of the most recent blog post?  There’s no telling how long a given name might get, so the design there should gracefully accommodate a lines of text of any length.  In general a designer must be aware of which text elements are fixed and which are subject to change, and beware of rigid assumptions about the bounding size when it’s the latter.

Finite background images – Similar to the above, the web, unlike traditional print media, offers up pages or blocks of text of varying and unpredictable length/size/height/width (not to mention a given user’s browser window can be much larger than designed for).  Background images need to be designed with awareness of this kind of variability:

That’s about it for the consistent gotchas that the HTML medium offers over, say, print media: they pretty much stem from how ultimate control of the end product is, in two vital ways, not in the control of the designer.  To wit: while a designer can count on whatever font they use to print successfully by a printer, on the web fonts are limited to whatever an end user’s browser supports.  And while a designer can usually perfectly typeset whatever copy is to go in a brochure, they often must design for variable and often unknown text in a web setting.

This list is shorter than it used to be.  A number of design elements that used to be headaches (or impossible) to realize in HTML have recently become rather simple with the rise of support for CSS3, namely rounded corners, drop shadows, gradient backgrounds, and image-based buttons of variable size.  It’s probably only a matter of time before the use of non-standard web fonts is perfectly acceptable, leaving only the notion of designing for variable or unknown content the only real novel constraint a designer needs to specially accommodate for.

A few months earlier, while describing the characteristics and virtues of a development team of one, I mentioned how partnership between [aesthetic] design and development is a more than worthwhile exception to that model of going solo.  Now I want to explore how this particular collaboration finds its best execution.

The essence of the developer’s job here is to translate the designers’ design (I refer to this simply as “the PSD”, PhotoShop files being de facto standard for this kind of work) into live, working, spider-able HTML.  In this relationship, assuming the designer is worth their salt, the PSD can be related to as the immutable bible, the defining guide to design for the project.

To begin, it behooves a developer greatly to trust in the importance of implementing the PSD with high, pixel-perfect fidelity.  If this is not taken seriously, a good designer will insist that imperfections in a sloppy HTML implementation be corrected, and for the developer there is to get beyond defensive notions such as “no one will notice” or “it’s just a few pixels of white space”, and resist the temptation to write off the designer as an artsy ego-maniac with nothing better to do than whine about trivial matters to create busy work.

The path to appreciating the designer’s desire for high fidelity lies in appreciating the subtle structure present in the PSD itself.  This is where a designer being worth their salt comes into play: a good one typically imbues their design with numerous uniform rules which manifest in various places and provide a certain visual continuity that makes it look good.  A padding of 8 pixels will crop up again and again, or columns of content will line up horizontally with the menu item boundaries above, or the baseline of several disparate pieces of text will line up vertically to the exact pixel.

These sorts of things are almost never accidental: they reduce the visual entropy of the layout and bring order and balance.  The casual observer probably doesn’t look close enough to recognize this effort, but it registers subconsciously as a more pleasing experience.  Likewise when banging out an HTML implementation, it’s easy for a developer to overlook the unifying visual rules and make each portion of a design look right on its own, yet completely fail to achieve the design-wide continuity.

It’s no wonder that a designer would be remiss to see the carefully crafted aspects of their design (which, incidentally, is probably the rendition that the client approved) either ignored or butchered.  Even if an implementation is arguably 95% correct, it’s that last 5% that separates clumsiness from truly professional design.  Web designers are judged more readily by their websites than their PSD files, so it adds insult to injury when a first-rate design gets a second-rate rendition.

CSS to the Rescue

I used to think that HTML was an inherently finicky medium for presentation, and that differences between browsers and platforms would make any attempt at a uniform, pixel-perfect rendition of a design futile.  It turns out that with sufficient mastery of CSS & HTML one can realize most any design (I’ll cover rules and constraints for designers to play by when I turn the tables in the second part of this series, Respecting the HTML).

A quick aside to put this into context:  There was a time before I fully grokked CSS that I thought to realize, say, a precise 16-pixel spacing between two paragraphs you needed to do something funny like <font size="2"><br /></font> and cross your fingers it was right, or <img src="clear.gif" height="16" width="1">.  Painful and cumbersome, and a nice illustration of why learning CSS should be an alluring endeavor for up and coming web developer.

CSS, it turns out, is brilliantly suited for a developer to capture those subtle-yet-uniform rules of layout and spacing created so meticulously by designers.  I used to think woe is me for having to realize their designs in a clunky, unpredictable environment known as the rendering engines of all popular browsers and their versions.  Now it seems like designers have the tougher lot: they need to perfectly position all of those design elements on a PhotoShop canvas, whereas I can make a few measurements of pixel heights, widths, margins, and so on, write a few corresponding CSS rules, and the browser does my meticulous dirty work for me.

I used to think developers (myself included) were limited by the medium of HTML and browser rendering engines when it came to how close they could get a live web page to look like its original intended design, and that a large collection of imperfections would have to be pardoned.  Mastery of CSS reveals that, for the most part, there is no good excuse anymore when an HTML implementation deviates from the PSD.  If it seems that there is, chances are there’s a CSS guru out there who could make it right.

That said, there are somethings to be said for designing in a way that is savvy for the web, which I’ll cover next in Respecting the HTML.

Many thanks in this essay go out to Rob Fieldhouse of Playground, the designer with whom I’ve done the most designer/developer collaboration on web projects, and whose eagle eyes and elegantly structured designs guided me to this place of design rigor and appreciation.