Last weekend, MIT was host to a somewhat unusual Drupal event:

Design4Drupal, where some 160 designers and interested developers gathered to talk about designing and theming for Drupal.

The Frank Gehry-designed Ray and Maria Stata Center was somehow appropriate to house a camp focused on Drupal design and theming, which often can feel like an adventure through unexpected curves, angles and walls.

This was one of a series of planned events to change that.

From the start, you could tell that this was an event different from other DrupalCamps and DrupalCons. For one, nearly all of us attending are designers. The percentage of women attendees was highest of any Drupal event I know of. And the energy was all about the design side of Drupal.

Most of the sessions fell into one of two general topic areas:

1. How to theme for Drupal as it is; and
2. How to make Drupal easier and better for theming and design.

Both topics are about beauty: the beauty of a successfully executed design, and the beauty of clean mark-up, clean css, clean output. For me, the greatest excitement came from seeing three different endeavors come together in a synergistic way.

Studio + Skinr + 960 = beauty inside and out

One of the wonderful aspects of working in open source is that you often find unexpected opportunities for collaboration and coordination of efforts to make the open source project better. This seems to have happened at Design for Drupal, as people weighed the exciting possibilities of the Studio theme, developed by our own Al Steffen and Matt Tucker, the Skinr module and the 960 theme.

Studio theme streamlines preprocess

Matt Tucker pulled together overnight a presentation on the Studio theme (that he and Al Steffen recently released), which got some buzz the day before in Jacine Rodriguez's presentation on the Skinr module (see below).

One thing that Studio does so elegantly is provide a method for handling attributes. As Matt Tucker said in his presentation, it's crazy to have to edit .tpl files just to add a class to something. It's especially crazy when you have 15 or 20 variant .tpl files for something such as nodes. To add a class, you have to go in and edit each and every .tpl file. It doesn't need to be that hard.

Skinr module's GUI for theming

I missed Jacine's presentation on the Skinr module, but the buzz coming out of it was palpable. There was no question that people had seen something very exciting to make modifying and customizing mark-up every easy to do.

960 grid system on Drupal

Nathan Smith, creator of the 960 grid system, did a fabulous presentation on how his prototyping system can make the flow from design to implementation easy, balanced and, yes, beautiful.

Then Todd Nienkerk presented his an implementation of the 960 grid into within a Drupal theme that was developed by Joon Park (aka "dvessel") and is co-maintained by Todd. [Edited for accuracy. Thanks, Todd!]

Three great tastes that taste great together

The potential of the idea of using NineSixty as a subtheme of Studio is intriguing. Such an approach would afford the benefits of both. (Currently, however, one would have to either hack or fork NineSixty to make it work.)

Adding Skinr promises to making design and theming work even easier.

Patching Drupal core

Some of the efforts at Design4Drupal were centered around improving Drupal's html output to make it easier to theme. Yes, contrary to what some developers seem to believe, it is possible to have too much mark-up -- way way way too much. Extra divs, spans, boatloads of classes and IDs, all that go way beyond what is necessary to target a particular element and can actually make it harder to do theming. Cascading stylesheets cascade.

There has been some push-back on the clean-html effort, so I'd like to offer a very rough analogy:

If Drupal's output standards were applied to PHP coding standards, I can only imagine the heated debate we'd be seeing in the Drupal development email list – that is, if any developers stuck around.

(See Moshe Weitzman's post discussing an aspect of this problem.)

We can do better in the html output. Just because Drupal is a complex CMS and framework doesn't mean the HTML has to be complex. "ID and classitis", as Moshe calls it, is just not necessary.

Let me be clear: This is not need to be an either/or thing. Sure, themers will often need a bit of specific mark-up to be able to target specific elements. But only just enough. Extra stuff just starts to get in the way. Not only that, it's usually un-semantic.

And just wait until we start throwing RDFa markup on top of it all!

Because of theme inheritance, extra-granular HTML markup with extra-just-to-be-sure classes and IDs can be generated in a base theme. I hope the voices of HTML and CSS expertise are not ignored or dismissed. Theming -- what is often called "front-end development" -- is not just an art, it's a craft, and at the heart of that craft are HTML and CSS. We live and breathe this stuff. Our voices matter.

Patches in the queue

• Moshe Weizman, one of just a few Drupal developers who attended Design4Drupal, has already rolled a patch to Drupal 7 core to implement a piece of how Studio handles attributes handling.
• Morten posted another clean-up item: removing divs from inside of forms.
• Another theme-related issues looking for some loving attention, posted by John Albin, is: Add full theme inheritance and settings defaults to .info files.
• To help the development process on Drupal.org focus more on markup, there's now an issue, close to being committed as I write this, to add "needs markup review" or something similar as a state option for issues in the issue queues.

And these are in addition to some exciting efforts pre-dating the camp:

• Allow more granular theming of drupal_render'ed elements, which is committed and now ready for some documentation work including expert review by some "#d4d people".
• Update and polish default page.tpl.php and associated css has been committed already.
  Update and Polish Node Template Output is looking for some love.
• An entire tag for tpl-refresh.

All these are very encouraging, positive developments in the effort of making Drupal markup beautiful and more themer-friendly.

Making contributing themes easier

On another front, this week, ceardach started a new module project, Simple Committer:

The initial goal of this module is to simplify the process of committing a theme to Drupal's CVS. For a HTML/CSSer, CVS is too much of a barrier for contributing new projects, and we would like to lower that barrier as much as possible.

During Design 4 Drupal, we had discussed that we could create a means to allow a user to upload a zipped file and it would automatically (or manually if we need to....) commit the contents of the file to Drupal's CVS.

We should keep the development path open, and plan a long term goal that is not CVS, Drupal and theme specific. For the first 30 days, we can hard code Drupal/CVS, but keep in mind during our development that we'll eventually want to make this flexible so the project can grow with ease.

This idea was given voice by Jay Batson of Acquia [disclosure: pingVision is an Acquia partner] in his second-day keynote as part of an effort to make it easier for themers not familiar or comfortable with CVS to contribute their work to the community. This was part of a larger vision he shared:

A Drupal designer community site

Designers as a rule tend to be different personality types than developers. For one thing, designers strive to create unique, one-off works, not designs to be used and reused on all kinds of sites. For the most part, designers work alone and don't collaborate on design work (though the best are open to collaborative feeedback and constructive criticism). And, almost to a rule, designers are not comfortable in the programming world. A designer may be quite comfortable working with (x)html and CSS, sure, but PHP? SQL? Not likely.

Jay's idea is to foment a constructive, nurturing community space where Drupal designers can talk about design, share comps of what they're working on, discuss useful design tools and approaches, debate techniques, and generally help each other as designers.

Where this community ends up living -- if it happens -- was left open last weekend, but today Jay announced the launch of http://design.acquia.com, which trumpets "Drupal is Beautiful!".

Jay points out some of the challenges designers at Design4Drupal identified:

• A really, really well done, useful, base theme in core. (But there is debate about what it should contain - all possible CSS, or none?)
• When displaying a base theme (on Drupal.org), indicate the sub-themes derived from the base theme (and vice-versa). (Can people just start to do this in the description of the theme, until it gets automated, please?)
• ID & class adding facility per menu item (currently in queue)
• Put the skinr project - or something like it - into D7 core. There was also some growing affection for the Studio theme pack
• If Drupal emits markup, it should be themable. (This, apparently, isn't always the case now.)
• Drupal.org has a security team, and an ops team. Should there be a design team? What would its authority / charter be?
• A way to mark a contrib issue as having a design problem - not just a "user experience" problem (which is actually a completely different thing in the eyes of designers.) (This involves a change to the Project module.)
• Guidelines for developers on when to do X with design / output to make the lives of designers (who have to deal with a module's output) easier
• Modules should list what markup it is going to emit that needs styled. Preferably list this somewhere _not_ in the module code - e.g. on the module's config page, or ..., so that designers don't need to shift into command line mode to discover this info.
• For every module, should there be a description of relevant design info or assumptions?
• How do we get a critical mass behind making all these changes? Do it on d.o? The systems aren't set up there well, but there is where coders (who may need to make changes) live. Do we create "community" among designers outside of d.o where we can change and modify systems quickly? Does this Balkanize efforts, or accelerate them?

I find the idea compelling.

All volunteer effort

Huge piles of thanks and hugs go out to Susan McPhee, who was at the heart of organizing this event, Morten, who has been championing the designer perspective in the Drupal community, and the fabulous D4D sponsors.

More:

on Design4Drupal

• Twitter search #d4d
• Groups.Drupal.org online community
• Jake "himerus" Strawn's post on Design 4 Drupal
• Matt Farina's write-up.

on IRC

Also check out the IRC chatroom #drupal-design on irc.freenode.net.

on UX

And all this is in addition to the Drupal 7 usability improvements being spearheaded by Mark Boulton and Leisa Reichelt. A UX sprint is about to happen in Utrecht, The Netherlands. All over the world, Drupal's design is getting all kinds of love and attention.

• Laura's blog
• 
• 
• 
• 
• 
• 
• 
•