My Drupal Blog

Basically, if you really want to be simplistic about it, Drupal theme design can be split into two clear stages – the design and the build.

The design is the bit where all the creative stuff happens. It’s the ideas stage, the point of questions which start ‘I wonder…’, and ‘hang on a second, what about…’. This is the place where Photoshop becomes my new best friend, and I try to pull everything together into one pretty picture. I like this stage a lot.

The build is the bit where I take the pretty picture and turn into a real live web page/site. This is the stage where I put on my code-monkey hat. It’s also the point at which I wish for some freak occurrence whereby I wake up tomorrow and IE6 no longer exists ;) I like this stage as well, although maybe not quite as much as the design bit, but it’s marginal.

Ideally, I think that these two stages should be completed in this order – design first, build second. After all, would an architect build a house without a complete design? Unlikely. So why should the virtual world design and build theory be any different from the real? Yes, it is true that the problems one may encounter, and the penalties one may pay, by jumping the gun in the virtual world are probably less severe than in the real world, but it’s still wasted time, and time is a precious commodity for any designer.

However, it’s not just wasted time which is the problem. Coherent design is hard enough to come by anyway, and is only made harder still if you continue to yo-yo back and forth between a bit of design, then a bit of building, then a bit more design and so on. If you design everything first you will be looking at the whole picture. Furthermore, and perhaps most importantly of all, designing first means that you will be less likely to compromise on your design in order to accommodate your build.

Now I’m not saying that you shouldn’t consider your content before you start to design – far from it. In fact, I believe very strongly that the design should fit the content, and not the other way round. But this doesn’t mean that the design should be ignored or restricted because you’ve already decided that this block must go here and that block must go there. As I’ve said in a previous post you should not underestimate the importance of the look of your site, because rightly or wrongly people will to some extent judge both you and the quality of your product based upon this. The skill of a good theme designer, therefore, is to balance the design with the functionality and content, and create a coherent whole.

Unfortunately things are rarely this simple and, just like a kid who’s been told not to touch something, I must be honest and say that despite my best efforts there always seems to be some part of a design that I find myself fiddling with way after I’ve actually started to build the theme.

I justify this by saying that there is just no substitute for seeing how the whole thing looks in a live test environment. After all, it’s tempting to think that you’ll be able to figure stuff out as you go, or that you’ll find the answer to some design issue during the build stage that you weren’t able to resolve in the design stage. In truth, though, I rarely find that it is advantageous. Whilst I may resolve the issue this way, ultimately it’s almost always the case that it would have been both quicker, and easier, to figure out a solution first (during the design stage) and then implement it second (during the build stage).