When I first built a web site for my company, Now Interactive LLC, I chose a content management program called Drupal.

What I wanted was a site where I could feature products, services, clients, partners and contact information–the usual components of a corporate web site. I also wanted to blog about product management and web application design.

My first thought was to use an excellent blogging program called Wordpress.  It gives you a blogging site along with the ability to write static pages. However,  Wordpress is narrowly focused on blogging. On the home page, you see the blog, and available free templates all look like blogs. I would have to write and maintain my static pages separately and in their entirety. It became clear that I would have to customize Wordpress, which is written in PHP, and this was something I wanted to avoid.

My personal web site is a Ruby on Rails application that links to a Wordpress blogging site. The problem is that while the content management on the blogging site is user friendly and sophisticated, the content management on the Ruby on Rails side is a bit clunky. After all, the application was not written for content management but for a personal marketing campaign (which went off extremely well).

For about a solid half-day, I tried using a Ruby on Rails application that read from a Wordpress database.  The idea was that my corporate site would be written in Ruby on Rails, while the content management (editing, tagging, categorizing, and controlling revisions) would be handled by WordPress. But after struggling to get categories to display in the right order as tabs, I decided to try something else.

I had used Joomla briefly and found it counter-intuitive and complex with its notions of menus and content that might or might not actually appear in the site. A representative from OpenSourcery at InnoTech Oregon had recommended Drupal over Joomla. Sure enough, some large companies use Drupal for impressive sites. Word on the internet was that Drupal had a learning curve, but not being one to shrink from learning curves, I waded in.

Drupal was easy to install in my hosting service. I’d probably put it at 3X the effort of the (ridiculously easy) Wordpress installation. Installation of new templates was a simple matter of copying files to the server. Drupal automatically checked for updates to itself and any installed templates. It ran a daily cron job for housekeeping.

Unfortunately, I started encountering problems soon afterward.

• I struggled to understand the difference between a Page and a Story. A Page seemed like a Wordpress page--an entire page that you managed yourself and that Drupal didn't know much about. But I wanted to deal at a finer grain.  For example, I might want a page of partners but feature one of them on the home page. A Story seemed more like what I wanted, but it had funny features like automatically showing up on the front page.
• I figured out how you need to create content and then create menu entries pointing to the content. Much later, I realized you could create menu entries at the same time as the content.
• I put all my menu items in the Navigation menu, which gave me a very plain menu. I didn't realize until much later that some templates treat the Primary Links and Secondary Links with special effects.
• My triumph was figuring out how to assign stories to categories and link a category to a menu item. It involves yet another concept called a "taxonomy". This is a hierarchy of categories to which you can assign stories. A menu item can be linked to a taxonomy entry, which displays all content assigned to that entry.
• I figured out that you can order menu entries by dragging and dropping, but this is interconnected with the notion of "weight". (What does "weight" mean for a horizontal menu?) Ordering stories on a page was much harder. Eventually, I figured out it assigns an editable timestamp to each story and displays them in reverse chronological order. By assigning the appropriate date stamps, I could alter the order in which the stories were displayed. (This is called a "kludge".)
• One problem I ran into was when you clicked on a menu item, you would see the name of that menu item all over the [BLEEP] place. So if I clicked on "Partners" then the page would display "Partners" in enormous letters, and each content item would say, "Posted in Partners on April 25, 2009 3:45 PM". Of course "Partners" would not show up in the URL as you would expect. Instead, it would say, "http://www.now-interactive.net/node/15" and this was considered a "clean" URL good for search engine optimization!
• Eventually, I found a template that would not display so much [BLEEP]. Unfortunately, templates varied widely how much they could be configured, so I really just broke some less important stuff in order to fix some more important stuff.
• My friend pointed out that the menu you just selected isn't highlighted. Duh! It turns out there is some support for this, but it requires editing CSS---but not the CSS you originally installed, because Drupal has made a separate copy!
• The interface is inconsistent. For example, assigning <none> to page and story titles ensures that no title appears, but assigning <none> to a menu name gives you a menu with "<none>" prominently featured.
• There are very few good tips and hints on the internet, and what there is is sorely out-of-date.

After all this, I began to understand why people have made a business out of being Drupal consultants. Come to think of it, my last employer had run a web site on Joomla, but used a consultant for all changes. Indeed, since I couldn’t hire one, maybe I should consider being one…

Honestly, I had no real problem with any of this. You get what you pay for, and I had been amply warned of the learning curve. Furthermore, complexity is directly proportional to flexibility.

However, recently I have been approached by people who want a fairly simple web site. In many cases, they are using FrontPage and sending files to a server using FTP, but they want to do things like

• mass e-mail campaigns to drive traffic to their site
• sell an inventory of products through PayPal
• have a private area for customers or members
• do a slide show
• allow reservation of resources
• choose a site design consistent with logo colors

Drupal can certainly do all of these things and more, but it would take me a long time to set it up for these people. Furthermore, I don’t want them to have to turn to me every time they need a small change, and I don’t want to expose them to the counter-intuitive terminology and complexity of the administration interface.

In my next post, I’ll spell out what’s really needed.