| No Comments | No TrackBacks

I've just installed DokuWiki at work, and I have to say that I am nothing but thrilled with my first real wiki-founding. Warning: the rest of this entry is almost entirely positive... fanboy-ness ahead, even if it is followed by actual discussion of wiki social issues.

Beyond the cut: Full discussion of Dokuwiki and enthusiasm about wikis in general.

Why Wikis Rule

Many, many others have written about why wikis are wonderful. I think that there are two reasons that most others reduce to:

  • easy distributed hypertext editing
  • wiki syntax lowers the linguistic barrier for hypertext authoring-- wiki creation is somewhere between Storyspace (easy) and HTML (markup, but still harder)

There are certainly nuances and implications to these. You can do a lot more with HTML, but wiki syntax makes markup simple enough (reason 2) that it is a negligible barrier to entry. Wikis do some of the 'book-keeping' for you by automating some links and telegraphing the status of a link's destination (reason 1). The reader and the writing tool are the same (the browser) and are almost universally available (reason 1). Most wikis flatten text/file hierarchies, making a text's structure flexible and removing it as a barrier to editing (reason 1 and 2)

Wikis are excellent for having a group of people who may not be in the same place, may not have knowledge of HTML, may not know the structure of the overall text, and may have better things to do than worry about those things (like writing) focus on the writing.

The fact that wikis (and, to be fair, their predecessors) are now making the terms 'read/write web' or 'two-way web' usable shows that there is a ease-of-use cusp, that wikis have pushed us past. It's so much easier that it's something different.

Why DokuWiki Rules

  • First of all, it's called "dokuwiki". Dah-kyoo-wih-key. It's fun to say.
  • It keeps all the wiki-syntax source in flat text files, making them editable by other programs
  • Nice, clean, mellow stylesheeting
  • It automates hierarchy within a page, building an index of your headings at the top of the page if you have more than three.
  • It sounds like it was taken from Zelda. (hm... the author's site icon is a nut... and it is all about links...)
  • It has more sophisticated features available but not required, including
    • permissions via ACL
    • 'namespaces' which serve as directories for pages
    • built-in site index showing extant pages in an expandable outline form
    • complicated structures like tables
    • interwiki links
  • link typing - automates internal, external, interwiki, and acronym links
  • it's open source PHP on Apache-- common tools.

Installation was even easy... after a fashion. To install it on OS 10.3 I needed to have Darwinports. Darwinports required XCode, which wasn't on the machine I wanted to use. I installed XCode but couldn't get Darwinports to install after about two hours of trying. No love came from the Darwinports list, so I gave up and tried an Aqua app. That kept everything in a database, though, and was ugly and low on features to boot. Then... I installed DokuWiki on my company's hosted webserver and ... a half hour later it was running with ACL security active and HTML enabled. Wow!

An Authoritative Author?

Now my wiki-for-work is my first wiki, and is less than a month old, so I'm shooting from the hip, here. That said: I think that a wiki intended as a source of information, even one which is a collaboration between true peers, needs an organizational vision. An authoritative author or authors, or more delicately, an Editor. A wiki intended as a forum is a different thing, and might be more free-form to allow for emergent structure. This seems to be a philosophical schism in wiki authorship; the strength of a wiki is in the ability of every member of the community to contribute, be it with questions, answers, theories, evidence, or signs of cluelessness. All of these are helpful because the wiki can then accurately represent the structure of thought in the community.

But it can also then get pulled into the confusion or the discord in the community. If the goal of the wiki is to represent the 'state of the art' for a community, the emergent structure is important to see even when the structure is 'conflict'. But when the goal of the wiki is documentation, to help bootstrap most of the readership to greater knowledge, then that discord will more likely lead to frustration and abandonment before it will lead to epiphanies about the challenges the community faces. It seems that a greater authority, even in the form of an active moderator (rather than author) may help by setting down the spirit of the community, by providing a vision that the 'cats' are more than happy to be herded by. Regarding wikis aimed at documentation or user support, I side with the authoritarians with the caveat that a good wiki will have areas where open discussion, questioning, and tinkering is clearly welcome.

For instance, the Tinderbox Wiki evidences (as of this writing) that people don't know where to find or place things. Has their comment been replied to? Is the question already answered over in the [FAQ]? Or is that the [Frequently Asked Questions]? These are dummy examples, but the point is: without a clear framework for us to build upon, all the good will in the world is going to be hidden within a tangle of different conceptions of how documentation should work.

And this is done with the best of will. What we could have is a body of documentation which is criss-crossed by trails established by as many indices as we have perspectives on the material. Once the material is there... want an index (linking edit-discouraged pages) for YourFirstDayWithTinderbox complete with narrative context? Sure. How about ProducingPHPFromTemplates? Sure. But without a clear sense of what is an answer area and what is a question area, where discussion should happen and where plain description is, those indices are likely to start bearing content... which someone else won't know is in ProducingPHPfromTemplates and not HowToMakeTemplates or ExportTemplates.

We're already running into this issue in our work-wiki because we're refactoring an old html-based documentation site into the wiki. We have it easier than Tinderbox (or Wikipedia, etc.) for a few reasons, though. Ours is a documentation wiki, and the work we're documenting has a clear structure-- several constituencies with discrete functions and tasks. Several namespaces are clear and useful: summerNetworks and summerSetup vs. yearNetworks and yearSetup. There are grey areas when something applies to several constituencies, but those are by far the exception, and when they pop up I as head of the department can determine policy. We'll have discussion, but most of it will happen offline, so the wiki doesn't need to deal with it.

The answer, as usual, probably doesn't lie in either the extreme of control (restricted edit privileges to the site or hard-line 'fixing' of edits) or of freedom (unmoderation). From my lack of experience as a wiki moderator I wonder whether there isn't a happy medium in clearly defining portions of sites or pages where edits and discussions are encouraged and portions where edits by anyone but the 'editors' are allowed but socially discouraged.

The software I've played with attempts to solve this with software. One package made the easiest way to edit be a 'comment', which was just a wiki editing window that deposited the typed text onto the bottom of the page in a write-only fashion; edits to existing text were still possible but required clicking through the editing process. Dokuwiki doesn't do that, but the top of the edit page asks: "Please edit the page only if you can improve it." I like that sort of social solution.

So much to read on Wikis

There are many, many interesting pages out there about wikis.

For history, there's the original WikiWikiWeb, started in 1995. There's Wikipedia, (can it be called the currently most popular or successful wiki?) and their entry on wikis.

MeatballWiki is a meta-wiki for "a community of active practicioners striving to teach each other how to organize people using online tools." It has neat discussion of social challenges like ForestFires, BarnRaising, and DocumentMode vs. ThreadMode.

Weblogg-ed discusses "The Read/Write Web in the Classroom", often including wikis. I'm really interested in wikis in the classroom... including the failures.

ETA: DokuWiki Review

Someone wrote a nice quick review of DokuWiki which I agree with and hosts a Word file-conversion tool. Can't figure out who, though, because their site doesn't say anywhere.

No TrackBacks

TrackBack URL:

Leave a comment

About this Entry

This page contains a single entry by Scott Price published on May 6, 2005 1:17 AM.

CSSimplicity Step 1: Analysis was the previous entry in this blog.

Buttons! is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

March 2009

Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31