The dynamic nature of wikis can cause a few headaches when you need to baseline documentation that's on a wiki to correspond with the release of your product. This blog post looks at some ways in which you can try baselining wiki content.
User-generated documentation is a big issue in technical communication circles. If properly done, tapping into the knowledge of users can improve the quality and breadth of your documentation.
So how did the wiki become a seemingly permanent fixture in the landscape of today’s Web? Which wikis have succeeded as technical documentation, and how can we replicate their success?
This is the fourth in a series of posts from Atlassian's Technical Writing Team focusing on using a wiki for technical writing. Last week, Sally Hawse wrote about time-saving ways to re-use content. In this post, I'll be talking about how to manage the documentation release process using Confluence.
Good documentation about new sites, tools, and resources can be used for marketing efforts. Marketing and documentation don’t need to be separate efforts. I could leverage volunteer enthusiasm for documentation and then pull highlights from the documentation to post as news for the blog. Wikis have so many advantages that it’s hard for me to understand the case for traditional help authoring systems when you need a collaborative authoring environment.
Many people have predicted that wikis will replace traditional help in the future. Ok, I can buy that. But I've also heard that technical writers will surrender content control to SMEs and users, and will move into other roles such as merely editing wiki content, or switching to programming, training. Sorry. I just can't see that happening. In the world of wikis, technical writers will still be kings of content.