For years I prided myself on single-sourcing both online help and printed guides. When I used RoboHelp, I created custom macros in Word to clean up and adjust the print formatting. With Madcap Flare, I hammered out the print styles until everything looked clean. And then I made a major mistake: I more or less single sourced the online help to the printed guide in a near 1:1 ratio.
One day a department manager told me he was preparing to give a presentation to new employees, and he asked me for the printed guide so that he could distribute it during the training and orientation. Sure, I thought. Because of the high visibility, I decided to print it out the guide and read it cover-to-cover to make sure I wasn't missing any typos.
The printed guide was about 175 pages. As I read through it, red pen in hand, I had two epiphanies. First, a lot of the topics didn't connect with each other in the seamless way you would expect from a print reading experience. This disconnect is probably the inevitable result of topic-based authoring -- topics aren't necessarily chronological, nor does one topic lead in to another.
Second, after reading 50 pages, I was done. I had hit my technical reading threshold. There's only so much instructional material I can ingest before it all becomes a blur and I simply need to play around in the application to continue learning. Perhaps if the material were more concept-oriented, I could continue reading far beyond 50 pages, but with step-by-step tasks, there's not a whole lot that one can internalize from just reading step 1, step 2, step 3, and so forth.
After this experience, I changed my approach to single sourcing. I no longer single source from online help to printed material in the near 1:1 ratio that I did before. For my printed material, I include only the basic topics, and I try to limit the printed guide to around 50 pages or less. The printed guide mostly serves as a primer for users who are new to an application. It's not intended for advanced users.
I freely admit that a good majority of people bypass the manual altogether and simply jump into the application. I do this too. But in doing this, many times I get stuck, because the interface isn't as intuitive as I hoped, and so I turn to some instructional material. When I do turn to the help as a starting point, if the help is a gigantic array of folders and subfolders with dozens of topics arranged in almost no hierarchical or chronological order, as is the case with many online help files, I get lost. I want a clear path for ramping up in the application. The 50 pages of information in the printed guide helps get me started and going in a much more friendly way.
Before I go too far with my dismissal of the extensive single sourcing that I previously adopted, let me point out a few disclaimers. First, this whole topic gets into the discussion of whether anyone reads the manual. The variety of software and different user scenarios makes it difficult to generalize trends. Everyone has an uncle who reads manuals cover to cover. Everyone knows a teenager who marks up his video game guide with an almost religious scrutiny. Everyone has a customer who needs the full manual printed out because they want to include it in a packet for new employees.
Ideally, I'd like to move beyond anecdotal evidence and point to researched trends, but I'm not sure the topic has much hard research to stand on. My perspective has mostly been shaped by the experiences I've had and by my own methods for learning software.
Now that I've made my disclaimers, I'd like to state a few principles:
Long printed manuals are becoming museum relics. If you're delivering a 200 page printed manual for your software, expecting that users will read it cover to cover to learn the application, you're kidding yourself. Reproducing the entire online help in printed form for those one or two users who request a whole handbook does a disservice to the majority of users who prefer just a light print reading experience to get started. If your experience has been different from what I described above, please share your perspective with me.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.