[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: EXTERNAL: [dita-techcomm] HP Troubleshooting and Proposed Troubleshooting Topic structure
I agree wholeheartedly with Rob. I have been a fan of the HP problem-solving Help model for many years. It is one reason I choose HP products for my personal use. Val
Senior Technical Writer Lockheed Martin Corporation | Information Systems & Global Solutions San Diego, CA 92121 760-845-1650 Cahn's Axiom: When all else fails, read the instructions. SAVE PAPER – Please do not print this e-mail unless absolutely necessary. From: Rob Hanna [mailto:rob@ascan.ca] I’ve just reviewed the HP models you sent out in May. I definitely believe that HP model fits with the approach I am exploring with Gershon at Cisco. The HP examples show a lot of mixed information types that can easily be reorganized appropriately into task, reference, and troubleshooting topics. The HP model describes three separate modules to help users solve problems: · Checkstep – for checking several possible causes of a problem · Message – for explaining error and other messages · Symptom – for identifying a problem from a set of symptoms The Checkstep module describes possible actions the user can take to solve a problem. There are two ways to address this with the proposed model: 1. The Troubleshooting topic provides for a list of actions the user can take to resolve the problem. However, it does not describe how to perform those actions. The actions assume that the how-to isn’t important. In cases where the how-to is important, we use 2. The Resolution task topic to follow explicit steps to resolve an error situation. This resolution task may be common amongst many troubleshooting situations. The Message module describes error messages the user may encounter while using the product. This is reference information and should use the properties table to list and describe error messages. Unlike the Message module described in the HP model, the proposed model wouldn’t include task information as part of the message description. The message itself would be referenced inline within the troubleshooting topic as a symptom of the error condition. From this topic, the user would learn what actions to take or steps to perform to resolve the issue. The Symptom module very closely matches semantic substructures of the proposed troubleshooting topic. The proposed troubleshooting topic structure is attached. Rob Hanna From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com] Hello All, Don't forget our committee meeting Monday, May 2. You should already have the Outlook notice. I've attached the material I promised about the HP Problem-Solving information type. We'll review tomorrow in our continued discussion of troubleshooting topics. JoAnn JoAnn T. Hackos, PhD President Comtech Services, Inc. 303-232-7586 Joann.hackos@comtech-serv.com |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]