Excitement, ideas and new designers' focus coming out of Design4Drupal Camp

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 implementation of the 960 grid into a Drupal theme.
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

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

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

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.

Related: 

Introducing the Studio Theme Pack

»

 
 
Home » Drupal