Posted 11.16.2009

Posted 11.16.2009

CMS Comparison: Choosing the Right Tools to Power Your Blog

I’m a HUGE fan of Expression Engine. (Actually, I love all the stuff that Ellis Labs is doing). However, as I’ve worked on other projects that require a different platform, I’ve had the “opportunity” to learn.

Movable Type

At my day job, I’ve been building (a lot of) blogs on Movable Type’s platform.

My friends in high places (i.e. IT) tell me that Movable Type was chosen because of the support that they offer. If WordPress goes down, you’re SOL. However, Movable Type offers customer service that will help you solve the problem. In fact, I assume that’s one of the reasons why Obama is using Movable Type.

Also, from a multi-author platform, Movable Type is easy peasy, lemon squeezy. Literally, a few clicks and you’ve got another blog up and running.

The Community
At first, I HATED Movable Type, namely, because of the (lack of) community. There was a HUGE change in the code between version 3 and 4. A quick Google search of “Movable Type Tutorials” has 746,000 hits, however, I wouldn’t be surprised if 90% of the results are based on old code = USELESS.

It’s amazing what community support does.

  • Plugins – Because the community so small, there aren’t very many plugins to choose from
  • Knowledge: Tutorials, Best Practices, + Troubleshooting – Whenever I run into an issue, my best bet is to phone a friend. There aren’t a whole lot of other resources out there, unfortunately.

I haven’t been impressed with the documentation on Movable Type’s site either. It’s hard to find the information that I need, and in some cases, the documentation that I have read has been inaccurate! Talk about beating your head against a wall!

Once you understand the templating process, it’s actually not THAT bad. But there are a few key concepts to remember. For example, Movable Type is based on PERL. –SO– when you write a blog post, it will actually generate a static HTML page. The cool part is this makes your site super fast. It’s not having to ping the database every time a user visits a page. Even if you have a whirl wind of traffic, Movable Type can handle it better than some of these other CMSes. However, every time you make a change to a template, you’ve got to republish your site, especially on pages with includes (header, footer, sidebar, etc). This makes minor site tweaks incredibly tedious.

Quick Note:
I’m planning on writing a series about building sites in Movable Type, so please be patient and stay tuned.

It’s also proved a challenge teaching others how to use Movable Type. It’s not that difficult, but when someone is used to WordPress… well, there’s enough difference to cause some aggravation.


I’ve been working a freelance project for the Cooperative Program. We decided to go with WordPress for a couple of reasons:

  • Custom Fields
  • Cost (free)
  • There’s a plugin available for just about anything
You can create custom fields in Movable Type, however, it requires a special plugin.

THE DIFFERENCE BETWEEN WORDPRESS .COM AND .ORG is hosted on WordPress’s site. The nice thing: you can have an account + blog ready to go in 5 minutes flat. The downside? there are a few restrictions on which plugins, themes, and backend hackery you can do. For a control freak like me (when it comes to code), this isn’t acceptable. I lean towards means that you download WordPress and install it on your own server. You’ll have to go through a service like GoDaddy or Network Solutions.

Over your head?
When you create a website you have to have a name and a place to store it. Think about it like this. When I buy a house, I have to have an address and a plot of land. Same thing for the web: an address ( and a place to keep all my files (Network Solutions or GoDaddy).

Unlike Movable Type, the community is HUGE. This is fantastic when you’re trying to troubleshoot or find a specific plugin. Chances are, someone’s already figured it out.

Like most things in life, the pendulum swings both ways. If Movable Type = non existent, then WordPress = over saturated.

For every question there are dozens of solutions. I struggle with finding the best practice. Every plugin installs and places its preferences somewhere different. If I have a dozen plugins, then my backend ends up looking junky. –There are no standards!

When I’m Googling “creating custom themes for WordPress”, there are tons of tutorials out there, but some glaze the surface, while others go way too deep.

As much as I complained about Movable Type, I would choose it over WordPress.

I’m planning on writing a WordPress tutorial of my own, so, again, patience please!


My boss uses tumblr and loves it. We’ve implemented it at work, for sharing cool things that we find (either resources or inspiration for upcoming projects). So far, it’s worked out pretty well. If a new post has been made, I’ll get an Email every morning with the new content. This is nice. It’s not updated regularly, I don’t have constantly visit the site to check for new posts. (Actually, that feature specific to Tumblr. That was done with the help of Feedburner.)

Tumblr is all about the community. You can follow people within Tumblr and easily repost content, if someone has already posted it once on Tumblr.

Funny, though, you can’t comment on posts that people make, unless you hack it, with Disqus

There are only 7 types of content that you can post to Tumblr: text, photo, quote, link, chat, audio, and video. Again, pretty straight forward, but not enough to support a complex site.

Expression Engine

This is my favorite. Hands down. I’m bias.

Expression Engine’s (EE) documentation is well written: complete, easy to understand, and easy to navigate.

The community is so great. Anytime I have had an issue and posted it on the forums, I’ve generally had a response with a few hours.

The plugins that have been created are quality.

— With EE2.0 they’re building it on CodeIgniter’s framework, which will make it even easier to build plugins.

There are plenty of tutorial sites out there that have great information. If you’re just starting, I would suggest starting with Pragmatic Programmer. However, EEInsider, DevotEE, Jambor-EE, TrainEE, and EE How To are also good resources worth visiting.

I’ve trained multiple clients on using EE. In all cases, (even non-Tech clients) have been thrilled with how easy it is to update their site.

EE’s greatest asset is it’s flexibility. I can do anything. I LOVE having complete control over my code. No limitations.

Yeah, the flipside is that I have to code more, but in the end, I’m so much more pleased with results.

They recently announced that version 2.0 will launch December 1, 2009. After waiting a year and half, you can bet I did a happy dance and marked it on my calendar. (and you think I’m joking)


While I’ve been getting antsy for EE2.0. Darrel also loves SquareSpace. He’s using it to run another one of his blogs.

So, I’ve been experimenting, a little. My biggest beef (again) is control. It’s super easy to change your templates and add new widgets, however, creating custom templates is another story. I have a decent amount of control through the CSS, but some of it is hack-y. For example, to move the menu above the header: margin-top: -200px;

I also can’t insert HTML. Take my website for example. I have a vignette in the top left and right corners. Ideally, I need 2 containers that will span 100% with absolute positioning. With the given structure from SquareSpace, I can only get 1 corner to work.

Even though, EE is by far my favorite, I would consider “selling” a client on SquareSpace.

One thing that SquareSpace has that EE doesn’t: an iPhone app. We’ll see what happens after December 1…

Posted 11.14.2009

Planning a Web App

Lately, I’ve been working on a super secret project. (details to come later…yeah, I hate that line too)

So far, it’s been a great learning experience. I’ve been coding on Code Igniter, which for someone that L-O-V-E-S Expression Engine, Code Igniter is even better.

One of the things that I’ve been struggling with is how to plan out a web app.

I’ve read (most of) 37 Signal‘s book, Getting Real, which talks about just doing it:

Don’t write a functional specifications document

These blueprint docs usually wind up having almost nothing to do with the finished product. Here’s why:

  • Functional specs are fantasies
  • Functional specs are about appeasement
  • Functional specs only lead to an illusion of agreement
  • Functional specs force you to make the most important decisions when you have the least information
  • Functional specs lead to feature overload
  • Functional specs don’t let you evolve, change,and reassess

When you’re anxious to get a project off the ground, this is a great method. I made huge headway at the beginning of the project. I impressed myself, even. However, I eventually had to take a step back. There were a few problems:

  • I kept changing my code because I had not made all the decisions up front on how something was going to work.
  • I started to get this fear in the pit of my stomach that my code was not efficient. I was duplicating code because I hadn’t thought through it on the front end.
  • I hit a wall. There wasn’t a clear next action step. (thanks GTD)

Back in September, Ryan (37 Signals employee) wrote a blog post, A Shorthand for Designing UI Flows. I’ve tried using this to press on, but it’s still hard. My charts look overwhelming.

What is the best practice? Thoughts? Suggestions? Resources? Musical Anecdotes?