Just Write Click

Technical writing with Continuous Integration and docs-as-code

  • JustWriteClick
  • Contact
  • Books by Anne Gentle
  • Introducing Docs Like Code
You are here: Home / talk.bmc / Wikis for technical documentation, one writer’s story

April 20, 2007 by annegentle

Wikis for technical documentation, one writer’s story

An interview with Emily Kaplan, a technical writer and former co-worker of mine, who maintains a wiki for Motorola

A good friend of mine, Emily Kaplan, was kind enough to let me interview her via email to find out more about her experience with managing a wiki for technical documentation. She writes for the Motorola Q phone. Back in November of last year, just in time for holiday shoppers, the Motorola Q was on the cover of October’s Wired Magazine special issue (Wired Test). Here’s the article: http://wired.com/wired/archive/14.10/play.html?pg=14. Here’s a link to the Q wiki: http://www.motoqwiki.com/index.php?title=Motorola_Q_Wiki. An excellent starter reference page is found at http://www.motoqwiki.com/index.php?title=Motorola_Q_Wiki:About

Emily says “I’m a senior technical writer contracting with Motorola. My group has about six writers, an editor, and a graphic artist. We’re spread across state and national lines in Illinois, Florida, and the U.K. We write user’s guides for the high profile mobile phones that you see everywhere. (We have a sister group that produces the in-device help and videos.) I go to the office once a week and work from my house the rest the of the week in my pajamas.”

Here are the questions I asked her, along with the answers. I am trying to find out more about real experiences with wikis for technical documentation. The concept of wikis for technical documentation and user-created content was mentioned recently at the Writer’s User Assistance conference as the future of online help systems in the session “User Assistance Trends Panel: What’s Ripe, Hype, and Out-of-sight.” The panel consisted of Rob Houser, Dana Chisnell, Paul Mueller, Bernard Aschwanden, and Joe Welinske. By learning from others experiences, perhaps we can avoid pitfalls or craft best practices.

Anne: What types of information (concept, task, or reference) goes on the wiki, and did you pre-populate the wiki with certain basic information?

Emily: The foundation for the MOTO Q wiki was the user’s guide, which has mostly tasks and some reference types of info., such as diagrams of the keypad and how to insert a memory card, etc.

Anne: What are the main goals for the wiki – customer support, customers making connections on their own, community building, or using it as another way to publish information that customers can get elsewhere?

Emily: The main goal of the wiki was to provide customer support. Some users lose their manuals or don’t keep them or want to learn the latest details that might not be in their manuals if they have upgraded their software. Secondarily, customers can share information, which builds a sense of community. Not as much as a blog or user forum, but a little.

Anne: What type of maintenance do you perform on the wiki?

Emily: So far, I’ve had to do a product name change and also add new sections as new features have been developed. I do not touch any customer input, and we haven’t had to deal with malicious users.

Anne: Does wiki maintenance require more work on navigation or on content?

Emily: I haven’t touched navigation at all, only content.

Anne: Have you discovered a core group of users taking the wiki content under their wing?

Emily: We have two users who regularly add information for Verizon-flavored phones. Other user-based sites for this phone exist already, so they might be going there instead.

Anne: What feedback have you received from customers, if any?

Emily: I haven’t been involved with user feedback for the wiki.

Anne: Was there a customer request for a wiki or did the business decide to do this on their own?

Emily: One person in the marketing group spearheaded the idea. There wasn’t a customer request because it was a brand new product, but the type of product (a computer-like phone) suggested that the average user might be more web savvy than for other phones, so it was a natural thought progression.

Anne: What is the business justification for building the wiki?

Emily: It’s fast, cheap, and easy to maintain. And it reaches potentially millions of users. Like everyone else, we’re trying to reduce paper docs, and this is one attempt…

Anne: What underlying technology does the wiki use? MediaWiki? (That’s what it looks like to me, anyway.)

Emily: It is indeed MediaWiki. It also uses a SQL database in the backend for some user information.

And a bonus question/answer!

One of the downsides of the wiki that we haven’t been able to address yet is that we have many flavors of the MOTO Q phone coming out. These are phones that have totally different keypads and some unique features. We haven’t figured out how to reuse the info. or if we even want to create more wikis. (We’re talking 7 or 8 varieties right now.) Anyway, a dilemma…

At BMC, we do have user-generated content and are always looking for more ways to connect fellow BMC product experts. We have forums on BMC DevCon as one place for expert users to share advice, tips, tricks, and so forth with others. And, you can ask other users questions there, and our support staff chimes in as well. AR System has had an active developer community for years and the current site can be found at http://www.bmc.com/arsystem/dev_community/. TalkBMC is yet another place for us to connect with users, and give users the chance to let us know their experiences, and hopefully offer advice as well.

What do you think of wikis for technical documentation? Would you like contributing what you know? Let us know.

Related

Filed Under: talk.bmc Tagged With: MotoQ, Motorola, wiki, wikipedia

More reading

Bubble graph showing sources of developer support data

I’ve been thinking a lot about developer support at Cisco recently, especially for the way the world works today with multiple cloud providers. This post is a re-publish of my talk from over five years ago, but the techniques and tools for listening and helping others are still true today. At Rackspace, we watched several […]

Cisco DevNet is our developer program for outreach, education, and tools for developers at Cisco. From the beginning, the team has had a vision for how to run a developer program. Customers are first, and the team implements what Cisco customers need for automation, configuration, and deployment of our various offerings. Plus, the DevNet team […]

I had a great talk with Ellis Pratt of Cherryleaf Technical Writing consulting last week. Here are the show notes, full of links to all the topics we covered. Podcasts are great fun to listen to and participate in, if a bit nerve-wracking to think on your feet and make sure you answer questions succinctly […]

At the beginning of this year, I worked hard to summarize my thoughts on API documentation, continuous publishing, and technical accuracy for developer documentation. The result is an article on InfoQ.com, edited by Deepak Nadig, who also was forward-thinking in having me speak to a few teams at Intuit about API documentation coupled with code. Always […]

Recently on Just Write Click

  • A Flight of Static Site Generators: Sampling the Best for Documentation
  • Try a GPT about “Docs Like Code” to ask questions
  • Discipline and Diplomacy: Docs in the Open
  • Let’s Find Out: When Do Static Site Generators Do Rendering?
  • GitHub for Managing Tech Docs

Just Write Click in your Inbox

Enter your email address to subscribe to Just Write Click and receive notifications of new posts by email.

Read More

  • Privacy Policy
  • About Anne Gentle, developer experience expert
  • Books by Anne Gentle
    • Conversation and Community
    • Docs Like Code, a Book for Developers and Tech Writers
  • Woman in Tech Speaker Profile
  • Contact

Books

  • JustWriteClick
  • Contact
  • Books by Anne Gentle
  • Introducing Docs Like Code

Copyright © 2025 · WordPress · Log in