Drupal Vs. MovableType: Round 3

I’ve just finished installing the Kubrick template for both Drupal and MovableType. The template does a decent job of hiding the complexity inherent in these systems, and looks relatively pretty, too.

In my mind, it’s back to a dead-even horse race. The biggest drawback of Drupal was the complexity – too many widgets on the screen, so novices could get easily confused. It’s immediate benefits are LDAP authentication, and extremely flexible content types and easy publishing. Drawbacks include the mash-everything-into-one-website-with-multiple-views strategy, where it becomes difficult (impossible?) to create truly unique weblogs as part of the larger system. They all feed into the same content store, and are all displayed via the same interface.

Now, the biggest advantage of MovableType isn’t the simplicity for the end-user, but in being able to set up distinct weblogs with their own templates and groups of authors. This would be much more useful for something like a departmental website. Where Drupal squishes everything into essentially a single weblog with multiple views, MovableType creates silos of content, which can be shared (or not), and mixed (or not) as desired.

Suddenly, I’m craving a trip to IHOP, what with all the waffling I’ve been doing over this… 🙂

I’ve just finished installing the Kubrick template for both Drupal and MovableType. The template does a decent job of hiding the complexity inherent in these systems, and looks relatively pretty, too.

In my mind, it’s back to a dead-even horse race. The biggest drawback of Drupal was the complexity – too many widgets on the screen, so novices could get easily confused. It’s immediate benefits are LDAP authentication, and extremely flexible content types and easy publishing. Drawbacks include the mash-everything-into-one-website-with-multiple-views strategy, where it becomes difficult (impossible?) to create truly unique weblogs as part of the larger system. They all feed into the same content store, and are all displayed via the same interface.

Now, the biggest advantage of MovableType isn’t the simplicity for the end-user, but in being able to set up distinct weblogs with their own templates and groups of authors. This would be much more useful for something like a departmental website. Where Drupal squishes everything into essentially a single weblog with multiple views, MovableType creates silos of content, which can be shared (or not), and mixed (or not) as desired.

Suddenly, I’m craving a trip to IHOP, what with all the waffling I’ve been doing over this… 🙂

7 thoughts on “Drupal Vs. MovableType: Round 3”

  1. It sounds like you’re reaching some of the same conclusions I have about the suitability of Drupal for a multi-blog site, like a departmental site. The user interface is too complex – Drupal can do *so* many things, that an end user gets swamped with choices. And I’ve read some stuff that suggests that allowing each user to tweak and customize their blog is a much better way to get the users to buy in to the whole online community.

    Keep posting us on the results – I’m getting a lot of work done by looking over your (virtual) shoulder. ;^)

  2. Rob, good point about customizability and adoption. That’s one point where WordPress makes it so much easier – just select a template from a list. MovableType makes it quite difficult for newbies to just switch a template – you have to edit a bunch of templates (and set the parameters of the template, etc…) and know roughly what you’re doing.

    It’s extremely flexible and powerful, but has quite a learning curve. I’m hoping we can set up the Kubrick template (or some derivative of it) as the default, so all new weblogs automatically use it with no user intervention. It’s easy to set up, but takes a few steps, and that would require a LOT of support.

    Of course, Drupal appears to lack this functionality at all.

  3. There is a version of Kubrick for Drupal. End users can switch templates for their own view from a list, and there is work being done for customization per end user (as well as subdomain aliasing, so darcynorman.example.com would point to your blog, but actually be in one Drupal system).

    As well, complexity is hidden for individual end users — you turn on permissions for only the things they have access to (e.g. blog).

    I got a preview of somre really powerful new tools here at DrupalCon. The stuff I’m really excited about is a publish – subscribe module, where you can define publish and subscribe points that share content across sites. With LDAP as authetentication, this means that each user/course/department can have their own space, but also have content be pushed and/or pulled between sites.

    The share or not comments I’m a bit confused about. Drupal can have that mass of blogs, but can also (for example) have the story module as a shared blog. Plus the organic groups module, which lets you split a large

    Basically, multiple Drupal sites can be very easy to run off a single codebase (I’m not pushing Bryght here, this is standard as of 4.6, which will be hot off the presses in a few weeks) yet still allow for customization on a per site basis.

  4. Using sections.module you can have separate templates for parts of your Drupal site. Anyway, there’s no doubt that WordPress/MovableType are easier to theme as they do much less, but I do think that Drupal is relatively easier to theme if you consider the feature-set.

    Theming a blog is just making 2 pages: a listing of entries and a single entry with comments. Even for a basic blog Drupal offers much more functionality (although note that you can turn pretty much everything off if you don’t want it).

    If you sit down and take a closer look at Drupal’s theme system, you can do some pretty darn neat things with it. You might want to take a look at the presentation “Drupal theme development” which I delivered at the Drupal Conference in Brussels this weekend:

    http://www.acko.net/drupalcon

  5. There are a few easy steps to reduce the complexity of Drupal’s navigation:

    1) Enable only the modules you’re actually going to use.
    admin -> modules

    2) Give users only the permissions they need.
    admin -> user -> configure -> permissions

    3) Use the menu module to customize what menu items are available and their order.
    admin -> menus

    If you want to get really fancy, you can use Perl regular expressions to change when certain blocks. For instance, to only show a block when you’re at /admin you can use

  6. “becomes difficult (impossible?) to create truly unique weblogs as part of the larger system”

    First of all, what makes a weblog truly unique is the content, not the site theme and configuration. Then there’s a fallacy in this line of reasoning in that it’s based on how individual weblogs work, not on how Drupal facilitates community within a site of numerous blogs. I’ve been using Drupal and teaching with it for a couple of years now. People who are saying this have never experienced a community site like Drupal. Drupal creates it’s own mini-blogosphere, and in using it over MT’s multiple individual blogs, you would be encouraging students to intereact with each other.

    Features that support this:

    1) Recent posts block that aggregates the most recent comments on the site and lists them on each page.

    2) Recent blogs block (similar to above).

    3) Aggregate display of all blog posts

    4) Option to promote all blogs to the front page.

    5) Trackback autodiscovery, which would have individual blogs in the site ping each other automatically and create connections between them.

    6) Recent posts (tracker module)

    7) Buddylist module

    8) Having a shared blog on the front page (story) and individual blogs using the blog module (as Boris mentioned)

    9) One registration across multiple sites; students when logged into their blog can post comments throughout the site without need for further login.

    10) The option to create user support forums within the site, to make use of discussion forums in conjunction with weblogs.

    11) In the long term, there are features that Drupal is developing which increase community interaction. For example, there’s a lot of interest in integrating social network features such as found in orkut within Drupal. I’m not sure if MT has this, but Drupal already has avatar support, and in my experience, students really like this.

    And as far as customization, students would still have the ability to create their own blogroll (see blogroll module).

    Then there are the disadvantages of allowing too much configuration, some of which I’ve seen from administering individual blogs for people:

    1) Newbies to HTML, etc., insert blocks which break site themes and can’t figure out how to remove it or what’s causing the problem without admin assistance.

    2) Inappropriate site themes

    3) Broken site themes from user experimentation with building their own site themes.

    4) More difficult for the administrator to chang configuration settings for hundreds of individual sites instead of one site.

  7. Thanks for the feedback!

    I’m checking out the sections.module right now! I appreciate the benefits of Drupal for a community site. The Sections module should be able to provide much of what I was trying to describe, but without letting/requiring the users to do it themselves – just pick one of a predefined set of templates (well, ask the administrator to do that for them)

    I’ll play some more with configuring meaningful URLs (I’ve got pathauto generating urls for nodes now, but want to set up something like /blog/dlnorman instead of the default /blog/2 or the LDAP side effect of /blog/dlnorman@ucalgary.ca etc…)

Comments are closed.