mezzoblue

A few months back at SXSW I sat on a panel that discussed how designers and developers play nice together on web projects. One of the things I never got around to mentioning was the system I use for handing off my static design work to clients and their developers for integration into their dynamic systems. Since I've been thinking about it a bit more in the past few weeks, I figured I ought to put this out there.

I prefer to start in Photoshop, and keep most of the big picture design work there if possible. I find designing with CSS leads me to make decisions based on what's easiest to code, whereas moving things around the screen visually gets me better results. Your mileage may vary.

During the initial design process, my mockups for client preview are delivered as flat image files. Each is given an increasing version number like home-page-v3.png, and by about v3 or v4 I'm usually pushing for signoff to start coding.

Since most sites involve multiple page templates, I'll often be concurrently designing some while coding others. The first one or two I do set the stage, so I try to pick templates to code that involve as many visual elements and layout variations as I can so that I'm thinking about the possibilities from the start. I'll build out those first few, then package up the HTML, CSS, and various image files into a ZIP archive and deliver that as code-v1.0.zip.

The developer will take that and start implementing that, while I move on to designing and coding out the rest. I'll build new ZIP files as I finish new templates and increase the version number of the archive. Each subsequent ZIP file is meant to totally replace the old. My instructions are basically, take these updated CSS and image folders and dump them on top of the last round.

The HTML poses a bit more of a challenge though; the new versions do replace the old static versions, but by at this point the developer I'm working with has started integrating them with their system, so it's not quite as simple as overwriting pre-existing folders. There's more manual work involved for them; they need to run a diff and apply the changes to their development version. Not a huge task, but a least a little more overhead than overwriting folders.

There's also an assumption built into this process: I own the CSS and image folders, and will be the only one making changes to them. In cases where the developer has needed the ability to modify CSS at will, it's proven a good idea to create a separate running development CSS file that ends up being integrated with the rest near the end of the project. Images could work the same way, though I usually find those are self-correcting; if the developer needs their own image folders outside of those I've built they'll figure out how to make it all work without my intervention.

And there's definitely a side-discussion here about designers using version control systems like Subversion. I've personally adapted to doing so, and what I'm describing above is kind of a manual way of doing the same thing. But the advantage to this system is that it firmly places the control of the application logic in the hands of the developers, and the designer never has to see wade around inside their Ruby or PHP or Python to find the place to change a div element's class, for example.

I'm curious to hear how other people handle handoff, as this is simply my own system that I've evolved over the years as the result of preparing in advance for moving goalposts like feature requests and design changes after my work is theoretically finished. I think it handles fairly well, but perhaps there are better ways.

Permalink › | 37 comments

At An Event Apart in New Orleans a few weeks back, something that Aaron Walter said on stage caught my attention.

During the portion of his talk where he discussed image replacement and its impact on findability, he addressed the white elephant question that has likely occurred to most designers who have used image replacement over the past five years or so: what does Google think of CSS image replacement, anyway? But the part that surprised me is that he actually had an answer: Google's okay with it, you won't be penalized for using image replacement properly.

Though I've long believed this to be true, I had never heard a conclusive answer. One assumes Google is smart, and their algorithms ought to know the difference between keyword-stuffed text and plain English content written for real people. For example, I've often wondered if the potential to abuse image replacement and load invisible text with keywords was akin to, say, the potential to stuff keywords into the alt text of img elements, or even into meta tags. The net result seems similar in all three cases: otherwise-invisible text on a page that could unduly influence Google's ranking. Presumably whatever algorithms they use to detect keyword-stuffing on the other two elements would equally apply to text hidden with CSS.

Not to mention the more compelling evidence that numerous sites I've built using image replacement techniques fare well in Google's ranking. That fact alone indicates that Google won't ban a site for simply making use of image replacement techniques (though I'm sure they've banned numerous sites using the technique in a sneaky, black hat SEO manner).

But again, I've never heard of an official blessing from Google. So I did some searching, and asked him for some follow-up (thanks, Aaron!), and here are the relevant resources that came out of that conversation:

Hidden text and links

The second bullet ("including text behind an image") accurately describes a few image replacement techniques. It's mentioned in the context of being a potentially untrustworthy activity, followed by a warning of the consequences of using it incorrectly. However, further down the page, the focus changes to techniques used for the sake of accessibility and why you would want to describe something search engines or users with assistive technology may not be able to access. This is a fairly accurate description of the intent behind image replacement. The article also suggests a handy rule of thumb for judging these techniques on your own: show the Googlebot the same thing your visitors see. Properly-used image replacement passes that test.

Best Uses of Flash

See point #2 in regards to sIFR, an ideologically similar concept to CSS image replacement, which suffers from the same potential abuse vectors. As this is a Google blog, it appears sIFR has an official blessing. Also mentioned in this article is a similar guideline to the previous one: show users and the Googlebot the same content. Sensing a theme here?

Working with Flash, images, and other non-text files

More of the same. Provide text alternatives for non-crawlable content, sIFR's great, etc.

So it appears that, short of a set of stone tablets carried down from the hills of Mountain View, we do have a fairly clear answer. Using CSS image replacement in a responsible way, where the image truthfully represents the content it's replacing, is safe to use. The simple act of hiding text from users is not enough to get your site banned from Google's index.

(This article has also been translated into Russian.)

Permalink › | 37 comments