Drupal – Designers vs Developers, can’t we get along?

There’s a lot of good insight in this blog post from the creator of the Views module for Drupal. I’m a big fan of the module, and when I’ve had to dive into the code behind it, I’ve come away pretty impressed. That’s pretty rare for a Drupal module, IMNSHO. Also, if you don’t understand or like the CSS classes and id’s that the Views module uses in its markup, I’m afraid you don’t have a good grasp on the “Cascading” part of CSS or how to use selectors effectively, if at all.

Before reading this, I’d never thought to frame how designers vs developers work in terms of the re-usability, perceived or real. Of course, that clarifies a lot for me, like why Designers love to design in Drupal, the latest site is a standalone piece of art, of course! Or, changing interactions from one site to the next, because each site is a “blank” slate, only to be mystified why it takes so long to implement this version of, say, a Document Library, when you’ve done dozens sort-of-like-it before. An Observation About Designers Versus Developers | Angry Donuts

The converse, however, is not true. If a designer desires a particular piece of functionality, the services of a developer are required. Now, in the Drupal world, we have created a pretty good illusion that you may not need the developer. Drupal, particularly with Views and CCK, allows you to utilize surprisingly complex bits of functionality without needing a developer. But this is only an illusion that you don’t need a developer. The truth is, that you only don’t need a developer as long sa the functionality that these packages provides you happens to be the functionality that your end goal requires. When these things are in sync, this is great. And Views and CCK can do a lot out of the box, so it’s pretty easy to get to 90%, but sometimes that last 10% can be daunting.