Nica Lorbor, from Chapter Three, has a great post on their highly optimized Drupal design process. In the article, Nica shows how they start from a Drupal template that has roughly 25 common named elements (some native Drupal, some not) that can be styled according client specifications. A specialized Fireworks template calls out these elements and helps map them to a mockup to facilitate conversation between the designer and the developer. This creates a common language that binds the design to the code that the developer needs to work on. This also probably quickly identifies visual design elements that are not part of the normal Drupal/Chapter Three build, which need special consideration for estimation and budgeting.

I think the efficiency of this process supports my philosophy that you should work with a partner that specializes in the CMS that you intend to implement. Chapter Three didn’t invent this methodology for their first Drupal implementation. I am sure that it evolved over time. It also speaks to the efficiency of designing with the platform in mind. With this process, everybody on the project (from designers to developers) understands what is going to be easy and what is going to be hard. Designers are guided towards concepts that are more efficient to build. Yes, you could build any design on Drupal, but that doesn’t mean that you should. With some site designs, you will be fighting the natural tendencies of the platform: increasing both the implementation and maintenance costs.

I should probably make the point here that I am not implying that all Drupal sites (or sites from any other CMS) look alike – particularly to the untrained eye. Nearly all of what the casual site visitor notices (font, palette, page layout, buttons, etc.) is totally customizable in Drupal and any other CMS platform. Guessing what CMS was used involves much more subtle characteristics that you wouldn’t notice unless you worked with the platform extensively.

This all raises a chicken and egg problem that I have discussed before. If the product influences the design and the design defines the requirements that drive the product selection, where do you start? As I mentioned in “When it is not all about the software,” the key is knowing enough about your requirements to define a short list of options that you can evaluate on more subjective levels (such as aspects of design).

Nadav Schreibman just commented on my post “Is Drupal the right platform for whitehouse.gov?” to say that Recovery.gov is now running on Sharepoint. I was pretty shocked when I read the article and had to check the source on the site. Sure enough, I am seeing Sharepoint HTML in all of its postback glory.

The referenced article from Oh My Gov talks about how the Recovery.gov needed a more portal-like framework. Both Drupal and Sharepoint can be described as development frameworks. Drupal leans more towards being a CMS product (with strong capabilities for developing content) while Sharepoint is more of a portal (with strong capabilities for pulling content and data from other sources). It seems like Recovery.gov, with it’s mandate to expose where recovery money is being spent, needed more portal and less CMS. This was an expensive change — the redesign project cost $18 Million, which may not be a lot of money in government spending terms but is more than most of my clients have lying around. Thanks Nadav for the tip!

By now, most people have heard that whitehouse.gov has been migrated over to Drupal. Apparently, the administration has built a level of comfort with the platform with its experience using it for recovery.gov. While the Drupal community is doing high fives all around and equating this with being the most powerful CMS in the free world, I wouldn’t go that far. I would say that Drupal is a very good choice for powering the kind of website that the Obama administration is trying to foster: content rich, news oriented, faceted, and populist.

Apparently, Slate Magazine’s Chris Wilson wasn’t so generous with his critique of the choice. I discovered the Slate article by reading Conor McNamara’s excellent post
“Drupal misrepresented by Chris Wilson of slate.com.” In my opinion, Conor’s responses to Wilson’s points are spot-on. Some of Wilson’s criticisms reflect configuration choices, not limitations of the platform (like not being able to add Javascript to a content objects. It’s a bad idea to allow this by the way.). Slate.fr uses Drupal and the Today’s Pictures section of Slate.com is Drupal powered. It seems like Chris has just enough knowledge to sound ignorant. Readers of my reports know that I can get critical of technologies. But whenever I criticize, I make sure to do my research because I know that I am going to get attacked by defenders of that technology. Chris is about to learn this lesson. If Slate.com’s commenting system wasn’t so bad, he would learn even faster.

Recently there has been a lot of chatter about friction between the designers and developers within the Drupal community (see posts by Earl Miles and Greg Harvey). The Drupal community is huge and dynamic and is bound to have various skirmishes as members with different backgrounds and needs try to get what they want out of the platform. But I didn’t really expect that the divide would be along the lines of developers and designers. I thought it would be between high-end adopters (like media companies) and low-end adopters (like individuals, small companies, and non-profits that make up the bulk of the Drupal community). Or it could have been between people who see Drupal as a business application and those who see it as a development framework.

The Drupal community is keenly aware of the importance of usability and has done a lot of work to identify issues. With the upcoming version 7 release (code freeze any day now), Drupal upped their usability efforts by bringing in some high profile designers to participate. The transition from being developer-dominated to having a more even balance between design and development is important for the Drupal platform as a business application. Mark Boulton and Leisa Reichelt conducted a very open process to incorporate peoples design ideas and feedback. Now that I think of it, this rift between new ideas and the old Drupal guard was pretty inevitable. This kind of transition is not easy. Both sides need to adapt. I don’t think there will ever be total harmony between pure developers and pure designers but I do think the project can achieve a healthy level of tension that improves the software.

Readers of Drupal for Publishers know that Drupal has been very successful in the small to medium newspaper market. In fact, the Newspapers on Drupal group is assembling a list of modules commonly used by newspapers. This effort has been going on for some time but there has been renewed energy because the older list was oriented around the outdated 5.x series of Drupal.

There is also a Drupal distribution for newspapers called ProsePoint that bundles Drupal, many of the modules listed by the Newspapers on Drupal Group, and some other third party code. I think that creating vertical specific distributions of software is a neat idea and there are lots of great examples. Gartner has been talking about CEVAs (Content Enabled Vertical Applications) for years but it is unlikely that their commercial software vendor audience will be as quick to capitalize on the idea as open source communities.

From an open source community perspective, vertical distros introduces interesting dynamics. On the one hand, these groups definitely strengthen the bond within segments of the community who can benefit greatly by collaborating with peers with very similar needs. On the other hand, specialization of community segments requires strong central leadership to maintain common ground and prevent the different groups from becoming too self absorbed and self interested. I don’t think this is a problem in the Drupal world because leaders in the Newspapers on Drupal community seem to have a very strong belief in and commitment to the Drupal project as a whole. For now, at least, this very active constituency seems to be nothing but a positive force in the greater Drupal movement.