To search, or not to search
Professional technical writers create documentation around a product or process; User Guides, Training Materials, Field Service Guides, etc. Basically documents you read because you have to, not because you want to.
People go through product documentation looking for a specific topic using one of two approaches. They either browse if they’re not sure what they’re looking for, or they search if they are. Browsing works if you have the luxury of taking your time to peruse a lengthy table of contents (if you’re lucky), or an “organized” list of FAQs (if you’re not). If they’re in a hurry, people will tend to use a search function if it’s available, and then hope for the best. It’s also likely that someone who is going through user documentation is already in a bad mood, because something isn’t working they way it’s supposed to. Not finding the information you need quickly is unlikely to improve the end-users mood, so by the time they default out of frustration to customer support the company that built the product is well behind the eight ball.
Assuming most information (particularly about technology-centric products) is created and delivered in a digital format, it’s also reasonable to assume it’s delivered over the web. It’s also reasonable to assume the ubiquity of the web (it is essentially as widely available as wireless infrastructure, which you can get nearly anywhere, anytime).
So if it’s possible to provide information without delivery limitations, the question is how to provide precise product information; that is, not millions of answers to a query, but provide the correct answer to a question. Or take it up a level; not just provide a text response, but include query results in a variety of rich media formats that may be better suited to the end-users need for information.
It is now possible to provide a precise text response to a product query; assuming the text has been rendered in XML, or better yet, the text reflects documentation standards such as DITA (Darwin Information Typing Architecture) where all technical information is organized by topic down to a very fine level of granularity. This standard is what allows companies to provide an exact answer to a technical question (e.g. a Field Service Technician asking (how do I upgrade the motherboard on a Siemens MRI Scanner model # blah, blah). The docubase for that particular machine is stored in an object database, and organized by topic. Since the query is specific to a procedure (or topic), the query engine pulls out the relevant references across the entire database, and organizes the information by topic and sub-topic, on the fly. This is referred to as Filtered Publishing. No more thumbing through a 10,000 page manual (literally, at least—the flight manual for a Boeing 747 is over 1.2 million pages long). This is a huge improvement over the hard copy experience all of us have suffered through, but we are still one step short of the promised land: one question, one answer, delivered anywhere, anytime, in any relevant media type, to whatever form factor is most convenient to the end user.
So how do we get there? I’ll start on that on the next blog.