The Community Whiteboard Test: Does your new community project prioritize participation, or passivity?

Anyone who's worked in the software industry is familiar with "the legacy problem" -- the fact that it's often easier to build something new from scratch than it is to overhaul and extend an existing system.

I certainly believed that the Legacy Conundrum applied to news sites -- that it would be easier, in many ways, to create a community site from scratch than it would be to effectively integrate community features into the website of your average metro daily newspaper in North America.

As the broad shakeout in news industry continues, I see more and more "from scratch" projects. What have I found?

It's not necessarily easier to build a community site from scratch -- at least not with a major mental overhaul first.

This year I've read dozens of project descriptions from news organizations or individuals with experience in those organizations for new community sites -- but fewer than a handful have more than the bare minimum of participatory features; most are simply another website that gives a visitor a message that their job here is to passively consume information.

After reading so many of these, I came up with a simple exercise to help test a project description for a community site. It's very similar to a paper wireframe exercise, where a team blocks out a diagram of the front page or major landing pages of a website, with one major difference: with the community whiteboard test, you don't try to sort features from top to bottom the way you expect them to appear on the final page -- you block them out on the whiteboard in the order they appear in your description, at a size that you think is proportional to the size they'd take up on the screen.

Does your community site project pass the Whiteboard Test? Here's how to find out.

Draw a large, portait-oriented rectangle on a whiteboard. Divide it in half from top to bottom. Reading your project description in order from the beginning, and for each feature (login block, buddylist) or content type, draw a box within the large box that's proportional to the space you think one of those units will take up on the page. (For instance, a story isn't going to take up less space than your login box, or a search bar).

As you do this, don't vary the order of the features from the order they come up in the project description. When you get to the line that divides the top half of your canvas to the bottom, stop.

At this point, count the number of items that a visitor to your site will "view" -- a story, a photo, a video. Then count the number of items that a visitor can "do" -- add their own content, upload a photo, comment, create an ad-hoc group.

If you have twice as many "view" items as "do" items...you've got a conventional news website. If the success of your project depends on community participation, you'll need to rethink your approach.

A great way to start is to do the same exercise, but start by listing out every feature listed in your project description that gives a visitor a nonpassive way of participating in your site, and block those into the top half of your canvas. Don't worry too much about which order these go in. Do you have enough of such features to fill the top third of the box? If not, time for a brainstorming session.