Notes from 56th International STC Conference
Atlanta, Georgia, May 2-5, 2009

Climbing the Levels of Collaboration

Anne Gentle, Just Write Click

Session Description: Groups can take action quickly thanks to tools that amplify group communications such as blogs and wikis. Three hands-on examples that illustrate levels of collaboration: information-sharing, cooperation, and collaborating with a “book sprint.” Advanced session.

• Opening exercise
   
• Session started with a 3-minute exercise where individuals had to design a mode of transportation that met 4 or 5 basic specs.
• Next step is to break out into groups of 4 and specialize in the braking system, restraint system, propulsion system, and appearance. Integration.
• Groups shared designs.
• The point of the exercise: forced specialization focused different groups’ energy into one area of the design, not the entire design
• Starting individually was tougher; stimulation of group produced better results
• Classic levels of collaboration
• Information sharing using media like F2F, phone, e-mail, and IM. Includes classic writer/SME interface
• Cooperating: agile development practices, crowdsourcing, computer-supported (social web-enabled). “Time-boxing” ... forced time limit in solving a problem; keep repeating the exercise to force refining the design
• Wiki = Hawaiian for “quick”
   
• Lets anyone edit a page simultaneously; some wiki engines actually try to merge the editing to the maximum extent possible (pseudo real-time version control)
• Allows cross-platform, cross-browser networking and exchange
• It is NOT just Wikipedia
• Wiki growth ... easy to add users, bring more SME and skill sets to bear on the design or issue
• Collaboration benefits
   
• Encourage crowdsourcing
• Scalability goes up and up
• Online identity
• Some wiki engines also have “talk-page” feature (like real-time IM between wiki participants)
• Wiki matching
   
• ROI by reducing customer support phone calls
• Sometimes a customer forum isn’t enough
• Open source products often use wikis
• What a wiki can’t do
• Don’t go on wiki suicide missions (Wiki for Dummies)
• Don’t put off collaborating with wiki engine research
• Must have a strong guiding hand and innate talent and commitment
• Motivating community contributions from online collaboration
   
• Reputation: provide recognition for wiki participants; also a broad forum
• Reciprocity: what do people receive in return for working on your wiki? Users could accrue points in exchange for a T-shirt, conference fee, etc.
• Attachment: Shared vision and commitment provides motivation
• Efficiency: How do people save time by contributing to the wiki (e.g., SME answers question once, not 10 times)
• Do you have to use a wiki?
   
• First, listen, participate, join a community; join RSS feeds, check out what existing online communities are doing
• Wikislices: Infoslicer: can search for an extract certain portions of a wiki’s database. Could be used like informal single-sourcing to put together portions of documentation or another communication product
• Feedback loops to your source files: make sure information always comes back to the source files. Writers use DITA; users’ data can be extracted, merged by writers into documentation as appropriate
• FLOSS Manuals wiki
   
• Why did you choose a wiki?
• What type of wiki are you using?
• How are you using the wiki?
• What changes have you seen as a result of using the wiki?
• Data can be extracted from wikis, remixed in various combinations, converted to .html, and published
• Book sprint: wiki can be used for collaborative writing exercises (e.g., 10 authors could produce a book in a week)
   
• FLOSS Manuals wiki and community
• OLPC and Sugar Labs
• Firefox and more
• Must begin with a planning session, outlining (storyboarding); establish personal relationships, esprit de corps, and common vision
• “Scaffolding”: pages are blank but can be filled up progressively by multiple contributors
• You have to search out the right SME’s, “load” your team
• Need seed money to fly authors in, lodge them, feed them, etc.
• Find organizations that are willing to donate existing information, articles, etc.
• Digital Foundations: graphic designer led book sprint to assemble a guide sutdnets could use to create graphics using entirely downloadable freeware
• Book sprints are a good match with Agile (e.g., a quick review/edit of an entire document in one day)
• Wiki patterns
   
• Steward Mader’s website and book of the same name are extremely helpful for spurring wiki adoption
• Patterns describe a certain solution to a problem in context.
• To avoid problems, you want to follow a model pattern or be on the lookout for anti-patterns (e,g., “bullying” of a low-credentialed but high valuable contributor)
• Wiki best practices
   
• Establish a working draft area and a “published” area … don’t force authors to display their “dirty laundry” (very early drafts, etc.)
• Write a wiki style guide: authors will do some of the work on ensuring common style
• Give training on the wiki and a sandbox area … a practice area
• Maintain rules for arbitration … sometimes an argument can ensue on how a certain information module (wiki page) should look. Like a real-time war on Wikipedia. There has to be a final authority on what will be published.
• Offer original content, update content
• Beware of spammers, and back up often
• Join the community ... tech writers must develop an online persona, be part of the team
• Recruit reviewers ... tap into SMEs’ knowledge by asking them to review, rewrite, etc.
• Maintain categories
• Watch recent changes
• Expect small percentage of contributors and value them highly (90-9-1). 90% read, 9% make comment, only 1% digs in and makes a significant contribution
• Resources:
   
• Wiki tools research at wikimatrix.org
• Wiki patterns website for adoption and people patterns
• Meatball wiki
• Answering Tough Questions about Wikis podcast on TechWriterVoices.com
• Feathers.wordpress.com – technical writer at Confluence (product)
• JustWriteClick.com – wiki category
• FLOSS Manuals at flossmanuals.net
• Contact information:
   
• www.justwriteclick.com
• annegentle@justwriteclick.com
• What about conflict between e-mail and wiki in user preference? Project lead must force use of the wiki by putting all information there.
   
• Improve the effectiveness of their internal process
• Enrich their customers’ experience with their products and documentation
• Examples of improving process efficiency and communication
   
• Internal wikis to track projects with matrixed teams
• Wiki comment tools replacing meetings and doc reviews
• Internal and external wikis and globs to enable collaboration across groups ... and with customers.
• Why use wikis to develop docs?
   
• More than 1 writer can work on the same doc in real time so more content is created in less time ... configuration control is not rigorous until the doc reaches the final stages, at which point the pubs group takes ownership
• Ad hoc, immediate sharing
• Lightweight tools and tagging
• Lightweight production
• Wikis for a matrixed project team
   
• Need wiki tool that suits your team’s needs and working procedures
• Content changes can happen more quickly on a wiki than on a web site or paper
• Provide user-friendly, simple review wiki
• Wikis provide staging areas for docs
• Improving external customer deliverables
   
• Customer review and comment tool for beta documentation; informal feedback provides preliminary usability testing
• Other examples of using social networking to improve communication with customer: NOT to define the final version—the social element builds trust and credibility. This adds a dimension to the tech writer’s job—exchanges on the wiki demand a “persona” rather than just an anonymous writer/editor.
• A wiki manager is essential to track content.
• Collaborative environment for sharing knowledge and experience.
• Evaluating the wiki interface led the doc team to develop a task-oriented user interface (UI).