Home / Beautiful Drupal - growing the designer community and its impact

Beautiful Drupal - growing the designer community and its impact

I'm happy to have seen the good response to my "What shall we do about themes?" post. I'm particularly glad to see a bunch of self-described designers participating, and to see the thoughtfulness of the comments.

From the 50+ comments, a few consistent messages emerged (no editorial pen here; just consolidating / summarizing):

  • Designers need a non-CVS way to submit themes. Drumbeat. Drumbeat. Drumbeat. (Of course, this doesn't solve the problem of how we actually do version control on those themes, but hey - it's a clear message.)
  • "Default" themes need to be linked to a purpose, e.g. identified use cases (i.e. intranet, ...), and either leverage install profiles, or (it sounds like a preference for...) the patterns project (along with a request for a tool to build same).
    • Some desired pre-defined things: blog, magazine (media generally?), forum site, eCommerce, gallery, basic brochure-ware business site.
  • Provide theme listings (on d.o, presumably) with a way to incorporate / display sub-themes derived from a base theme
  • Tools for Dreamweaver to assist in development of Drupal themes (I note that I've seen one; it hasn't rocked my world, but it helps.)
  • A "Drupal layout engine" (panels on steriods), plus block theming. (See also (orthogonally?) Gabor's blog).
  • Feelings on both sides of the argument re: the notion of encouraging Premium Themers. And a notation that if such a community does grow, those themes can't "live on" d.o, due to licensing or other conflicts.
  • More cleanly separate content from theming during page-building - e.g. Drupal needs to construct its content during page-building in a way that is more (semantically?) structured, and have a more rules-based (e.g. XSLT) method to actually create output. (This has the side-benefit of being able to output content several ways, e.g. web services, expose data to Yahoo search monkey / semantic search engines, ....)
  • RSS feed for new themes - both commercial and GPL
  • A(nother?) base / starting theme that's a bit different in approach (vs. Zen, ...): One with all the theming settings defined, but "minimally" themed so the designer can make it look as they wish.
  • Separate front-end and admin layouts. (I think this, however, may be better discussed under the D7UX redesign context.
  • Different orientation to documentation. Instead of a theming handbook for developers, a handbook targeted at designers to teach them to develop themes for Drupal.
  • Less concern than I might have thought about the requirement for designers to learn a little PHP - though the "Drupal learning curve" remains present.
  • A showcase of "what Drupal is for" - how it's being used, some of the designs that have been created for it, etc.
  • A repository of little re-usable snippets for theme designers
  • Improved documentation on d.o - eliminate need to muck through D5 to find D6 details, eliminate wading through comments, etc.

In the interim since that post, I've seen several things that seem to be addressing some of these desires:

  • Tools for Dreamweaver. Chris Charlton posted a link on groups.drupal.org to a page on Adobe.com that gives a tutorial on how to use his Dreamweaver Drupal Theme Starter software.
  • Base themes. There seems to be a consistent drumbeat of new "base themes" on d.o, each approaching the issue different. Today, for instance, Starkish appeared, claiming to be a derivative of Stark but with no CSS at all. Morten also has the mothership theme he's working on. Maybe we need a common theme with layers / subthemes that can address the various approaches?
  • Re-usable snippets. It's interesting to see that this such thing has already been on drupal.org since 2008; is it that these aren't findable, or useful, or simply not what people were looking for? I'm not sure what the answer it, but a non-d.o alternative has now appeared. (Is it that simply organizing in book fashion wasn't enough of a way to find them, and if so does / could the new Drupal faceted search solve that problem?)

However, the occasional blog post in Acquia's general blog isn't going to be the way to systematically address all these things. We'll need another place to do it, and people showing up with high-bandwidth interactions to get stuff done.

One good place to start: This weekend's Design4Drupal Camp. I proposed a session for this Camp to talk about this topic. I'm honored that the organizers felt it was an interesting enough topic to make it the Keynote on Sunday. (Thanks, guys!) If you've got the time, and transport, to get here this weekend, and care about this topic, come to the Camp, and let's get something done.

I'm hoping we can come from that with an actionable list of things we - Acquia and the designer community - can do. My next post will come after D4D, with my list of things I know I & we at Acquia can do.

Comments

Posted on by JohnAlbin (not verified).

I've got a couple points to quibble with…

A(nother?) base / starting theme that's a bit different in approach (vs. Zen, ...): One with all the theming settings defined, but "minimally" themed so the designer can make it look as they wish.

I think you misunderstood this comment. They wanted a default theme (emphasis mine) that implemented a minimal design with a bunch of theme settings. That's exactly what Zen does (as Duvian pointed out). The difference being Zen is a contrib theme and he seemed to want a default theme in core. That's exactly what we are trying to do with D7's default markup and Stark.

Also, the Starkish theme isn't “Stark but with no CSS at all”. The Starkish project page says its like Stark in that it contains no CSS. But Starkish adds tab styling, page and node templates and a template.php file. So its kind of half-way between Stark and Zen.

And now on to the non-quibbly bits… :-)

Personally, I'm glad to see all the new base themes. If you’re not using Zen, you should be using some base theme. I'm also starting to see a ton of Zen sub-themes pop up in contrib which says to me that people are really starting to see the benefits of a base theme/sub-theme combination (something I've been promoting since January 2008).

In regards to the Theme documentation, I've got an extensive outline for new tutorial-based Theme documentation. I've been waiting for Addi to post the new Documentation road map, which she just did, to discuss it with the docs team. There's a docs IRC meetup this Tuesday where I plan to bring it up if I can fit it into the agenda.

Also, I think the “Reusable snippets” docs need to be renamed and re-organized as a Theming FAQ. How do I do X? Oh, I use this snippet. Here's a D5 version and here's a D6 version.

Finally, like Joon Park, who wrote the original D6 Theme Guide, I think it was a mistake to combine the D5 and D6 theme "guides".

One problem is that the D5 "guide" was a mish-mash of barely-organized stuff. And the D6 guide was a structured reference guide. The D6 theme guide wasn't intended to be the end-all and be-all of D6 theming docs. It should have remained as is, a reference guide. And we should have implemented additional D6 documentation earlier.

The second problem is that D5 and D6 theming is so different that combining them gets confusing because there are whole sections of the guide that only apply to D5 or to D6. I had someone in IRC asking me why his _phptemplate_variables() function wasn't working in his D6 theme. Docs FAIL.

Posted on by bsmith (not verified).

I don't hear much about Blueprint (http://drupal.org/project/b lueprint), I was curious about its merits as opposed to Zen, does anyone have a comparison? We are trying to choose our tool for going forward on quite a few sites.

Posted on by Jay Batson.

Actually, there's much more excitement about the 960 grid project in Drupal. If you don't know about the 960 grid system, you should take the time to look at it. The creator of it wrote a blog post discussing it, and speaks a bit about Blueprint in the post.

Posted on by Steve Krueger (not verified).

I'll touch on Base themes considering I just noticed the Starkish theme was heavily based on Basic (which I co-maintain). Over the past few months, if not the past year, I've felt a massive influx of "base" themes being contributed claiming to make it easy for themers to get started in Drupal front-end dev. Although most base themes achieve their purpose, each have their own unique approach in getting to that point.

I've been troubled with this problem as well since each project has it's own unique quirks that need to be tweaked to fit the guidelines so it's a matter of:

  • Provide endless possibilities and functionality for the themer to add to their project's front-end (resulting in code bloat and/or removal of code if not needed)
  • Provide a minimal framework and clean slate (results in the themer researching for functionality if they need to add. Another reason for proper documentation/code snippets)

An alternative solution would be to have a minimalistic, no CSS/plain markup, theme with various modular sub-themes which allow the themer to switch or play around with depending on their project guidelines or requirements. Once again, this theme would have biased HTML markup but would allow other themers to develop sub-themes around it.

Steve Krueger
Co-Founder

The Jibe Multimedia

Posted on by rahulraikwar24 (not verified).

Both premium and free drupal themes have their own advantages and disadvantages.
Before deciding in favor of a free theme, have a look at the following premium drupal themes providers. And, who knows, maybe you will find the prices charged by the company worthy of the design and support package you get for your money.