The modern day cut-up man/woman/shop is dead when it comes to a dynamic system. It’s sad because no obituary was written nor news alert on AP/CNN posted, but it’s true. The theory, that a company or individual needs to ‘cut-up’ the design composition into a semi-working website before full development of the backend system is highly unnecessary and inefficient. In a time where budgets are even tighter than they have been in years past, combined with a need for continual push around efficiency in development, eliminating the process of cut-ups before development needs to die quickly.
I want to take you on a trip down memory lane where I saw for the first time the method of cutting up a design before development was an absolutely waste of my time and the clients’ budget. It was the year of 2008 and I was just a fresh, bright-eyed, bushy-tailed developer out of college trying to land my first gig in the DC area. I ended up in at a PR firm in Old Town where there was a small web division of a backend developer, designer and myself (as a junior front end developer). I had prior experience working with static sites and others based on light CMS before, but Drupal was a new world to me. As per direction of my boss, I was to take Photoshop compositions and start to ‘cut them up’ into a semi-working example of the website. I spent a few weeks creating my markup, slicing all the images and optimizing them; trying to write semantic HTML and CSS to pass all the W3C tests before getting my boss’ final approval. Development had begun while I was busy copy/pasting markup and styles that stayed consistent from page to page.
When I got the green light from my boss to go ahead and apply my work to the Drupal install, needless to say, I was stunned by what I saw. There were div containers many layers deep, regions, blocks, menu’s and views classes that were just all over the place. I was thoroughly baffled; I had spent weeks making my code as perfect as could be, only to have Drupal spit in my face. To finish up the story, I looked to my senior developer to help with the distress I was having from all of the unfamiliar terminology and to massage the code base to more closely resemble my markup (done via template overrides/modules, which when I look back was a horrible idea). Right then and there, it was apparent that this wasn’t the way these sites should be handled and I started to retool my techniques for Drupal theming.
Rather than cutting up a site completely, or inheriting a cut-up from a design shop, it would be best to skin the site through the development process. Not only does this cut down on the budget (the hours spent developing the markup, CSS and images), but it allows the front end developer to better understand the output that is being generated. It even allows time to customize the code (whether it be in a template or views output) in the manner the developer may want and because this would be the first pass at markup, the client isn’t being charged twice to complete the same task. It also lets the client, designer, developer witness scenarios that weren’t planned for in the design or cut-up: titles that run multiple lines, unanticipated white space, blocks that don’t line up, areas without word counts, layout structure that doesn’t conform to specific needs and countless others. By theming the site along with development, the situations can be tackled head on proactively, rather than fixing them retroactively.
I don’t want to say that cut-ups should go the way of the dodo bird, but there is a time and a place to wisely utilize this practice, and it’s not with large complex websites that run Drupal. Properly maintained dynamic systems, where functionality and presentation are separated don’t really benefit from this procedure. When the functionality is dropped into templates/pages directly *cough* bad Wordpress *cough* then perhaps this practice still has some legs. In the increasing effort to create efficiency and appease client budgets, streamlining a step in the development process is certainly a good start.