Drupal

It seems the issue of a lack of good available themes for Drupal has really come to the forefront this week. Not only have Todd Nienkerk, from Four Kitchens, posted about the problem and Morten posted a CVS Haiku but, we have lost countless hours in Design for Drupal meetings and IRC talking about this. One thing seems for sure. As Leisa Reichelt points out, the current drupal.org setup to contribute a theme has a high barrier to entry.

It's time for the Drupal web designers and front end developers to have their own home. This is the message coming across loud and clear at the moment.

Drupal.org was built for back end developers, programmers, and the community at that time. Over the years it was architected around those users and their needs to build a great product. But, times have changed and we have users with different needs. One group looking for their own place and set of tool is the web designers and front end developers. It's time to build it.

Back at Drupalcon DC we started to talk about what the need would be. We started a group on groups.drupal.org to get the conversation going. But, the groups system wasn't really built around the needs of the design for drupalers. It grew quickly but became stagnant. What was really needed was 2 things. A project management tool to manage the tasks of the group and a home built specifically for front end drupalers.

The Drupal ecosystem has created a new title and job you don't find elsewhere. That job is of a themer. The name is built out of the Drupal theme subsystem. When we have had discussions regarding who the theme system should be built for or when we have talked about who the design for drupal movement is for the discussion has often turned to a conversation discussing a themer vs. designer. The problem is, for the theme system there is a better target than either of these and one the web development community at large will understand.

For many years the Drupal core development process has served us well. With Dries and a co-maintainer committing the changes of the community we have crafted a product we love and hate to use and a community we are involved with. But, the success of Drupal is stressing this 2-tiered development system. After talking to numerous leaders in the community here are a few suggestions as to how we can scale this system and relieve some of the stress for Drupal 8.

The Strain

The Drupal community has grown in size and the Drupal core package has grown in size and complexity. For anyone now sure what I mean just download Drupal 7 and compare it to Drupal 5 or 6. In many ways I think all this new stuff in Drupal 7 is good. But, we now have two big stresses.

My old Drupal core development workflow revolved around CVS. Anytime I'd want to work on a new feature I'd do a CVS checkout of Drupal core and start working on the new feature. If I, or someone else, was working on 2 features that overlapped in code I would have to deal with massive conflict resolving or just have to wait until the other feature was committed or abandoned. Oh, and I had to be connected to the Internet to grab a new CVS checkout. That all changed when I switched to Bazaar for my core development work.

Some Of What I Can Do With Bazaar

Bazaar, a distributed version control system, let's me do a lot of things that simply can't be done with CVS or SVN. Here's a short and incomplete list:

• I don't need to be connected to the Internet to create new feature branches.
• Merges are much better making them useful. That makes branches cheap, easy, and useful.
• I can make branches of other feature branches allowing me to layer patches and issues.
• Did I mention merges are better. This means a lot less conflicts to deal with.

How do you react when your pet project is criticized? How about when a project you use and love is criticized? When it's the same criticism you've heard over and over you and are tired of hearing it? That's happened yesterday to the Drupal Views project when a tweet sent out of frustration turned into a swarm of tweets, IRC conversations, and back room talk.

Every so often someone points to the markup generated by the Drupal Views modules and calls it ugly. This seems come up every so often in the forums, issue queues, blog posts, and on twitter. Most of the time this is where the conversation turns a bit ugly. Since this conversation has been had many times the people who are involved are a bit tired of explaining what's going on to someone new and to many Views is their baby and it was just called ugly. So, let me take a shot at explaining why Views markup is the way it is, why that's good for some, and what you can do about it if you don't like it.

The Deal With Views Markup

The markup from Views has to be very flexible out of the box. It's going to be used by a lot of people to do a lot of different things. So, the markup provides spans, divs, and classes for almost every case you'd want to style. If you are someone who lives in CSS and loves classes and separation of everything it's there for you. There is a certain group of designers that want this and they have been vocal and are, for the most part, happy with the markup.

Can't Make Everyone Happy

As the saying goes, you can't make everyone happy all the time. Having lots of spans, divs, classes and other forms of markup is directly opposed to small concise markup others love. You can't have both out of the box and what Views picked is actually easier for new people to pick up.

In Drupal to alter the output you need to know how the theming system works and how to override the default markup. Since Views provides lots of markup many people can learn to style the output without needing to know how to alter the markup output of views. It saves them from a layer of complexity.

Having Markup Your Way

If you are a markup purist and want to change the markup output by Views it's there for you to change. Views uses the templating system provided by Drupal and has a display plugin system of it's own. With the templating system you can override all of the markup provided by Views and replace it with your own. It's almost as simple as copying the Views template files into your theme and altering or replacing them.

The Drupal Design Camp in Boston this past weekend was fantastic. Having the event at the MIT Stata Center, a building that looks like it's right our of a Dr. Seuss book, was a perfect place for a design event. With well over 150 people, loads of fantastic sessions, and ideas for improving the tools and community designers and themers have the camp was a roaring success.

Photo by Jeff Eaton. Everyone is pointing at Morten.

Most of the shared Drupal themes aren't very good and there aren't very many commercial ones. That's what a study shared by Jay Batson pointed out. Jay went on to propose some steps we could take to court better design in the Drupal community. While he made some important points, there is one important point that was overlooked. The issue of crediting designers for their work.

Mark Boulton and Leisa Reichelt have suggest drupal provide inline editing in the interface. This is a fantastic idea and one I would love to see in drupal. But, (I hate this part) inline editing in drupal is a difficult feature to add. So, before everyone wonders whey we don't offer it or why it's going to take some work let's look at why this is hard.