--- title: "Why I Returned to Wikis for Help Authoring" date: 2011-11-14 description: "$( document ).ready(function() { // Handler for .ready() called. $(" canonical_url: https://idratherbewriting.com/2011/11/14/why-i-returned-to-wikis-for-an-authoring-platform/ --- # Why I Returned to Wikis for Help Authoring Last week I was feeling a bit stretched out about not having enough time to accomplish everything I needed to do. Granted, I gave several webinars to a total of 2,000 people, which was somewhat stressful, but I was more stressed about the fact that the help material I'd created could have been much better if I had only more time to focus on it. And it wasn't just help for one product, but about ten others as well, simply because I didn't have the time to provide the detail and attention the documentation needs. It's not because I'm lazy. I've actually become somewhat of a workaholic, working on weekends, sometimes a little in the evenings. The problem is that there simply aren't enough technical writing resources for the work we do. This situation was taxing my patience, and I started to think of the immediate solution: hire more people. I already mentioned that we have [one opening](https://idratherbewriting.com/2011/11/08/senior-technical-writer-job-opening-at-the-lds-church/). This is just back-filling a position from a writer who left. But we need about half a dozen more writers, in my opinion, to do a good job. I thought about trying to hire interns, or trying to recruit full-time volunteers. While I thought of these staffing solutions, I also thought of other things I have heard our leaders say. *We have to find a way to meet the demands of a growing membership without commensurately staffing up*, some said. And another: *If you set your goals higher than you can achieve, you will change your methods in a way that allows you to achieve them.* While I liked these ideas, I didn't have a clear idea of how to move toward them. I was constantly working in crisis mode, trying to cross off the top three items from an ever-growing list of tasks each day. As if the documentation challenges weren't enough, I had also taken it upon myself to do marketing for technology products across departments. I fished for tech news information in every corner I could find-- forums, RSS feeds, intranet content, email lists -- and then worked with volunteer writers and subject matter experts to get the articles written. I greased the approval system, learning how to navigate the large number of checkpoints with skill and prowess. Despite some successes, I realized I couldn't move in two directions at once, both playing documentation and marketing roles for so many products. I needed a way to scale without  simply growing our team with more full-time resources. A Glimpse of the Solution Just last week, I felt like I caught a glimpse of the solution. I have a group of 60+ volunteer writers eager to help out. (I wrote about the [challenges of managing volunteers](https://idratherbewriting.com/2011/11/06/managing-60-volunteer-writers/) last week.) In fact, there are hundreds of church members (as well as non-members) out there who are eager to serve and volunteer for LDS Church writing projects (I work for the LDS Church). I hadn't  leveraged their efforts except for the marketing side of tech, writing articles for the blog about new releases, updates, and other technology topics. I didn't have them creating documentation because I saw these as separate efforts. And then it hit me: These aren't separate efforts. 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. And what platform would allow 60+ volunteers to contribute writing and editing? The traditional help authoring system we were using didn't seem adequate. The cost per license and lack of availability outside the firewall made it impractical as a collaborative volunteer platform. About the only platform that works in this situation is a wiki. [![Why I Returned to Wikis for Help Authoring](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/wikis.png)](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/2011/11/wikis.png) One of my colleagues explained that volunteers could write in Word templates and then send me those templates. I could then import the templates into the help authoring system and generate help material from it. This was a system he had used in the past for internal SMEs who wrote content. While this could work, he acknowledged that the process would be somewhat impractical. One of the problems is that we don't have a set of number of official products we document. If you look at this [list of categories on LDSTech](http://tech.lds.org/wiki/Special:AllPages/Category:), our users have questions that span across products, departments, and roles. There are dozens of different topics, sites, tools, resources, applications, processes, methods, issues, and other areas that users have technical questions about. Would I create a new project to publish information about each one? The most feasible platform to accommodate such an information ecosystem is a wiki. ## Pros and Cons of Wikis I have to say that, in general, I really like wikis, especially Mediawiki. 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. Here are the main advantages I see with wikis in my authoring situation: - **Wikis scale infinitely.** Mediawiki is actually free, and it supports an infinite number of users. You don't have to shell out $1,500 per license. People can just log in and start authoring. It scales to support a growing user base. - **Wikis remove authoring complexity.** Some help authoring tools require a lot of tinkering before they make sense to users. In contrast, adding content to a wiki is fairly straightforward. It's a matter of asterisks and pound signs and equal signs, for the most part. There is some syntax to learn, but it's nothing prohibitive. This is essential to expand the base of authors. - **Wikis allow collaborative authoring.** When you have multiple people working on the same content, nothing is easier than a wiki to facilitate this collaboration. Mediawiki even allows more than one person to work on the same page at once, and is smart enough to handle simultaneous commits of the same sections. I mentioned that I've tried using wikis before. Some of the reasons I abandoned it previously include the following: - Wikis don't allow you to single source the content. - Wikis are poor at translation. - Wikis don't get enough edits from users to justify the platform. I want to address some of these objections, if only to provide notes for myself. Although many people don't realize it, content re-use in Mediawiki works much the same way as it does with help authoring tools. If you put content in a template, you can re-use that template in any other page as much as you want (it's called transclusion with Mediawiki). You can also embed pages inside of other pages. What you can't do is easily push the content to a nicely printed manual or do other multi-channel publishing (at least not with Mediawiki). You could, however, come close by embedding pages in a specific order and then customizing the print CSS stylesheet. But in all the feedback I've seen on forums and through email, I have yet to come across a request for a printed manual. I do often create one-page quick reference guides that people can print. These seem to satisfy the need for a print experience of documentation. With translation, while help authoring tools may package up all the essential files and make it easy to export and reimport those files, I don't think wikis are impractical for translation. Look at [Wikipedia](https://www.wikipedia.org/), after all. How is it available in so many languages if wikis aren't suitable for translation? What's more, wikis allow for community translation in a way that help authoring tools usually do not. Many people from the community can work on translating pages, and they can translate as much or as little content as they want.