[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Feedback on the updated troubleshooting tech paper
This is a worthwhile revision of the original tech paper . . . my compliments. I have a few friendly suggestions to consider for addition: 1. Collaboration gateway: Individual troubleshooting topics are certainly useful, but the real value of investing in focused troubleshooting content has lots more to do with collaboration across organizational barriers than building out some separate library of documentation topics. Organizations that are large enough to consider DITA certainly have technical support, customer support, or field sales organizations who have been developing diagnostic and troubleshooting information for years. Whatever the tech pubs team might think are useful XML content models for troubleshooting information is secondary to leveraging the logic and substance of existing troubleshooting content developed in other organizations. 2. First steps: Section 3 of the tech paper doesn't mention the primary business justification for developing troubleshooting content -- reducing the number of customer support calls. IAs and managers planning to develop an initial library of troubleshooting topics should buy the head of customer support lunch and ask her/him for a list of the 50 most frequent support issues. Some 30 or so issues are most certainly suitable to be worked into DITA troubleshooting topics. It's a win-win. Support can now feed the tech pubs team all sorts of field-tested content and the writing group can get on the scoreboard with some proven content. Rewriting existing Support content also helps writing teams shake out their XML templates and metadata. Not every writer is is strong in this area, so managers need to vet the writers as well as the writing. 3. Collaborative design: Under the hood of the most popular knowledge managements systems supporting KCS (Knowledge-Centered Support), you find very similar fields and views for diagnosing and solving customer issues. Adding yet another set of fields (XML element names) on top of the existing ones doesn't make that much sense. Why not recast the DITA content models to adopt the names of the KCS fields that are already familiar to the organization. Yes, there would be little consistency between the XML troubleshooting elements in Company-A or Company-B, but so what? 4. Structured information exchange: Most any engineering grad student would be able to write converters between structured database records in KCS systems and DITA XML troubleshooting topics (especially if they share many of the same field/element names). Similarly, adding adding specialized DITA elements that correspond or link to non-DITA support or escalation tickets would be huge. DITA troubleshooting content should be an extension of a corporate content strategy around troubleshooting information. Finding ways to emphasize that role in the tech paper would be good. Using the troubleshooting topic type as a calling card for collaboration and not as an end in itself makes business sense. DITA is late to the party. It has been easier for Support organizations to publish troubleshooting information or FAQs out of their KCS systems than to educate tech pubs organizations on how to develop and curate enterprise-class support information. DITA is quite capable of playing nicely in this collaborative space (perhaps a different tech paper). Let's play to our strengths where we can.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]