Nowhere in the description of System One does the word “wiki” appear (well, actually, it does, but not very prominently). And that’s a good thing. Because “wiki” as such is an albatross. The benefits (openness to multiple editors, ease of page creation and editing) do not require the syntactical and linguistic baggage that comes with most wikis. And they bring with them one very serious problem: finding things. Wikis are great for information capture but not so great for information retrieval. To the point that I’ve been on more than one project that began with a wiki as the primary collaborative space and at one point or another the group agreed to abandon or augment it in favor of something else (Basecamp, word documents, etc.).
Take, for example, requirements writing. If all your requirements are in a wiki, each on a separate WikiPage, with all the extra discussional cruft that wikis seem to engender, they are not useful as requirements. Sure you can point to them and say: “There are the requirements” but you can’t easily design from them. Especially if they are constantly editable.
Obviously, this is in part about how you use your wiki, but the point is that tools encourage (afford, whatever) certain behavior. Wikis encourage adding information. They don’t encourage (though they require) managing that information.
Oh, System One? Looks really cool. Very academic approach (in fact, this is probably the most academic approach to product design I’ve ever seen produce an actual useful product). Looking forward to seeing the benefits of wikis leave their garden of semi-usefulness, and permeate the way we interact with information.
Comments