TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
First, I'm not assailing what we do, or questioning it's value. I'm questioning it's efficiency.
Namely... given that the new paradigm for finding information is a sort of random searching on the Web, my question is really this: "How do we re-fashion our technical communications to match the user's behavior and/or mental model when randomly searching on the Web?" (To match their *experience*, in other words.)
Put another way, the user has a need and an expectation, and I want to try to match that by providing the information in a way that will "intercept" that random search to deliver the right info at the right time. Or something like that. (I'm not talking about presenting it on the Web -- it can still be contained in a self-contained system, offline or online or both.)
For example, I feel that the traditional "topic" as it is used in DITA and other standards, especially the task topic, is too long.
I feel that one way to get there is to write information in much smaller chunks. A topic should be the length of a dictionary definition or a smaller encyclopedia entry.
You then have to make these items easily searchable within your documentation system.
So you document a single chunk of information. You can have concept topics to tie it all together, and those should be available at the user's request -- handy, but not obtrusive. The chunked information should be the most readily available.
For example, suppose I want to "Reply All" in Outlook (if such an explanation were really necessary): I only need a quick description of what that does and how to do it, not a step-by-step task topic. I mean, really now... how much do I need on that? And it should be eminently searchable or findable in my system. Via TOC, Index, search, whatever.
This is all about available time. I don't have time to read a full topic anymore. ("I" really meaning the average user here.) I want what I want and I want it now. I certainly don't have time to call a Customer Support line and try explaining the problem to somebody who really doesn't understand the product. As I'm sure you know, you can spend half an hour on a phone call that you can find an answer to on the Web in five seconds.
The point is, many/most/all of us are writing things that no one will ever read, just because people don't have time to "look it up." Our current "documentation" model doesn't seem to be working. Do you think it does? If not, isn't it time for something new?
This "nobody reads the manual anymore" is a long-time complaint but it's especially acute now, even with the refactored ways of delivering documentation, through DITA and friends. Doesn't matter. It's a new way to collect information and deliver it, not really a new paradigm. Minimalism and SGML are kind of old by now. The power of the technology is there but the presentation does NOT meet the needs of users.
So the idea is to address the new way of searching for and finding information, via our documentation itself. The current systems don't do that, at least not in a way that's satisfactory -- and as user behavior shows (anecdotally, at least -- maybe others can cite research).
Steve
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EPUB Webinar: Join STC Vice President Nicky Bleiel as she discusses tips for creating EPUB, the file format used for e-readers, tablets, smartphones, and more.
