Writing Assistance, Inc.

Why Technical Publishing Shouldn’t Be Art

by Alan J. Porter

Image for Why Technical Publishing Should not Be Art article
“Writing is a solitary occupation. Publication is a group exercise,” so stated novelist Madeline Robbins. And she’s correct. The work may start with the author, but to get it from the author to the end reader means it also has to go through an editor, copy editor, book designer, typesetter, printer, sales and marketing team, distributor, book buyer, and, eventually, a retail store. It’s a model that the book market developed centuries ago and still works today. Although it could be argued that the Web and print-on-demand are altering the delivery mechanisms slightly, the same basic process still applies. The book trade is based on the fact that the artistic elements, the creation of the content, and the design of the book are small parts of the overall process, and that the publishing process is a business that only flourishes through being scalable and repeatable. Yet the more I write books and the more I become involved in the book business the more I am struck by the differences between it and what has been my “day job” for over twenty years, technical publications. Over the years, I’ve been trained and worked as a writer, editor, document designer, coder, formatting expert, content management specialist, and workflow designer. I’ve used software tools that applied to every one of those disciplines. And here’s the point: often at the same time. As I talk to people in the tech pubs industry today, I still find that in most cases it’s the same person who writes the content, designs the documents, and uses special tools to publish the material — be it for Web, online help, or print (again, often managing multiple deliverables simultaneously). Not only is one person doing the whole job, but often several people are all doing the same thing in parallel. (See Fig. 1.) Why Technical Publishing Shouldn't Be Art - Figure 1 In other words, instead of several people contributing to an overall process, we have individuals each creating individual results. It could be argued that with this individualistic approach, what they are delivering isn’t a complete product but instead individual pieces of “art.” The problem with art is that the results vary. Give a canvas and a box of watercolors to a landscape painter and a second-grader. The same materials, the same process, but you get very different results. Install an editing tool, a help design tool, and a deployment tool on two computers. Give them to two equally experienced technical authors — one who is great at writing content and one who is passionate about typography and usability design. Same tools, same process. Again, two completely different results. The problem inherent in the artistic approach of having every technical author have full access to every tool in the production process is that it isn’t only the best who impact the quality of what you deliver, it’s also the worst. Natural tendencies toward areas of greatest comfort and skill also permeate. When I ran a large technical publications shop, I could open any document at random and tell from the page layout and language who produced that particular book, even though they all complied with both corporate and industry standards. The “author as artist” paradigm increases training costs, as every person has to become knowledgeable about every tool used in the process. Cost of ownership of those tools also becomes high as in a multi-author environment any updates to tools or changes to style templates, business process models, new standards, etc., have to be simultaneously propagated across all machines, and everyone must be retrained. Such parallel production also makes it difficult to measure progress and quality and tends to focus time and resources on getting consistent results. So why not borrow from an allied profession that has been using a well-developed system for a couple hundred years? If we design the process rather than the result, it can reap dividends in quality, proficiency, speed, and overall costs. By separating each of the processes into separate stages, each handled by a specialist with the applicable tools, just like the book industry, we can streamline and even automate the business of technical publishing. In fact, thinking of what we do as a “business” rather than just a necessary “overhead” will go a long way toward not only improving the way we do things, but also help tech pubs gain recognition in the corporate structure (but that’s probably fodder for a future column). So let’s take a look at how we can transform our group of artistic “technical authors” into a more efficient “publishing business.” Everyone on staff is different. They have different skills and interests. Find out what those skills and interests are and focus them in that area.
  • Have a couple of great content developers who have a real knack for talking to SMEs and translating geek speak into easy-to-follow user instructions? Focus them on content development and the use of your preferred editing tool.
  • Got someone who is passionate about page layout and typography? Have them design the WYSIWYG templates for the editing environment.
  • Got someone who loves to get into the taxonomy of what you produce? They could be a great information architect, and if you are going to a structured environment like XML or DITA, have them design and maintain your schemas and specializations.
  • How about that usability expert who is passionate about the way your customers navigate their way through your documentation set? Have them design the look and feel of your deliverables.
By doing this, you are basically building a “modular” production system. Place them in a particular order for the way you work and you have your own publishing production line. Now each individual only needs to be an expert in the area they work and enjoy. Yes, it’s a good idea for everyone to still maintain an overview of the whole process so they can anticipate the impact of their work, but they no longer need to know everything. By having the best people working on centralized tools related to their particular role (See Fig. 2), you are leveraging their skills and enthusiasm and making them available to everyone. The result is that quality improves and your deliverables become consistent. The best work impacts everyone, not just a select few. Why Technical Publishing Shouldn't Be Art - Figure 2 The modular process also means that you can introduce new steps in parallel, and test and troubleshoot without impacting everyone, before bringing them online into the full process. With areas of specialization, you can have people continue to work with the tools they are comfortable with, reduce training costs, and lower costs of deploying updates and changes. Now the authors may just have the editing tools and a review tool on their desktops, using schemas and templates developed by others and stored on the network. The design and behavior of the deliverables has been done by usability experts who have saved off those business rules in a place where they can be accessed by a centralized publishing application. Deployment can be automated to better utilize IT resources so that publishing could be done overnight in a “hands-off / lights-out” environment. The whole process is now measurable, scalable, repeatable, and manageable. Everyone is still a valued contributor, but no one is an artist.

About the Author

Alan J. Porter is the Director of Services at Quadralay Corporation. He has over 20 years in corporate publishing in the UK and USA. He has been involved in the development and adoption of various publishing standards, and has been a regular speaker at industry conferences. He has held senior management positions at various publishing software and services companies, allied with extensive consulting experience. His client base has included Boeing, Canadian Government, Forbes, McGraw-Hill, Mercedes, Sun, UK Royal Air Force and many other Fortune 1000 companies. He is a published author with a couple of books and several magazine articles to his name.