This Author Sees A Long Drupal Slope

I'm prompted to write a post that is a bit less technical and more of a muse on the state of the Drupal project. Anyone who follows the community will know much is made of a developer/designer divide. To be honest, I still don't quite get why this is. I don't personally feel it.

I *do* agree there is a divide in the community, in so far as there are definitely folk who seem to have an easier time of making stuff happen than others, not always for the right reasons, and some voices are far louder than they ought to be. But that's life and life isn't fair. I certainly don't see it as developers vs. designers.

And commercially I find no divide. Within my business the developers and the designers are on the same side and we work together, within the constraints of the product, to produce the best work we can. We do some nice work too. I have worked in places (advertising agencies, to be precise) where departmental organisation effectively pitches designers and developers against one another, but it wasn't constructive or pleasant. Not in my yard, that's for sure.

It's all about trade-offs and mutual respect. The designer wants to do something, the developers says we *could* but it will take a week, whereas if we do it like this it will take a day, the designer says ok, but not like that because it destroys the whole concept, how about this, will it be easier? etc. The need for compromise due to, budgets, goals and product limitations affect the entire team, but we turn that in to a positive thing. "Ok, the system isn't perfect but we can find a solution. So how are we going to solve this together?"

We find, that with a bit of give and take, Drupal pretty much keeps us all happy. So I was rather surprised to read these tweets on Twitter yesterday:

modulist: #drupal Trolling for functions or snippets for theming is an *enormous* waste of a designer's time and a real profit suck.


modulist: #drupal Unless you're a developer, digging for snippets and functions totally fucks with the economics of using Drupal.

Slightly confused, I replied and asked:

greg_harvey: @modulist Why would a *designer* be trolling for snippets and functions? Surely you design it and leave that to the devs? =/ #drupal

To which Claudio replied:

modulist: @greg_harvey The whole reason we embraced Drupal was because it empowered us to build ambitious sites without partnering w dev firms.

Woah. Let's back up there a second. Build "ambitious" sites without partnering with a dev firm? You want to build complex applications without talking to a developer? I'm exaggerating to make a point, but what that *sounds* like is you want to be able to build Facebook with just a UI and a bit of HTML know-how? That's a fine goal, but there isn't a CMS on the planet that will do that.

Furthermore, I would never presume to be able to make a really pretty website without hiring a designer. I would expect a website I designed to lack that certain "je ne sais quoi". God knows, I've tried. My designs are always ok, but never quite right. I always end up hiring a professional designer. Why, then, would a designer presume they don't need a professional developer to make their grandest ideas work effectively? I replied again:

greg_harvey: @modulist Depends on your definition of "ambitious" but I'd never expect it (or anything) to do that. Custom requires development. #drupal

And that was that. Until someone I follow, @omega8cc, re-tweeted this blog post by the same person:

The author starts out by talking about some of the strengths of the Drupal community, including it's code management (I remain to be 100% convinced - I think the systems are good, but...) He also makes the totally valid point that right now Drupal is managed far too closely by developers. The balance is all wrong. These points I personally accept, however, shortly after that he loses me. He goes on to make numerous points that he claims makes Drupal alienate designers.

The problem I have is the points feel like they've been written in criticism of Drupal 5.x. I believe many of them would've been true a year ago, but aren't any more. The article seeks to highlight points that are either already addressed or very publicly being addressed, which makes it potentially misleading to a reader from outside of the community.

Firstly there is the implication that you can't achieve anything in Drupal without using a boat load of PHP. Huh?? I beg to differ...

Drupal's templating layer is brilliant for this. It got way stronger in Drupal 6.x and there are even cooler changes to come in Drupal 7.x:

The whole point of the templating layer is to provide a set of files that are predominantly HTML (come on now, if you can't work out what print $content; means or how an if statement works, you really *need* a developer). The template variables are well documented (and even inline in some of the better starter themes like Zen) and if you don't like mark-up, layout, etc. you can just change it. Easily. With Drupal 6.x theme functions in PHP are all but gone. Forget about template.php - you barely need it.

Practical example? My own company website (while not the prettiest or most adventurous Drupal site in the world) uses almost no custom PHP. It uses a theme based on the Zen starterkit, some CSS changes and a carefully selected group of modules that I configured correctly. In fact, I deliberately did not do any PHP development work because I did not want to create a website that would become a nuisance for me to maintain:

Want more? Then I would urge Claudio to sit in on the Sony Ericsson presentation at 9am on Friday 4th September at DrupalCon (or watch it later if he can't be there) for a fine example of why I think he is totally wrong. Synopsis is here. I can't wait, personally:

There is, of course, a caveat. Bad module developers have always been able to make it difficult for themers and designers and that will never change, but that's not a Drupal problem. That's a people problem. And it's fair to say that all of the major contrib modules respect the rules and make sure that practically all produced mark-up, from Drupal 6.x onwards, is encapsulated in template files.

If you want to *change* how a module works, alter a workflow, add a step to a form, etc. then sure, you need a developer. But that is *development* work. It is new features. It is fundamental changes to the intended purpose of a module. If that's what you need to do, then you're not theming any more.

If you want to change design, really theme, then the tools are there and they work well. It is not fair to say there is a high skill level required for theming. In Drupal 6.x there is a *low* skill level required for theming (nearly everything can be done in TPL files and CSS) and a *moderate* skill level required for changing the functional behaviour of modules. If you want to change functionality, we're not even in the same ball park. You can't do that with theming, in *any* CMS. You need to be able to make the mental distinction between what is a design change and what is a functional change.

And as for PHP code snippets, in my experience they went the way of the dinosaurs the moment the Views module came out of beta. It has totally removed the need for them. I haven't used a code snippet in a block for *years*. Add Panels 3 to the equation and they're gone man, solid gone.

Secondly, there is the implication that designers have to get involved in CVS. For a kick off, they don't. What on earth would a designer want a CVS account for? It makes no sense. If you're a designer, you won't be building modules. If you're a designer you're probably designing themes, which is all cool, but building themes? Nah. Not likely. If you need to build a theme, and if you have any sense and you don't know any PHP but you know a bit of CSS and mark-up, you're going to download a starter-kit theme like Zen and do it that way. Only a designer who's a masochist would try to develop a theme from scratch without the assistance of a developer. Hell, we don't even do it and we *are* developers. So why, oh why, would you want to touch CVS? Don't. It's horrible. Forget about it.

It's also really easy to bash the CVS repository Drupal lives in, because CVS *is* pre-historic. But Drupal is now over 10 years old, there is a huge infrastructure and masses of data and inter-dependencies relying on that CVS repository. The webmasters are probably tired of pointing out to people who say "Why don't you use {insert_version_control_system_of_choice}?" that if *only* it were that simple, they would.

Finally, there is the argument that the design of is a put-off. That may be true, but we all know full well that Mark Boulton is working very hard, right now, to address that, so to use that as a stick to beat Drupal with is misleading. Someone who does not know anything about the community would say "hell, yeah!" But someone who *does* know that search on has just recently been totally overhauled to improve experience, that design is in the pipe and will be released imminently and that real, serious efforts are under-way to turn that tanker would find that an unfair point to pick up upon.

Yes, we know could be a helluvalot better, so let's leave that one. It's being worked on and you know that, I'm sure.

If you find Wordpress easier, fine, use Wordpress. But remember, you are clipping the wings of your website. Wordpress is not a CMS any more than vBulletin is. It's a blogging engine with bits bolted on. It cannot do what Drupal can do, but if it does what you need, that's cool.

I'll sign off on a final point about the whole designer/developer thing. It works both ways - the creative community needs to embrace developers as well and accept that you can't do everything on your own. If you start from the standpoint of "I selected this product because it means I don't need developers", which it would appear from Claudio's tweets that he does, then I don't believe you can have a healthy relationship with a community that relies on a symbiosis between the two disciplines of design and development.

To answer Claudio's question, "Has Drupal peaked?" - clearly I don't think so. Not by a long shot. I think it's only just getting interesting. But don't believe me, ask a designer. Ask Morten. =)

mortendk: I know im putting my love into the right community: #drupal -fuck yeah! offcourse theres gonna be some frictions between the front/backend


by Anonymous on Fri, 28/08/2009 - 12:09

Just my two bits:

For the last year I've worked with Drupal 5, building ecommerce sites, writing modules etc. Recently I decided to re-develop my personal site in Drupal 6.

I was utterly blown away by views. Using CCK and Views I now have a *fully* functional web site without writing a *single* line of PHP.

Impressed? That doesn't even come close.

by eigentor on Fri, 28/08/2009 - 12:26

Greg, nice of you to write this post.

Well I am divided into agreeing and not.
While you say criticism would have been valid a year ago, I'd argue that you are talking about the future, and it hopefully won't be valid in a year.

Disclaimer: personally I never had a problem with drupals template layer, I loved it right from the start. But probably I am quite a geeky person, not a "real" Designer.

Some points:
There are loads of designers using drupal (probably working in Drupal-Shops) there are hardly any active in the community.

We will have a new drupal version soon, and we threw out all "old" themes like pusbutton et al. We had various discussions that Garland won't cut it anymore.

Still there is not even a trace of new themes for core. This does not blame the designers active, like Morten, Stephanie and Jim Burnz, but rather proves that you can count the rest on two hands.

So as long as there are hardly designers visible in the community one cannot even talk about if there is an infrastructure around them. The percentage of outspoken designers (I do not mean Themers, big difference!) is a lot smaller than the percentage of women.

Another one: one does not need to know PHP to theme drupal. True. But if you get into the nitty-gritty, you find all kinds of PHP inside themes. A non-coder is just appaled, and you quickly get the notion, not knowing PHP you cannot do "the cool stuff".

CVS. Ah. I should not care about CVS. So how do you think will we ever get more beautiful themes onto It does not have to be disputed that the themes on have the biggest chance to get popular, so a designer has quite some gain in putting one there. But CVS for designers, just as you say, is like heading right into the piranha pool willingly, having bathed before in aromatic sauce. I cannot remember any experience in drupal as wtf-y as getting a hang on that.

I really second you in there _should_ not be an against each other. Designers need to step up and come in, and the ecosphere will balance more. If the present Community wants to have them and needs them, the entire thing needs to ge thought through more with the right hemisphere. What we need is voices of outsiders, step outside the box.

Marks and Leisas experiences may be special, since the did the piranha thing in the most amplified way imaginable: having a mark on the forehead saying "We will rearrange your very living room, if you want or not. Be prepared to find your bed in the kitchen tomorrow."

Still some time ago we had a very interesting discussion in IRC about what a prolific designer could gain in joining the drupal community and why he/she should do that. It was very enlightening.

by greg.harvey on Fri, 28/08/2009 - 12:43

Thanks for the long reply.

Life would be pretty dull if we all agreed, so that's cool. =)

I didn't want to write a piece about the past - I wanted to make the point that things are moving forward and the other piece wasn't fair in its criticism (IMHO) because the criticisms don't apply to the present (Drupal 6.x) and the future (Drupal 7.x).

With the PHP thing, I think my point is "the cool stuff" ain't theming... if you want to get in to it, great, but you'll need to know PHP. Don't say it is theming and say theming has a high skill level. No, the problem is you want to go to the level above theming and it frustrates you because you don't have the skill (not you personally, obviously ... but you know what I mean).

Finally, CVS. Ah, yes. Indeed it is a cross Drupal is bearing, but it's not *that* hard. And I'm sure there are hundreds of developers who, if a designer asked them, would happily manage a theme's CVS namespace on behalf of a designer. I know I would. Perhaps it's as simple as that? A "Help A Designer With CVS" scheme, in the short term. Perhaps designers who want nothing to do with CVS could post zipped themes in to an issue queue to be picked up by people who *do* have CVS access as and when they have time? That way you side-step the whole unfriendliness of CVS by leaving it to people who already know how it works.

Or just stop storing themes in CVS.

I guess one fine day Drupal will move away from CVS, but no time soon - it's just too big a task. =(

Anyway, thanks again.

by Pasqualle on Fri, 28/08/2009 - 18:50

There is already and alternative of cvs theme storage, which works nicely with update status
Drupal theme stored on feature server:

all you have to do is package (zip) the theme and upload.
there is not central feature server for themes (yet), so you need to use your own Drupal site for theme distribution..

by greg.harvey on Fri, 28/08/2009 - 20:28

Thanks for posting this. It is not talked about enough. =)

by Ronald on Fri, 28/08/2009 - 14:13

thanks for this - puts some perspective back into the debate. I think all this frustration is ultimately a good think. You need to get people fired up and believe that after you throw things up in the air they are going to land back in the right places (i.e. working together to fix the problems!)

by Baris Wanschers on Fri, 28/08/2009 - 15:38

I work with Drupal since version 4 and saw it develop and grow to a CMS that can almost do anything. Think of something you want to achieve on your site and there is a module that can do it. I bet. Even more; I think there will be at least 4 modules that can do what you want. You *only* have to choose :)

That's for me the most challanging part - finding the right module for the job. And that's a point in which the Drupal site can perform much better. True; they made some improvements lately. But still. How can I find a module that works with Taxonomy AND Views AND CCK AND Drupal 6? That's still not possible, you have to browse though a lot of modules to find the one you need..

@greg: I agree with your vision on using CVS. I see myself as a designer who can theme. I could really use a "Help A Designer With CVS" scheme! After years of using Drupal, I still not know how to build my own patches for example :)

Thanks for your post. Great vision, food for thoughts!

btw: Please install Mollom. Now trying to crack the code for the 3rd time. I hate them.

I appreciate the long and in-depth rebuttal. It's really helped to nail the core issue here:

Should Drupal require a developer or not?

It's a big fork in the road for Drupal and a business decision with huge implications. If the answer is no, then Drupal can grow to be a real disruptor in publishing, a game-changer.

If the answer is yes, then we can set a lower bar for usability, and developer won't have to gift-wrap their code for dummies. It also means that Drupal won't -- and shouldn't -- gain adoption outside of the developer community.

My firm is caught in the middle. I decided to have us adopt Drupal in 2007 because it was empowering. It made us more competitive when bidding against other firms.

Here's how the math works:

If we bid on a small project, we'd try to share a budget with a development firm. Let's say it's $15-20K for us and $20-25 for our dev partner. We'd bring in the new business, but it would benefit our partner more than us.

It also allows us to bid as a single vendor, making it far more likely that we'll win the bid. Clients don't like managing multiple vendors because it dramatically increases the risk of the project failing for them.

If we brought Drupal in-house, we could bid $25-30K for the same project that could have run $45,000. I'd also be able to look over the shoulder of whoever is building the site and be able to make ongoing critique, working in a more agile process. I can be a creative director overseeing a well-integrated process, as opposed to slipping notes under the door to teams at a different location, or even in a different time zone.

I don't have an anti-developer bias; it's the cruel economics of the industry. As margins get smaller, we're looking to squeeze what little profit we can, wherever we can.

You're right: if Drupal does require a developer's involvement, then we're in the wrong business or have chosen the wrong tool -- unless we choose to partner with a firm like yours.

by greg.harvey on Fri, 28/08/2009 - 16:50

For listening and taking the time to reply in as much detail. I totally see your point, and I think mostly Drupal probably isn't the tool for your business, given how you're describing your needs. There probably isn't a single tool. You probably need to maintain a strong knowledge of all the options and pick the right horse for the current course - not easy.

It just sounded to me like you were expecting too much of Drupal and I wanted to point that out. I know you're not "anti-developer" per se. I didn't really imagine you would be. But I don't think you can do advanced Drupal work without one, so in that respect it probably is the wrong product for you.

A friend of mine in Milan is an entrepreneur with a small, funky design shop and swears by Wordpress. He's not a developer and it serves him really well. He does some nice stuff with it. Drupal made his head hurt. =)

by Chris on Fri, 28/08/2009 - 19:11

I read your post and was pretty put off by it at first. The idea that you want to do something custom without a developer seems absurd to me. I do understand a little more where you are coming from in this response though.

Let me use a print allegory as an example of why this isn't possible. This is what I experienced in the print industry over and over again. About 10 years ago new technology allowed print and prepress to split up. Suddenly you had small prepress firms popping up everywhere doing all the trapping and film output for the print shops. For a bit it was cheaper and everyone made money. Then as the ecconomy tightened the print shops decided they could make more money by buying their own image-setters and hiring a couple of people to do the prepress in house. Boom, the small image bureaus started being absorbed into the print houses again and everything returned to the way it use to be. A few years later print on demand hits big and you find these POD shops popping up. Now I'm already seeing that being absorbed back into the larger traditional print shops. This is roughly a 5 year cycle and has been that way since the printing press was invented.

Right now you either have to outsource it or hire someone. If you hire someone and build up your company I guarantee that in a couple of years there will be some other advancement where a specialist is needed outside of your company and the cycle will repeat.

Expecting Drupal to be a one stop shop that anyone off the street can build a complex site with would put you and every other boutique shop out of business. We should all feel fortunate there will always be work for us advancing the project.

by greg.harvey on Fri, 28/08/2009 - 20:27

I was initially surprised by Claudio's blog post, hence me writing this one, so I'm really pleased he came here and went in to more detail. As you say, his clarification makes total sense and really explains why the selection of Drupal is creating an issue for his business. I wouldn't say his specific issue illustrates a problem for Drupal itself though. But that's my opinion.

Your analogy is a good one, btw. Thanks. =)

by catch on Sun, 30/08/2009 - 16:19

"It's a big fork in the road for Drupal and a business decision with huge implications. " (and etc.)

"more competitive"

"I don't have an anti-developer bias; it's the cruel economics of the industry. As margins get smaller, we're looking to squeeze what little profit we can, wherever we can."

Drupal is a community project.

Your post has nothing to do about designers getting involved in the Drupal community. It has to do with you wanting to put out sites with high margins for your company, using a tool that thousands of people develop for free, without hiring any of them to customize code for you when you try to build complex, specific, sites with it.

And then you want to tell those people, who are doing all this work for free, which you use every day, that they should go out of their way to make it work better for you, as a small business owner, compared to all the other users out there (whether they're volunteers trying to build sites for organisations with no budget or $500,000 dollar sites their interests probably conflict with yours), and that if they don't, then you'll go use some other CMS. Feel free.

So is 'designers vs. developers' actually 'small business owners' vs. workers?

by greg.harvey on Sun, 30/08/2009 - 19:52

Though I largely agree with what you're saying, please remember not all small business owners are squeezing profit out of Drupal - in fact, most probably aren't. My company is a small business based entirely on Drupal and we contribute back with every website we do (modules, patches, testing, etc.) and we say what we contributed in our showcase - take a look at an example (contributions is at the bottom):

Drupal *is* my business. Upsetting the workers would be very counter-productive! =)

by IceCreamYou on Fri, 28/08/2009 - 23:16

I've felt this way about the supposed "divide" too for a long time but haven't found a good way to express it. I think this article has done a great job of saying what I wanted to. :)

As far as whether Drupal can be a non-developer tool: well, yeah. Drupal is never going to be easy -- nothing that big and powerful and flexible could ever be. But if you care enough and you know what Google is, it's really not that hard to pick up Drupal from the UI after you've used it for a short while. Now, if you're talking about PHP, that's an entirely different story -- and some things just *have* to be done in PHP. Drupal -- especially Drupal 7 -- makes it quite easy to avoid PHP in theming, and you don't even have to go there at all if you're really just talking about the pure design level. But if you want to change the actual content that's being displayed (as opposed to where it's showing up and what it looks like) then that's quite a different level, and you're going to have to use PHP to do it. That's simply unavoidable.

by Joachim on Mon, 05/10/2009 - 11:54

Judging from my issue queues, modulist is not alone.
I get a lot of support requests and bug reports from people who HAVE build ambitious sites with Drupal, but get stuck when things go wrong.

by Club Penguin Cheats on Mon, 18/01/2010 - 08:19

While you say criticism would have been valid a year ago, I'd argue that you are talking about the future, and it hopefully won't be valid in a year.
Disclaimer: personally I never had a problem with drupals template layer, I loved it right from the start. But probably I am quite a geeky person, not a "real" Designer.

Post new comment

© 2010 Greg Harvey. Drupal theme by Kiwi Themes.