Do you have any recommendations forf an ISP that can host a confluence wiki (just a small personal one of 10 users). We have a trial at work, but I’d like to have my own wiki on my personal Web site. However, it’s hosted by Network Solutions, and someone on the user forum said it has to be programmed in PHP, and Confluence is Java. (Support hasn’t responded yet.) It’s making me want to switch my ISP. I imagine you were able to get the free version of Confluence because you may have used it for a non-profit organization and they probably had their own server.

Thanks!

Gina

Like you, I prefer working directly on the web (though I don’t often have the opportunity). Instead of focusing on tools, you can focus on developing quality information. I appreciated the ease and immediacy of updating sections. And if others working on the wiki wanted to edit my topics, they could easily do so.

Disclaimer: I haven’t been a part of the BiomedGT project for a while, and I note that some of the links aren’t working. I claim no responsibility for that.

When I wanted to reuse content in topics, I used transclusion. In fact, I wrote a post describing how to use transclusion:

http://www.vanarsdall-infodesign.com/2009/06/02/reusing-content-on-wikis-and-blogs/

Eddie

Some thoughts…
1. “Authoring directly on a wiki screws up the history of updates.”
Suggestion…At the start of each software release, why not export the latest revision and import into a fresh, clean new wiki? We do this for every major software release for our online version (for customers).

2. “The text width is longer than St. Pete beach.”
This can be easily controlled by a style sheet for any of your Namespaces. We do this especially for lines of code in the examples we provide.

3. “Community members seem more likely to make little edits rather than create entire pages.”
The good thing about this is that everyone has become aware of how very easy it is to make a small update…any minor correction. Our developers no longer have to take the time to create a doc bug in our system or send me email. They just click the “Edit” tab, and voila! the change is made.
Plus, we use a template at the top of each wiki page (in our internal “production” wiki for product documentation) that provides a rating system. Our developers can see at a glance in our wiki dashboard which pages have a higher rating (because of the number/type of examples, interface descriptions, images including Flash, etc.). Some of our short, outdated pages have been greatly transformed! And because the system is so easy to use, developers have created new pages. (I provide boilerplates to make creating new pages easy for them.)

4. “Navigation is cumbersome.”
You gotta use categories and sub-categories! Plus you can do away with the TOC on any page (or group of pages as in a Namespace) if desired. We use templates so that an auto-generated TOC can be displayed either in our Portals, Release Notes, or any place where we want to provide extra navigation. Using Categories has been essential…plus it provides a “bird’s eye” view of the entire site’s contents when you expand on any of the Category trees.
I do agree with you that creating short pages is best. We make use of See Also and NavForward links at the bottom of our pages, especially in our Tutorial pages.
And yes, there is a way to pull in sections from other pages…transclude. Or use the NAVCONTENT plugin.

5. “Making updates is incredibly simple.”
Yes, absolutely! That’s the beauty of a wiki!

6. “Wikis are a web format.”
Ah! But they are living documents!
a. “little or no interaction with the user community”
I disagree. We encourage our customers to post comments, feedback, and doc requests on the Talk (writable discussion) pages. (Each wiki page has a Discussion tab at the top for customer input.) I check every morning for feedback…I let them know that their request has been received and forwarded, and by day-end, I usually have an answer for them direct from our development team.
Plus, with the latest version of MediaWiki, you can specify in the LocalSettings.php which Namespaces can go unprotected (writable). And you can always create custom Namespaces.
b. “uncorrectable errors that can’t be fixed”
Our customers point out errors, and once verified, I fix them immediately…that same day. No need to regenerate HTML files or PDFs. Whatever change I make on the external wiki, I am sure to make the same in our production version (which will eventually replace the external one upon a major release). I also upload all Service Pack changes by tagging them on the production wiki. And with one button, MediaWiki exports all those pages (using a Service Pack Release category).
c. “a mindset of it’s-released-so-now-I’m-done.”
Again, try using the template rating system. Provide a dashboard to stir up some friendly competition.
d. “no time for translation or video tutorials”
Why not upload the video tutorials or changed pages within a few days post release? (Treat the updates like a Service Pack release.)

7. “Wikis provide a new language to learn.”
You’re right. And as you mentioned, “fun”! You can use templates (for example, Note, Important, etc.) instead of styles (via menus, buttons). Editing in MediaWiki is almost as easy as typing in Notepad.

As you can tell, I’m really passionate about developing and publishing product documentation on the wiki platform. I’ve used everything from FrameMaker, WebWorks, PageMaker, QuarkXpress, Word, and even vi on a mainframe system. This system is truly a collaborative one and saves so much time!

Thanks for the heads up on search. I’ll have to address it in my documentation strategy somehow.

I use TWiki as well (for internal company wiki) and agree with the previous comments. I wanted to add though that I’ve had a hard time with searching on TWiki. Search results are listed alphabetically (instead of by relevance) and the search engine doesn’t offer many options (like best bet results, or sorting by date, etc.).

How well the search works would be one of my main concerns when using a wiki for documentation. However, if you build a decent TOC for people, you can get around problems with searching (which is what we’ve done with our wiki). But it bugs me that the TOC is all we have.

That being said, TWiki has a pretty active developer community who is publishing new plugins all the time. Another important point when you explore the world of wikis.

Thanks for linking to your example. It really helps to see this process in action.

It depends on your project, obviously, but I think wikis are going to be the way documentation is done in the next ten years, simply because it’s the way of the web.

Re hierarchies, I’m not really sure what you mean. Can you expand on it?

with near 100 different wiki engines, it’s hard to know which to use. Obviously Wikipedia is a strong selling point for Mediawiki. I do like how robust Mediawiki is. There are hundreds of plugins for it and abundant tutorials/instruction.