Part of a Wiki Wednesday series; this post is NOT FINISHED but I needed to post it anyway.
Using a wiki to help develop and edit text for your project is appealing because when it all works you can, when everything works right, get a lot more done with less document management overhead. However, there is a large group of professionals who regularly work with complex documents who are intimately familiar with Microsoft Word, are experts in understanding how it can be used to build complex and attractive deliverables, and for whom a wiki environment is novel - not just because the mechanics of editing, change tracking, and formatting for presentation are different, but because the model for how people work together in this world is not the same.
Here is an outline of how to explain wiki to Word users. It is broken into three parts: the mechanics of moving documents from Word into wiki, the process of working together on a document, and formatting the resulting work for delivery to a client. The first part, document import, is going to vary depending on which wiki platform you are using; I'll illustrate here with Socialtext, which does this task in response to very specific demands from early customers. The second piece on collaboration within wiki is fundamental to the change that people will need to internalize on how work gets done inside a wiki, and it's the hardest to experience without going hands on. Finally, the process of moving completed works from wiki to some other presentation format is worth going through, and again the devil is in the details.
What is a wiki page, and how does it differ from a Word document?
A wiki page can be thought of as a single document inside a collection of related documents. It is typically designed to have multiple authors, and it may or may not have a final published version that is delivered on paper or other static form. In most cases, people editing the wiki page will be online while they are doing it, and their changes will be instantly reflected in the page text.
In contrast, a Word document can be thought of as a single document unconnected to any related documents. At any time it has a single author, and there is very typically a final published version which is designed and formatted for distirbution. In most cases, people editing a Word document will do it independent of Internet access. Changes from multiple people are typically done sequentially, with subsequent authors able to accept or reject annotated changes in Track Changes.
Word is overwhelmingly presentation focused, and generally provides tools for people to build documents that look great. Most wikis have much more limited user control over the aesthetics of the page, and are often designed around collaboration first and only secondarily on presentation for print.
I have an existing draft of a document that I want to upload to a wiki to edit. How do I do that?
In most cases, you can cut and paste from any document on the Internet or any Word document directly into a wiki page. Some formatting will be lost, and some features of the original source document (footnotes, side bars, page layout, and more) will not be preserved.
Sociatext ... document import ... ???
How do I track the changes in a way that I'm used to within a wiki?
Edit ... change ... reconcile versions. Parallel development, merge.
Edit, edit, comment on versions. Serial development, no merge.
Change log, history, who edited which when, what were the differences. Diff based, not red line.
Who gets to edit this document, and how do I know that we're done?
Wiki permissions, edit vs view. Social control, expectations, soft security within an enterprise.
The three people I'm cooperating with have differences of opinion. How do we reconcile these differences within a wiki?
Three way document review inside Word is a huge pain to make sure you get all of the changes merged in in parallel. You can serialize the process by having the document go round-robin but sometimes that introduces unacceptable delays.
I need to take this document that we have made and make it beautiful for print (or PDF) and make it final so that the client can't make changes. How do I do that?
... is just a start; we haven't even hit footnotes, tables, immutable boilerplate, annotations in the change log, accept or reject changes, and ... The ... is ..., and ...
-------
I wonder sometimes which portion of the population has the wiki circuitry in their brains that allow them to light it up and make sense of that environment, and which part does not and will never "get it".
