Overhauling the Company Website
Over the summer, we overhauled the Raizlabs website. It was originally developed in 2001 using Frontpage (yeah, I know). The site had accumulated a number of HTML files, a collection of ASP files, a number of blogs for personal and company use, some newsletters and assorted client scripts.
In re-designing the site, I knew I wanted a content management system. We evaluated Joomla, Drupal, WordPress, and custom solutions. Joomla and Drupal looked promising. WordPress was a good blog system but not designed for larger site structures. We started implementing a Joomla site and were perhaps a week into the process when we decided to change paths and go with Drupal.
The Joomla front-end experience is easier to get started with but makes it difficult to set up and interact with content quickly. The Joomla system had a lot of out-of-the-box features, but it required too many steps to do simple things.
The Drupal user experience was, by contrast, amazingly stark. After downloading Drupal, I couldn’t figure out how you could possibly build a site using it. It later became clear that the real value of Drupal was with its module system.
Critical flaw: Make sure things work out of the box. Batteries should be included.
While Drupal is truly a powerful system, this is easy to overlook. The default install that you get from Drupal.org has nothing included. It’s like getting a car engine without the seats.
Dries: Oh, you want seats in your car? There’s a module for that.
There are more complete solutions and downloads available from providers like Acquia, but this is not obvious. The modules are the most critical part of Drupal, and if you’re not familiar with modules, it’s not clear what modules you need. They have many names that are also not obvious: CCK, Views, ImageCache, AdvancedHelp, Devel, Mollom, TaxonomyMenu.
Too much flexibility can cause problems.
Everything in Drupal is customizable. Not only can you customize your content, but the system also makes it very easy to customize the admin structure, menus, and commands however you want. It’s so easy to customize the administrative interface that it’s easy to get into a state where nothing works.
The admin interface should be designed to be quick and efficient for creating and editing content. Some amount of customization is great, but the system as it stands is overly abstract, making it easy to get into trouble.
Be good at certain things. Don’t try to be good at everything.
When evaluating Drupal, it seemed that it has support for blogs, forums, discussions, groups, and pretty much everything else. It was only later that we decided that even though Drupal could do these things, it couldn’t do them well. For instance, Drupal has a blog module, but it’s so much harder to use than WordPress that there’s really no reason to fight Drupal to do what you want. It’s easier to integrate WordPress. The same story for PHPBB and the Drupal Advanced Forum module. As a content management system, Drupal should make it easier to integrate these external products. Instead, they try to re-invent these components, and it doesn’t work. Drupal is a good content management system but it’s not a good blog and it’s not a great forum.
More than anything, I wish Drupal would be a better cross-product citizen for other PHP projects. For example: Gallery, PHPBB, WordPress, ZenCart, etc. Plugging in other stuff that’s not part of Drupal should be encouraged. The attitude that it has to be Drupal for everything is simply not practical.
Views and CCK
Views and CCK allow you to create all sorts of queries onto your content and allow you to customize the fields of content that you collect. It’s basically like creating your own database columns for your content. The problem is that you can’t just take someone else’s database; you have to build them yourself. If I want to set up a bunch of content and views to create a little client database, I have to start from scratch. It would be so much easier to take a good solution as a starting point and customize it to specific needs.
There should be a number of popular and useful views that should be included. I shouldn’t have to create my own “random post of the day” or “most popular articles”; these should be canned views.
Modules and Blocks
A module encompasses a portion of functionality. It’s actually not ‘modular’ in that sense of the word. It’s more like a plug-in that extends the functionality. A block is a component that gets shown on a page.
The block model assumes that you have one core site template and that blocks are either shown or hidden on each page. As your site grows, you have to have rather complex rules for when certain blocks are shown and when they are hidden. The UI to customize this show/hide functionality is rather broken. Rather than having page templates with visual drag-drop interfaces for multiple pages, you have to manually specify all your blocks and pages within one block template page.
I wish I could define a site structure, then drag/drop content and widgets to each page in the site structure.
Terminology
With any content management system, there’s a certain amount of learning that has to happen. For some reason, content systems don’t use terminology that is used when designing a website. They use their own abstract terms: Page, Story, Book. If you take these terms literally, you may expect that stories compose a book and a page is one page of a longer story. This isn’t how it works.
Drupal uses the term “Menu” for everything. Even if certain things are tabs, other things are trees, and still others are actually menus.
Making things practical, not just possible.
Drupal has the ability to do a lot of things, but in many cases, these things are possible, not practical. Solutions for certain tasks are not ‘turn-key’; they involve a lot of customization and configuration. As a simple example, I wanted to create a special “clients-only” section on my site. Reading the docs and forums, there were at least 10 different approaches for how to solve this problem. Some solutions suggested advanced permission modules, others suggested Organic Groups, still others suggested a CCK/Views approach. This seems like such a basic security scenario that there should be a simple solution to make this work (there was not).
I’m sure this problem has been solved many times over using Drupal; however, there is no current way for people to share these “solution recipes” in a way that I can download them and have things just work.
Long-term experience
I think Drupal’s user experience has a lot of potential, and I’m encouraged by the efforts I’ve read about for the Drupal 7 release. Focus on the user experience is really the thing that’s going to make this not just a powerful system but a practical one. I’m looking forward to it.