--- title: "Turning Point (Wikis)" date: 2012-06-17 description: "My journey to and from wikis 1.0 My Journey To and From Wikis: Why I Adopted Wikis, Why..." canonical_url: https://idratherbewriting.com/2012/06/17/turning-point-wikis/ --- # Turning Point (Wikis) The reasons, as I have stated, can be summarized in three bullet points: - Writing requires insider knowledge that volunteers lack. - Professional writing standards are usually beyond volunteer capabilities. - The management overhead in coordinating volunteer writing barely outperforms the return. This marked a turning point for me in using wikis as a collaborative platform. ![Turning Point -- maybe there's a better way to collaborate outside of a wiki.](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/turningpoint600.png) With wikis, I did like the publishing immediacy and the web interface, but Mediawiki had so many shortcomings that the platform didn't seem worth it without having an overwhelming need to collaborate. With Mediawiki, I couldn't publish to any other output other than web. With Flare and other help authoring tools, you can publish to PDF, Webhelp, EPUB, Mobile, and more. Given the proliferation of mobile and tablet devices, it seems that technical writers will need to master multi-device publishing if they are to remain relevant. With that, I switched back to help authoring tools and wrote a post, [When Wikis Succeed and Fail](https://idratherbewriting.com/2012/05/23/wikis-are-dead-other-options-for-collaboration/). [![](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/fromwikis-to-single-authoring.png)](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/2012/06/fromwikis-to-single-authoring.png)Switching back from wikis to traditional help authoring tools ## Time for Another Model: Testing Documentation Despite my apparent failure with wikis and engaging volunteer efforts, I have not thrown in the towel on volunteer efforts. I do think another model may be more productive: crowdsource documentation testing. Our biggest success in LDSTech by far has been with testing rather than development. Testing a software application across the variety of platforms (iOS, Android, BlackBerry, Windows), carriers (AT&T, Verizon, T-Mobile), locations (North America, Europe, Africa, South America), roles (clerks, bishops, stake presidents, auxiliary leaders, members, website administrators), computers (PC, Mac, other), operating systems (Windows 7, Windows 98, Mac OS, Linux), browsers (Opera, Safari, Chrome, Firefox, Internet Explorer 6,7,8,9), and scenarios (so many possibilities) is pretty much impossible to do in-house. The in-house quality assurance team can test general load and general requirements for the software, but testing all of the possibilities of user experience proves impossible under normal budgets. Because of the success with testing, our team decided to build a tool that would facilitate more directed testing. The tool was just released a couple of weeks ago, and it's still very new. But here's how it works. The testing lead enters a list of specific test cases he or she wants the crowd to test. Users can respond to the test cases with pass/fail options. If the user marks the test case as fail, he or she is prompted for a reason why. The failed responses are automatically appended to JIRA items. When multiple volunteers report a failure for the same test case, the failures are appended to the same JIRA item, thus removing the chaotic mess in the forums where responses about bugs appear across a variety of threads. ![This is the Swarm model of testing documentation with the crowd.](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/Swarm-diagram.png) The tool was designed for testers to test software functionality, but it also works with documentation (documentation is, after all, part of the product). Each task functions similarly as a test case in software. If users cannot complete the documentation's steps, they can mark the task as fail and explain why. For the following reasons, testing documentation may prove to be the biggest win for writing within the community: - Testing documentation does not require insider knowledge. - Testing documentation does not require professional writing skills. - Testing documentation does not require a lot of time from volunteers. Additionally, through the crowdsource testing tool, which we call [Swarm Tester](https://tech.lds.org/wiki/Swarm_Tester_help), the feedback can be neatly organized. ## First Experiences with CrowdSource Testing Although it's still too early to tell, my experience with crowdsource documentation testing has been positive. I am getting just the kind of feedback that I truly want. With one of the applications we have help for, I created a link to each individual task. The application was rather light, so I just created about 25 links. The test cases outlined that people should test the steps in the documentation. If tasks did not have steps, users were to test the clarity of the information. ![These are all the test cases in Swarm that volunteers test.](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/swarm-test-cases-600x515.png) It's only been about a week using this model, but so far I've found that many participants who didn't write articles did in fact participate in reviewing the documentation. Their comments were helpful and on target. I hadn't updated the application's help for about a year, so there were clearly some parts that were out of date. Interestingly, one team member decided to simply update the inaccurate information directly on the wiki, because, after all, it was editable. Most of the others, however, made recommendations for changes. Within a week, about six different volunteers tested the documentation in ways that proved very helpful.