Subscribe to RSS
Posts Tagged ‘customer feedback’
Community support - don’t think of yourself as a customer but as a member of a movement
I’ve signed up for the Give 1 Get 1 program for One Laptop Per Child, and just received the email today, November 12, 2007, with the link to the site, www.laptopgiving.org.
I read the terms and conditions with interest because I am seriously considering purchasing a laptop either for my son, who is four, or for his classroom of four-year-olds. Plus, I’ve been volunteering to help with their end-user documentation.
I’d love to buy one for every classroom at my son’s preschool but that’ll take some fundraising. I’ll boldly propose here that you can contact me if you’re interested in buying enough for a small preschool in Austin, Texas in addition to kids in least developed countries around the world.
I absolutely LOVE the spirit of the support statement. It reads as follows:
Neither OLPC Foundation nor One Laptop per Child, Inc. has service facilities, a help desk or maintenance personnel in the United States or Canada. Although we believe you will love your XO laptop, you should understand that it is not a commercially available product and, if you want help using it, you will have to seek it from friends, family, and bloggers. One goal of the G1G1 initiative is to create an informal network of XO laptop users in the developed world, who will provide feedback about the utility of the XO laptop as an educational tool for children, participate in the worldwide effort to create open-source educational applications for the XO laptop, and serve as a resource for those in the developing world who seek to optimize the value of the XO laptop as an educational tool. A fee based tech support service will be available to all who desire it. We urge participants in the G1G1 initiative to think of themselves as members of an international educational movement rather than as “customers.”
I’ve been working on documentation for the XO laptop in the wiki at wiki.laptop.org/go/Simplified_user_guide and then taking the wiki content over to an Author-it instance. I’ll write more later about a wiki-based workflow, especially with translation in mind, and we are putting a process in place. Please, feel free to edit that page or contact me if you are interested in contributing.
Personally, the most difficult part so far has been my limited ability with design and layout. I have grand visions but feel my layout skills are inadequate for a kid- and parent-friendly look within Word. Nonetheless, it is an exciting time to be a small part of such an influential project.
I’m one of the friends, family, and bloggers who is willing to help with the XO laptop. So I urge you to go to www.laptopgiving.org and put your U$399 to good use.
Interview about wikis for tech doc with Dee Elling of CodeGear
While researching my STC Intercom article about wikis and technical documentation to be published in a few months, I interviewed Dee Elling via phone and email because she left a helpful comment on my talk.bmc.com blog entry about a DITA and wiki combo. Dee’s the manager of the documentation group at CodeGear and she blogs at http://blogs.codegear.com/deeelling/.
Anne -What are some of the factors for selecting a wiki software package?
Dee -I’ve encountered hesitation from some writers about using a markup interface. Many writers preferred a Word-like GUI interface, such as Confluence provides. Another consideration is cost, since there is not always a budget for new systems; at CodeGear we use MediaWiki. Primarily we manage internal information such as schedules and doc plans; lately we are collaborating with engineers to write FAQs and release notes.
At my previous employer, one engineering team was writing the documentation themselves on the wiki (using outlines provided by the writer), and the writer cleaned it up and converted it to PDF for distribution with the product. That is a great use case which I believe could seed the adoption of wikis into the documentation process, especially in companies where there are limited doc resources.
At CodeGear I can post copyrighted material to our Developer Network. The Developer Network technology allows comments on postings, which is not the same as wiki but a good start. Since joining, I have started to post traditional doc content as “articles” there. I’ve already fixed a few doc issues due to rapid customer feedback! We are also working on a design to make the website interface more wiki-like.
Anne -How do you get legal approval for such an open-edit site?
Dee -At my previous company I never got to the stage of implementing a public wiki. However I had many discussions about the legal aspects elated to the product documentation. The legal aspects seem complex, but lawyers can write new terms for new situations.
At CodeGear the issue will involve intellectual property, but the user base is so active on the internet that there are few “secrets”. More important will be the issue of releasing information too soon or otherwise getting in trouble with SOX compliance. (That makes my head spin!)
Anne -What are the considerations when choosing where the wiki is hosted?
Dee -Cost and reliability are factors, but most important is buy-in from the IT department, who would likely manage the hosting.
Anne -Which types of products are best targeted for a wiki?
Dee -Complex software products are a good example. There is so much flexibility in software and product documentation cannot cover every use case. The wiki lets customers add content that is relevant to their own use cases, and that will benefit others.
Anne -How can you encourage your users to contribute?
Dee -Keeping up a dialog with the customers is helpful. If you respond to them, a dialog develops, and they are more likely to contribute again.
Anne -What are some of the success factors for the wikis that contain
technical documentation?
Dee -Does it result in more positive feedback from customers? Do customers help each other and contribute to strengthening the installed base? Does it increase product visibility and mindshare in the market? Is it perceived as a strategic advantage over competitors? Does it cut down on tech support phone calls?
Anne -What traps should be avoided?
Dee -The trap of not responding or not paying attention. Writers must diligently track the “living documents” they have created, and they must truly collaborate. If customers contribute and their contributions go unrecognized, they may think that the company is not fully supporting them.
Public wiki documentation must be actively managed and that takes more writer effort than in the past, when documents were forgotten as soon as they went to manufacturing. Contrary to the fear that with wikis you don’t need writers anymore, I believe that with wikis the role of the writer will grow.
Thanks so much for your help, Dee, and for sharing your experience with all of us who are interested in the best ways to harness the power of wikis for end-user doc.
