link

Free wikis for workgroups.

link

There has been a very interesting thread among some frasslers recently. It started out with a question by a blogging newbie—Jennifer—about the basic motivations for blogging, but escalated into a discussion between Josh and MySQL-Wikipedia-dude (hereinafter MWd) on the relative merits of Wikis and blogs.

I like both Wikis and blogs, and I don't think they are distinct islands. I agree with MWd that many of the features common in Wikis—like photo and file uploading, version tracking, and multi-user editing—would be important for collaborative work (and often lone work, too). These kinds of features don't seem tied to either Wikis or blogs. They are all on the long list of desiderata for frassle.

So, if all these little features aren't intrisically tied to blogs or wikis, what are the differences between the tools? I want to look at three points:

1. The prominence of order in time as an organizing principle.
2. The ease with which a user can directly edit a piece of content she did not create.
3. The ease with which new relevant content can be found based on the context of an ongoing discussion or long-lived page.

1. The prominence of order in time as an organizing principle. Blogs push it; Wikis don't. On one hand, this makes blogs seem more fleeting—there is lots of stuff scribbled in that drifts off the screen after a little while. Frassle tries to straddle this line by offering another organizational system—categories. But reverse-chronological is still the primary view.

I would argue that, for all its downsides, time-ordering has two huge upsides: it's simple, and it works. For most people, it is too much work to decide upon an organizing principle for a growing body of work. On the other hand, without an organizing principle, one experiences what I'll call the existential quandary of wikis. What came first, the Wiki or its organizing principles? It's hard to add content when you don't know where it might fit in, so many people are reluctant to contribute to a Wiki. Although Wiki designers have included revision history in order to counteract that reluctance, revision control is way harder to understand than "it's a stack of posts ordered by time". With reverse-chron ordering, you might lose some stuff in the pile, but at least you know how the pile works. And hey, it's not so hard to find stuff either, what with all the linking and great search engines. So blogs bypass the existential quandary and yet retain many of the same benefits.

2. The ease with which a user can directly edit a piece of content she did not create. Wikis offer a new user more potential power. But not without a cost: despite impressive Wikipedia vandalism-recovery experiments, people still feel protective of the work they create. Additionally, when people who view the work you've made can easily associate it with you, it's possible to develop a reputation. The permanence and presence of this reputation is what incents people to sometimes compromise their immediate self-interest because of longer-term engagements and opportunities. Humans are socially evolved to put their stamp on the things they create, and the interactions they participate in. Few can contribute to the common good without wishing for at least some recognition. Blogs, on the other hand, are built around people; they even encourage some self-indulgence.

3. The ease with which new relevant content can be found based on the context of an ongoing discussion or long-lived page. The chief way of organizing a wiki is by linking. When there is a small collection of highly-interlinked content (e.g. a wiki for a single project), or a large collection of lightly-interlinked content (wikipedia), linking is either easy and necessary or hard but unneccessary. However, for many medium-sized Wikis, I find linking to be both hard and neccessary. Hard because there is a lot of new content, but neccessary because when something new comes in, if its useful period is to last beyond its time in the recent changes list, it must be linked from more established, related pages.

For this (large) class of challenges, I think Wikis offer only the illusion of simple, flexible organization. In fact, they tend to fall back to the reverse-chronological views typical of blogs, and the few relevant pages are drowned in a sea of mixed-topic recent-updaters.

By contrast, weblogs are really stupid. Nobody who has anything serious to organize or preserve will ever be satisfied with it appearing on her homepage for a day or two, then getting stuck in some calendar archive. This is why blogs offer tools like categories, search engines, technorati inbound links, subscriptions, subscribable egosearches, and so forth. While I think the most competently maintained Wiki can probably beat the best blog, in general the combination of organizing tools available for blogs earns them the win. It's a lot easier to find information relevant to the average weblog post than the average Wiki page.

Finally, although some of what I've written here seems to pit blogs against wikis, I don't think they are so opposite. I think that mainly, the tools we've seen so far have specialized on one end of these scales or the other, but that is a question of the tool designs, not conceptual constraints. Ultimately, I hope we can have tools that incorporate the range of features from blogs through wikis, and allow writers to select the right blend of features at every turn.

link

link

a personal tool to allow me to take notes in a wide variety of contexts — plain text files, blog entries, comments in source code, MS Word/Open Office documents, etc — and keep an archive that keeps track of locations and can automatically (based on metadata rules) republish the content in a variety of formats: e.g. assemble the notes into the outline of a formal document in DocBook, or as a collection of interlinked pages on a Wiki-like website.

I'm trying to wrap my mind around Wikis. They seem to have some sort of conceptual barrier: a few people seem to love them but most are just bewildered. I'm not a skeptic—I like the idea that anyone can edit a page and I believe it can work civilly. In this post, which I've incrementally edited over the course of several hours, I hope to figure out what works and what's bewildering.

Consider collaboration at a workplace. A wiki would seem to work well here because people already have an etiquette for interacting with each other. There is a compelling need to share lots of information. It is beneficial when people not usually involved in a certain discussion can read it and contribute. It is a great time-saver when work documents have been saved in a shared, searchable system. Sounds wikilicious, no?

But the unconstrained form of the wiki implies some major limitations. Firstly, there is no way to keep up to date on new material. At work, information quickly becomes outdated and useless; but most Wikis do not provide a usable way to keep tabs on the latest developments. Perhaps this could be addressed by better-designed "latest changes" pages and publication of RSS feeds. I'm not sure because I haven't personally used these features in a wiki.

The two wikis I have used and enjoyed, Ward Cunningham's original (c2) Wiki and the Wikipedia, have chosen to focus on content that is not very time-sensitive. The c2 Wiki focuses on patterns in software development. The word pattern here refers to a specific literary form. Though it has been diluted somewhat from its original meaning (discussed, among other things, in Richard Gabriel's wonderful book Patterns of Software) it is a way of identifying a system of related events, actions, and people that occurs repeatedly in life. The pattern literary form identifies a pattern and describes a technique to help achieve it. There are also antipatterns that tell you what to avoid.

Patterns are well suited to collaborative development on a wiki. Firstly, patterns benefit from the input of many people—their different experiences can refine the pattern's definition, identify gotchas, and point to related information. Secondly, a large set of interrelated patterns comprise a pattern language. A pattern language is like a regular language—your familiarity with it should be broad, not focused; some redundancy is built in; and certain parts of it lead you naturally to other parts. This maps well to a wiki, because you can start at one place and go through at your own pace. If you need specific knowledge to understand the context of one pattern, it links to that knowledge. And finally, the patterns are a small set of related concepts that are being incrementally refined. It's not like a business enterprise where there are constantly new concepts being proposed and thrown away.

So maybe that is my beef with wikis at work: it's too easy for what was once the Team Foo Wiki to become Company X Wiki when others want to participate. But once there are so many different contributors, so much new material every day, and no clear purpose to the wiki, scalability problems arise. In certain cases like the c2 wiki and Wikipedia, the nature of the wiki content can mitigate or escape these problems.

Summary

My critical points in handy rule-of-thumb form:

• Wikis are for small, purposeful, long-term collaborative efforts. If a wiki has over 20 participants and no clearly defined work-product—i.e. a type of document to be developed on the wiki itself, such as product specifications—it will bewilder new users due to its lack of simple organizing logic or obvious ways to acquire context.
• Wikis do better to focus on a few work-products that evolve gradually than many work-products that are frequently obsoleted. Wikis save everything, and do not give priority to recent entires. Constant new entries dilute the purpose of the wiki and it's hard to evaluate which of two conflicting entires represents current thinking.

For Further Investigation

• An interesting new wiki for Richard Gabriel's Extravagaria Workshop, exploring the intersections of art and science.
• Bill Ives has some thoughts on Working with Wikis.

link

Free software Bliki implementation. Looks good.

Also on that site:

• Why "another" Blog and Wiki?
• Link to Martin Fowler's thoughts on Blikis
• Link to Wikipedia's definition & list of Blikis

link

Collaborative kinda-multi-lingual dictionary.