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.
So what you're saying, and I think we've been down this way before, is that the writer should engage in the creation of a body of work, an encyclopedic body of work, for a particular product, with short topics in convenient chunks, and that is the information set -- and then intelligent inline hyperlinking and relevant external hyperlinking should be included, with a good search engine, so that the user can wayfind through the material to get what they need.
Is that in any way accurate?
In this way, any given user might navigate/use 1 percent of the information set, but the collective of users would justify providing 100 percent.
Well, good luck. Aside from the fact that this would seem to be a massive burden of time and money for companies large and small, you have the problem you identify of document-centric thinking. You're going against 500 years of the Gutenberg age; it's going to take several generations, at least, to purge that habit. Most of the people alive today were born and raised on the document tradition. Millennials can deal with it but millennials I've worked with and known have often wanted PDFs.
And by the way, PDFs and ebooks are very document-centric. You can inline-link the content of an ebook until the cows come home, and you're basically bouncing around the ebook, only occasionally leaving for a web site.
Add to this the fact that most people and/or companies *expect* documentation to arrive or be delivered in some document-centric form. Online help is often just an electronic version of the print manual. Same document centrism, same sequencing of material as in a book. Just adding some internal hyperlinks that don't go outside because of the proprietary nature of the material (and the opposite if it's more public).
Then add to this the fact that, as you've pointed out, most of the most important tools in tech comms are document-centric.
You've got a big slog. Might be 10-20, or 5 at the minimum years to get this going in a significant way.
Another thing is that, assuming the writer creates such a product encyclopedia, there is the business of maintaining it, and often things change dramatically even before the first version is complete.
But basically you're trying (in EPPO) to reproduce the experience of the web in product documentation. To imagine an online webhelp set that has even a tiny resemblance to the breadth and scope of Wikipedia or, even more boggling, the web itself, is a tough one, because you're very, very limited.
But let's assume you're right. Humor me for a moment, Mark, because I'd love to find a way to implement the concept, as it does seem to have promise.
I work in the medical device industry. Take one particular manual, an instrument service manual. Hundreds of topics for the online help. PDF output runs into about 2500 pages. Delivered as online help only (self-contained webhelp site, HTML5). The PDF is only used for internal shared reviews.
The majority of the "manual" (still using that term) consists of remove and replace procedures, for components, sub-components, and parts of the device. Also other procedures for cleaning, maintaining, upgrading, calibrating, aligning etc. the instrument, installing/upgrading/removing software, installing and uninstalling the device, dismantling, packing, relocating, and unpacking too. Then theory of operations, parts lists, checklists, and some other odds and ends. A pretty big set of task, reference, and concept materials. Also: About a thousand images, many enlarged to help the tech zero in on the right part. (Many with callouts too.)
The techs download and install the help set on their laptop and use it on site to service a machine.
So how would you propose I take this mass of information, and convert it to an EPPO information set?
It appears to me at least on the order of a DITA conversion, and maybe quite a bit more, because assuming the information is already divided into DITA-friendly topics, you're really converting from one content wrapper to another, let's say. The meaning of the content is already largely DITA-compatible. (And if not, I could easily split a topic's subsections into separate concept, task, and reference topics, as they're already largely arranged that way.)
But to convert this kind of (although non-DITA) format to EPPO, it would require much greater effort in assessing how to deal with the content via meaning.
If I'm taking a large quantity of content organized in a document-centric way, and reorganizing it into much smaller chunks a la an encyclopedia, that takes a lot of human-hours and brain power that you don't necessarily need if you're just copy/pasting, or saving-as.
So unless you can convincingly tell me how to do such a conversion, in practical terms, at low cost and low time -- and do the same thing for an Operator's Manual, by the way, which is similar but quite a bit smaller -- then EPPO, at least in this case or for this particular kind of product, will remain just a dream, and in fact the discussion is almost purely academic.
I'm not looking to make you wrong, I'm looking to make you right, but I just don't know how. And as much as you try, you're not getting me any closer.
It continues to baffle me too that you can't point us to any relevant examples where we can just look and say, "Aha, so that's how it's done! I can do this with my own documentation!"
Thanks,
Steve
PS - For a single product: Service manuals, operator's manuals, training manuals, and a parade of package inserts for the various diagnostic tests that can be run on the machine. How in the world are you going to link that all together a la Wikipedia.
On Tuesday, October 04, 2016 9:19 PM, Mark Baker wrote:
The difference is, you go to a play (presumably) for the sake of the play.
You don't read documentation for the sake of the documentation. The experience of the play is bounded by the intention of the playwright. The experience of documentation is bounded by the task of the user and what they need to glean from the whatever sources are available to them to understand their problem and solve it.
What John Carroll's research at MIT showed (I don't know how much more academic I can get than that) was that user's information seeking and information usage was not shaped or bounded by the documentation, but by their individual goal driven requirements. Information foraging theory came from a research lab rather than a university, but should not be discounted on that basis. It shows the same thing. Several other studies which I have cited in the book and in the article I have linked to point in the same direction.
Perhaps this is the expression that best sums up the difference between document thinking and hypertext thinking: Document thinking assumes that the reader's experience is bound to the document. Hypertext thinking assumes from the beginning that it is not, and that each reader will make an individual traversal of the information set in combination with other information sources and their own experimentation. This point is supported both by research (which I have cited) and by experience and observation in the marketplace and on the Web.
There are, to be sure, still cases where document thinking is appropriate (because the readers experience is indeed bound to the document). Novels are an example, and so are books like mine. So it is entirely appropriate to study appropriate design in the context of document thinking. But we have to be careful not to take conclusions from that domain and apply them to the hypertext domain where the reader's experience is not bound to the documentation but to the task.
Mark
-----Original Message-----
From: Janoff, Steven [mailto:Steven -dot- Janoff -at- hologic -dot- com]
Sent: Tuesday, October 4, 2016 7:48 PM
To: mbaker -at- analecta -dot- com; techwr-l -at- lists -dot- techwr-l -dot- com
Subject: RE: inline links (Re: Online help access question)
Well, a lot of thoughts since I first popped a look at your message and versus what I wanted to say, but some of it reminded me of this, bringing back an old memory that I had to look up.
A play called "Tamara" -- "the play you experience from room to room."
Debuted in an LA production in 1984, and I so wanted to get up there and see it but never got the chance to do so. Revolutionary for its time.
...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
