There are lots of different Wiki solutions to choose from. Wikipedia has a good list going, in fact.
If your main factor for deciding on a Wiki solution is cost, there are plenty of freeware options. Just keep in mind that you get what you pay for. They are feature-lite and lacking in support. I'd encourage you to explore this if you're just experimenting with Wiki. However, I'm sure you'll find that once you're committed, your desire for features will drive your decision more than cost.
A major consideration should be ease of customization. If you or someone on your staff is comfortable in a particular programming language -- CSS, PHP, Perl, Python or Java -- then you might want to choose a solution that is implemented with that language. However, the more powerful Wiki solutions will present a non-programmer interface for adding features via plug-ins and macro editing windows. In the spirit of open-source collaboration, there are hundreds of Wiki plug-ins and macros out there that may give you the specific features you want.
The examples I use in this article use TWiki and Confluence. Actual Wiki syntax can and will vary significantly with each Wiki.
The pros and cons below are based on using Wiki versus more traditional Word and PDF documents.
Not Very Portable:
Wiki supports multiple editors working simultaneously on different topics. This appears to be the trend for all major undertakings. Take a look at Google Docs for an extreme case, where multiple users can edit the same spreadsheet at the same time.
Microsoft is working on a similar service for Office, but its implementation is somewhat different. Currently, it's more common to navigate to a Word document on the network, open it on your desktop, edit a paragraph, and hit "save" -- only to be told that the file is locked by someone else. That doesn't happen with Wiki unless users are editing the same exact topic.
Everyone has heard of the adage and probably experienced it for themselves: "Too many cooks in the kitchen spoil the broth." Clearly the biggest concern for most designers new to Wiki is the lack of cohesiveness that comes from group design.
They have a reason to be concerned. I've seen Wikis that were completely disorganized, disjointed and more or less unusable as a design specification as the various editors war over its contents and presentation. Clearly not everyone is a writer -- or particularly good designer. There's another adage at play here: "Just because you can, doesn't mean you should."
In my experience, the best design documents were written by designers adept at technical writing who listened as well as they wrote. They were able to take the various contributions, notes, and feedback from the team to create a cohesive, attainable game design specification that represents the goals and ideas of the team. The role of lead documenter just doesn't exist in Wiki. It runs counter to its philosophy.
There are a few ways to avoid these problems without becoming a complete Wiki Nazi:
1. Most Wikis can be configured to block anonymous users from making changes.
2. Some Wikis offer version control and change history tied to user name, which offers some accountability and recourse should there be some undesirable change.
3. Additionally, most Wikis offer read-only access control per page by group or user. This is less than ideal. I've only ever used it to keep people from seeing embedded database passwords.
4. Establish a style guide for each type of content and create a framework to structure all the Wiki pages into categories.
5. Enforce a formal migration of Wiki pages so that proposed ideas, notes and specs under development are kept away from published specifications.
6. If there isn't a lead designer with time on his hands to edit Wiki pages, have a designated WikiMaster at the company whose job it is to clean up and organize Wiki pages.
Wiki works with any web browser. The URL uses the Wiki topic name in simple CamelCase, making finding pages very easy. All Wikis have some way to tag pages for searches -- essentially applying key words to make associating and searching for the topics very easy. Confluence calls them labels and TWiki calls them tags.
Wiki pages can also be grouped in parent-child relationships. It's fairly easy to make a switchboard page with a navigation tree to each topic. Depending on the Wiki solution you use, the navigation tree can be auto-generated.
Wiki makes it easy to have links to other Wiki pages, attachments, downloads or external reference material. If you have a YouTube video that's a great reference, you can embed it right on the page. You wouldn't dream of doing that in Word Documents. Even though it's technically possible, it doesn't print and it relies on an Internet connection that you can't be sure the reader has. With Wiki, you can be sure embedded reference material will display fine.
|Jesus Alonso Abad|
|Andrea Di Stefano|