Adam Dales, Siemens PLM
Documenting Tecnomatix (and some features of Teamcenter) applications over the years, I have heard about our customers asking for help content tailored to their own use cases. Deployment engineers in our organization did an extensive survey of our various customers—turns out that there are about a 1,000 use cases waiting to be written. How do we write them all?
Ever Happen to You?
A go-getting product manager had just returned from visiting a large client in France. During our meeting on the Release Notes, unrelated to his trip, he pushed a smallstapled stack of A4 pages towards me and asked ‘how come we can’t do that?’ It was a printout of a 10-slide PowerPoint that an engineer at the French company had quickly put together, copying/pasting from our help, with some editing, a few added screen shots, some copies printed… and voila! Customized help that fit their actual working situation, distributed to the relevant engineers.
To further complicate the issue: Many of our customers use a number of applications that our greater organization produces. We have customers who design manufacturing processes using three of our applications in one workflow. But I only document one of them, with no real expertise in the other sectors’ offerings. But our customers, with licenses for all these applications, are using some aspects of each one to get their work done. So their across-the-board knowledge surpasses ours, the documentation specialists, and none of us can cobble together the comprehensive workflow documentation they require. Now multiply that by 1,000 use cases! Who will do it?
We need to be able to put our documentation into the customers’ hands, and let them take it from there! A lot of attention has been given to wikis, like the one maintained by Autodesk, as a solution for help customization by users. Though this is a promising direction, as described in the Notes at the end of the article, wikis have significant limitations that don’t allow full user-tailored documentation.
Look to Collaborative Communities
Siemens PLM has recently launched a public community collaboration site, and now I believe it’s possible to suggest a We Write/They Write solution. Our company’s public site will be securely partitioned into private communities for each of our clients, each with their own exclusive access (as well as to our administrators, community managers, and tech pubs people). Each of these private silos could be set up to allow users to access all of our help documentation sets across the board and to search any or all of them at once. We can provide the infrastructure for extensive search by applying metadata tagging to the content of all the documentation, supplying several thousand classifications. By thus underpinning the documentation with extensive taxonomies, we provide smart, faceted search options and instant delivery of very granular, targeted results. These finds are culled from all the document sets specified by the user, and listed Google-style: links, together with a line or two of description for each topic that comes up, as shown in Figure 1.
Users can then check to select the topics of interest that contain the step-by-step explanations that make up their workflow. After they click to generate the document, the site loads just the indicated topics into a text easel as a composite document. Users can then rearrange the content by dragging and dropping, edit the material with rich text features, and insert pictures and video links. Voila—they have assembled their own tailored use case using the relevant sections from the overall baseline documentation sets. Then choosing among the publishing and distribution options, users can quickly deliver their customized workflow to other members of the team (Figure 2).
There’s also a big added value of crowd sourcing that the organization can reap by “listening in” on each of the user help customization silos. Each client’s customized results serve its own needs, with no exposure outside of the partition. But our administrators/technical writers have access across our public community site, and we can glean material from the users’ reworked content. This in turn we can plow back into the baseline documentation, resulting in a continuous enriching synergy of we write, they write, we write…
Thanks to Joe Gelb and Suite Solutions for help in demonstrating the We Write/They Write concept, and pointing out a number of limitations in wikis, listed below.
Why Wikis may not be enough:
- There is no easy way to extract changes made on the wiki and incorporate them back into the source content.
- It can be difficult to control and authorize changes.
- They do not allow customers to build their own documents from multiple content modules.
- It is difficult to customize the format and usability of different types of content; it all looks and behaves the same.