Drupal Theme Development Turned Upside Down (part 1 of 2)
In Star Trek II: The Wrath of Khan, there is rather odd scene (actually, that movie is one long odd scene...) where the audience is introduced to "the genesis device". At one point during that scene Spock notes that "it's a timeless truth that it has always been easier to destroy than to create."
However, sharing that line from Star Trek is not entirely the reason why I am writing this post. nYou see Spock's somewhat haughty observation fired a synapse that gave birth to this post, and thus it became a "blog-worthy" introduction.
The obvious fact that destruction is easier than creation has some very interesting implications for drupal themes. Riddle me this: What's easier? adding code, or deleting it? How often have you found yourself digging through the stylesheets of past projects to harvest sets of styles that you find yourself needing to use over and over again? Why don't we make those solutions we come up with part of drupal itself, instead of buried away in our hard disks? Hopefully a few of you will sense where I am going with this.
A Brief Overview of the Holy Drupal Dogmas
There is something biblical about the philosophy of Drupal, and in particular, the adherence to a few key dogmas that are evident in all parts of the platform. Some of the dogmas include:
1. The drupal core is our temple, only the most rightous of code may enter. All code that wishes to enter will be tested, by the all seeing core contributors. (for little guys like me, the thought of having Dries look over some of my coding jobs is a very scary thing)
2. The need for Future Flexibility Always Outweights the want for Flashy Functionality.
To put it another way, its as though the drupal codebase and community is a long-distance backpacker. Code and features are weight. And as any one who has done a long knows weight we carry, the more our feet will hurt, the slower we can move, and the more miserable our journey in open source development will end up being.
These dogmas, in so far as the core is concerned, are worth defending to the death. It was the stoic approach that drupal maintainers have taken that have brought it to where it is today. However, I think applying the same philosophies and dogmas to drupal themes as we have to the core, and well programming in general is -- well -- kind of wacky when you really think about it. But I'll get to why in part two of this lil' thought. First, I think a brief reflection of the current state of drupal themes is warrented.
Paintings and Cement Foundations
Thinking over the 12 or so commonly used drupal themes (let's call em' the classics), I see two patterns that I will describe with the hastily constructed labels, Painting themes, and foundation themes.
a.Paintings -- Like actual paintings, these themes are basically finished final products. I call them finished because they are often quite fragile, and are distributed as fixed width themes that work fine -- so long as you don't change any of the pixel based width values in the style sheet. They are pretty to look at -- at least from the perspective of an anonymous user who hasn't been on the web enough to spot sites that use the same stock themes as thousands of other sites. The only real advantage of paintings is the first impression they make. Or at the very least, they offer a design which doesn't interfere with any of the site's goals. Themes such as Connections, and Leaf are my favorites in this genre.
While painting-themes do indeed look smooth, they almost always shatter the secont you try to fit in 2 sidebars, or expand their width. Leaf, for example, works great -- but if you attempt to alter the width of the page it behaves much like cramcrackers secured by rubberbands.The vast majority of the "paintings" are actually ports from wordpress... thus they have a big disadvantage: they were designed for an entirely different platform, that generally serves an entirely different demograph than drupal.
Painting-themes aren't without their use. They work great for quick jobs where you just want a blog, and for it to not look terrible. However, personal blogs, or simple brochure websites aren't really an interest of mine, or the people I generally work for. And most likely, if you've read this far, you're pretty deep into drupal, so -- these themes are not for you. Now, I have a few big problems with themes of this type, but I'll get to that later.
The Foundations -- clean_slate, marvin, blue_marine, and camelion are the fab foundations many of us know inside and out. Foundation themes are very minimal, often table based, and always very white, grey, and usually an odd color for links (purple, green, but never blue?!). They are like -- well, a concrete foundation, they are flat place which you can build your web based home.
Why Neither Approach *Really* Works
Drupal's number one selling point is in the long term value. Both in terms of the amazing places the platform might come in the following years, and the savings of empowering organizations to manage their content without investing in shady ASPs that could go under at any moment, or having to write a $50.00 check to some joe who knows how to work an FTP client, and learned HTML in highschool.
Whenever I make a decision about how to appraoch a challenge on a site, one of the most important questions I ask myself is: "when I leave, will going this route increase, or decrease the amount of control they have with the site." I never go the route that will tie their hands behind their back when I'm gone. Sometimes, I actually neglect to mention those routes, because they often look good in the short term, but its a decision I know they'll regret later.
Therefore, I would never ever ever implement a wordpress-ported theme. As a matter of fact, I often receive emails from freaked out people who hired some joe to build a drupal site, and received a really bad final product. One common thing that ties these sites together is that they were based off of painting themes. Never, ever,ever deliver a website for anyone serious that uses one of those wordpress ports. Seriously, regardless of the testing you do, their fixed widths do not play well with the unpredictable behavior of modules. I know that when some old customer installs CiviCRM, and it works perfectly, they won't think of me -- but that it seems is the nature of our work. We are invisible, until something goes wrong.
As for foundation themes -- they've worked well enough, and I have no sermons warning against their evils, I merely would like to suggest a new way to look at it. My personal opinion is that these themes are generally completely 100% unsuitable out of the box for use with websites that have something to gain from uh... ... looking like they have high self esteem.
Or actually that's harsh, I look at themes everyday, so probably look fine to the vast majority of the human race that doesn't spend all waking hours in the drupal matrix. Anyways, every foundation themes is what -- 3 years old? 4 years?! Any design that old goes out of style -- even designs as simple as box_grey.
Its worth asking: why do certain themes have tenure in the drupal core? Everyone in the field knows web design fashion trends move rather fast. Crap -- Curved Slate is already out of style!
Tomorrow, I'll follow up with an idea: Approaching theme development like a sculpture, and the delete key as our chizzle. I hope to convice at least a few of you that its in everyone's best interest to stop approaching reusable themes from the foundation point of view, in which the theme provides the basic structure, and you have to build your own solutions, and instead approach themes from the marble and chizzle point of view. You start with a library of well done, bulletproof solutions and styles that are commonly needed.
The really radical argument I want to make, which I insist is worth considering, is that the drupal core should come with one base theme, and then a marble slab which is basically a morbidly bloated them that gets fatter and fatter. However, the "fat" is a giant collection of ready to go styles, template files, and other difficult development challenges that only need to be solved once. Maybe I'm nuts, but the concept just makes sense: moving towards the modularization of style elements.
I might be completely batshit crazy about this one... but as many of you probably have gathered, I've never worried too much about coming across as crazy.
Notes:
When was the last time you saw paintings and cement foundations in the same header?