Blog: Secrets from the Chef

What could outrank Basecamp?

There is hardly ever a person who could be surprised by a convenient and nice extranet system. “Oh! You are using Basecamp! Great!” — that is what our clients tell us after they have received an invitation to visit turbomilk.seework.com. Basecamp has become a de facto standard, and 37signals, its developers, showed up as recognized gurus of web applications design and usability.

When we started using Basecamp, it felt like we are in heaven. The system simply did its job without making us think that we are too dumb to use it. A complete absence of tweaking options (except coloring the interface) turned out to be a great advantage of no necessity to spend the time and efforts to do that tweaking. Just launch — and work. However, after a year of active use of Basecamp (several dozens of accomplished projects later) I started to think we need to take a more sober look at this system.

A project in Basecamp resembles a blog. It has categories, messages and comments. This is a structure well known to the user and this is an advantage for sure. Is it ideal for project management? Blogging is a continuous process lacking a specific objective (in most cases). A project manager, unlike the author of the blog, hopes the project to be accomplished, sooner or later. A successful finalization of the project is a goal that all the project participants are striving for, and all their efforts are focused on implementation of certain tasks related thereto. And it is only with the total blog craze that we can explain the fact that a project management tool looks like a blog. I have heard, however, that some companies use MovableType as the Intranet system…

Why do I dislike this blog-like structure? The thing is that this structure tears apart the natural threads of messages task &rarr draft &rarr feedback &rarr revised draft &rarr feedback &rarr … &rarr final variant, should you publish every new version as a new message:

What Basecamp allows you not is to track the connections marked red on this diagram. As a result, every time we want to publish a new draft, revised with the feedback received, we feel a temptation not to create a new message (as the system logic tells us) but to post a comment to the existing message in order to keep that connection with already existing comments. After the developers integrated the opportunity of attaching the files to comments this temptation has grown stronger still:

However, in that case the All Messages page will give you only the primary task descriptions, whereas the fresh and up-to-date drafts and feedback are to be looked for somewhere deeper, or, alternatively, they can be found on the Overview page, where everything is collected in a chronologically organized heap like this:

But I would like to have a page where I would see only the latest events in each chain. To achieve this, we only need to discard the model of dividing everything into messages and comments and turn the whole thing back to front:

Marked yellow are the messages which are to be shown on the main project page. A single glance at such a page will allow evaluation of the current status of all tasks. And if you unwrap any thread you will see all of its history, up to the primary task.

As you can see, this model is not in the least more complicated than the one presented in Basecamp. However, it suits our requirements to a greater extent. Do I want too much?

I had a complaint from a client in a large project recently. He said he failed to find and collect all the approved drafts. He is hardly to blame for it: the project lasted several months and consisted of lots of small parts. Each of these underwent lots of iterations. As a result, in the course of time we experienced a great difficulty in finding the messages with final versions: we simply had to open each message and to read all comments.

Sad music accompanies Basecamp is losing the title of the Dream System… and Basecamp is obtaining the worthy title of an honest working tool… In our eyes.