Mezzoblue
22nd May 2008, 02:05 am
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.
More... (http://mezzoblue.com/archives/2008/05/21/handoff/)
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.
More... (http://mezzoblue.com/archives/2008/05/21/handoff/)