My journey to writing with a wiki
In a recent post, I discussed how wikis aren’t just tools for techie but are also for writers. I threatened to discuss at length how I use a wiki to do my writing.
If you’re interested in learning about how I do that, then read on.
I’m not always in my home office (as it is) when I write. I regularly write away from home, either with my laptop or my netbook. Sometimes, I don’t even use my own computer — I use someone elses or one at an Internet cafe (regularly taking advantage of PortableApps).
Instead of having to transfer files between computers, it’s easier to use the Web. Which is what I’ve been doing for a few years now.
Taking the first steps
A few years ago, I hacked together an online writing workflow. It was simple, and easy to set up. But it involved using a variety of applications; nothing was centralized. After that, I started using Google Docs, which I really like. But something was missing.
On top of that, my information was in the hands of others (or as close to that situation as possible). I really wanted to put my writing back into my own hands, and not have to worry about, say, getting locked out of my Google account for entering the wrong password or mistyping it one time too many.
Looking to the wiki, once then twice
As I’ve mentioned several times in the past, I was exposed to wikis in various development shops in which I’ve worked as a technical writer. I saw the value of a wiki not only as a tool for collaboration, but also for writing.
Some time before coming up with my online writing workflow, I used PBWiki for about a year. It was good, but not quite what I was after. I drifted away from it to applications like Google Docs and Writeboard.
Last year, I decided to give the wiki another look — not a hosted one, but one of the Web server that I use. My hosting company offers quick installations of a couple of wiki engines. I tried them both, but they weren’t quite what I was looking for.
Then I heard about DokuWiki. With a few tweaks, I could turn it into a very powerful and useful online writing hub.
Structure and organization
When I jumped back into using a wiki, I did so with one rule in mind: structure is important. I didn’t want to just dump information into the wiki. That would definitely complicate things — it would be difficult to organize and find notes, outlines, and actual written work.
Instead, I came up with a simple way to organizing everything on my wiki. I currently have seven distinct sections on the wiki:
- Active Projects
- Planned Projects
- TechTips
- Presentations
- Articles
- Draft Blog Posts
- Outlines
If you’re wondering about TechTips, it’s a weekly (or so) article series to which I contribute.
But I added something else to the organization: namespaces. A namespace is like a folder on your computer into which you save similar documents. The namespace is your friend. You can have individual silos on the wiki for each project and never their twains shall meet.
As you may have guessed, each section on the wiki is in its own namespace.
Expanding DokuWiki’s capabilities
Out of the box, DokuWiki is a great tool. But there are ways that you can make it better for writing. To do that, I installed the following additions:
- The ODT plugin, which lets me export my documents in a file that I can open using OpenOffice.org Writer.).
- A word counter, which displays a running word count as I type.
I also take advantage of section editing, which literally allows me to edit discrete portions of a document.
How I do the deed
Remember the sections of the wiki I mentioned earlier? Those are my starting point. The links to those sections are on the main page of my wiki. When, say, I want to write a new article I click on the link to the Articles section, and then add a link to the new document on the articles page.
From there, I click that link and start typing. I’ve set my wiki up without a WYSIWYG editor. It’s a distraction. That said, I do use the default toolbar which allows me to quickly add formatting without having to type wiki markup.
The Web browsers that I use (Firefox and Epiphany) have built-in spell checking functions. When I’m editing a form, like the editor in my wiki, the browser points out any typos.
Collaboration
Wikis were designed for collaboration. I don’t do a lot of that, although I’m currently working on a small project with a couple of other writers. On pain of … well, lots of pain, I’m not allowed to share any details. But we are using my wiki to do the writing.
Why use the wiki to collaborate. Passing files around by email (or any other method) is fraught with danger. Files can be lost or become corrupted. You can send the wrong version of a file to someone. That can be frustrating. Sure, you can use the compare documents feature found in most word processors to try to get around this, but that’s a lot of work.
A wiki, on the other hand, makes collaboration easier. Your work is in one location, and there’s no chance of stomping on someone else’s edits.
Earlier, I talked about namespaces. The come in handy when working with others. You can give your collaborators access to a particular namespace, but nothing else. When they log into the wiki, they’ll only see what they’re supposed to be working on and nothing else.
Some people will argue that doing this goes against the original wiki principle of openness, but to each their own.
Getting content out of the wiki
When dealing with technical writing, I usually say that you shouldn’t worry about getting content out of a wiki — the wiki is the delivery method. In the freelance writing world, things are a bit different.
Few editors are interested in or willing to log into a wiki (or any other online tool) and copy and paste content. They want a file that they can edit. Preferably a Word file.
That’s where the ODT plugin that I mentioned earlier comes in. That plugin lets me save a wiki document in OpenDocument format. I can pull an ODT file into OpenOffice.org Writer or AbiWord, apply a template (if necessary), and then save the file as a Word document.
While turning a wiki into a writing environment takes a bit of work up front, it’s not difficult. And once you get used to working with a wiki, you can fit it comfortably into your workflow.
Related posts:
Wonderful writeup. I was actually looking for a wiki solution for wireframing sites with, your detail has convinced me to give docuwiki a go for that and possibly a workflow management system such as yours. Many thanks.
@Mark Thanks for the comment. Hope your wiki experiment goes well, and that you tweet about your progress. I’ll definitely keep an eye on your feed.
I shall try this. I use Tinderbox on my computer and blosxom on the web. Blosxom handles the plain text and publishes to the web, htmldoc as cgi script can publish to pdf. BUt I think you solution may improve the business of writing from several locations