Publishing a project Weblog

I received a number of thoughtful responses to my recent thoughts on "The conversational enterprise," including this one from Ben Ko:

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

"As a project manager, I wish I had an authoring interface that has the same ease of use as weblog writing interfaces, but allows for more logical structuring of information, rather than putting everything on a calendar roll."

There's a subject near and dear to my heart! A couple of years ago I predicted that Weblogs would emerge within the enterprise as a great way to manage project communication. I'm even more bullish on the concept today. If you're managing an IT project, you are by definition a communication hub. Running a project Weblog is a great way to collect, organize, and publish the documents and discussions that are the lifeblood of the project and to shape these raw materials into a coherent narrative. The serial nature of the Weblog helps you make it the project's newspaper of record. This kind of storytelling can become a powerful way to focus the attention of a group. The desire to listen to a compelling story and find out what happens next is a deep human instinct.

Although Weblogs are typically calendar-oriented, they are not restricted to chronological views. You can, for example, easily categorize items. Popular and inexpensive blogging tools, including Radio UserLand and Movable Type, make it trivial to do this. What's more, each category can produce its own RSS feed. So if you categorize items by task or team, readers can subscribe according to their interests.

The value of a project Weblog has a lot to do with getting everybody onto the same page -- literally. You want to deliver a manageable flow on the home page, drawing attention to the key events in the daily life of the project. To do this well, think like a journalist. You're not a journalist, you say? Don't worry, I'm not one either, I just play one on TV. Really, I'm an information architect. And by a happy coincidence, many of the principles and techniques I've learned over the years -- designing software user interfaces and information displays -- turn out to be the same ones that journalists use.

The newspaper editor's mantra is "heads, decks, and leads" -- in other words, headlines, summaries, and introductory paragraphs. These devices are, in fact, tools for managing a scarce and precious resource: the reader's attention. A well-written title (or subject header if you happen to be composing an e-mail message) is your first, best, and often only chance to get your message across. In the Web publishing game, a title plays a number of key roles. It identifies an item on the home page, in the RSS feed, and in the results list returned by any search engine. In the last case, Movable Type has the advantage over Radio UserLand since each item gets its own HTML page and HTML document title.

Projects move quickly, so you can't spend a lot of time crafting decks and leads. But if you use the project Weblog to gather and post key documents such as specs or status reports as well as selected e-mail discussion-related to them, you'll find it's easy to get into a rhythm: quote fragments on the Weblog, upload the supporting documents, and link to them. Radio UserLand shines here because it will automatically upload anything you copy to the /radio/www/gems directory: images, PDF files, Word or Excel files. A simple Web-accessible repository augmented with brief commentary explaining what has been posted and why turns out to be a powerful team coordination aid.

Decks and leads can also play several roles. When you post an item to a blog page using these devices and then link elsewhere for the full story, you're doing just what a newspaper does, and for the same reason. You want the project's home page to deliver the at-a-glance overview and then direct attention elsewhere. Of course, attention that goes elsewhere might not come back. Fortunately the Web offers techniques that aren't available to newspapers. Expanding outlines are one useful trick. On my public Weblog, I maintain two topical views that I compose in the Radio UserLand outliner and which are automatically rendered in HTML/JavaScript by Marc Barrot's nifty activeRenderer. This method enables me to publish headlines that expand in place to reveal decks or leads, which the reader can review in order to decide whether to click through to the linked item.

With judicious use of both chronological and topical views, you can pack a lot of information onto the home page. But you have to make effective use of your archives too. It's helpful to repeat your chronological and topical indexes on archive pages. In Movable Type by default and in Radio UserLand by means of some simple add-in macros, you can also link each archive page to its predecessor and successor. Since related items often cluster together on the project timeline, this kind of sequential access is handy -- particularly when a search drops the reader into the middle of your archive.

No matter how effective your navigational scheme, there's no substitute for full text search when you need to find something that's vanished from current view. Movable Type, which is server-based, has supported search out of the box since Version 2.5, though many Movable Type sites still don't take advantage of it. Radio UserLand, which is client-based, doesn't offer search. In either case, if your Weblog is public -- as it might be if you're using it to support a product or service -- you can use a hosted search engine to make it searchable. Atomz.com or Master.com will index and search hundreds of pages for free. That's a trivial quantity by commercial Web site standards, but plenty for most Weblogs. If you're running behind a firewall, you clearly can't rely on public search services. Any intranet search engine can meet the need, though. One way or another, do make your project Weblog searchable. There's no point in building a collection of documents that you can't search.

Like Ben Ko, I'm eager for more powerful writing tools that will make it even easier to gather documents and messages and shape them into a project narrative. By pushing current tools to their limits and beyond, we'll discover what those next-generation tools need to be.