I joined 3di’s technical authoring team in early 2020, which neatly marked 21 years since I was introduced to the world of technical communication. Seeing the range of tools, technologies, and processes that 3di deploys for our customers, I’ve been reflecting on the production methods I’ve contended with over the years, and how they’ve changed to keep pace with changes in technology and user demands.
It’s ranged from a good old fashioned typewriter, working in a paper-only environment where content was laboriously printed and marked up at each stage, through to a digital-only environment, where authors use the latest software for advanced topic-based authoring, publishing and content management.
Do you remember the 1999 Solar Total Eclipse?
Like many technical authors, I had a whole other career before finding my way into this world. Before authoring, I had spent 15 years as an Avionics Engineer with the Royal Air Force. In 1999 I was seconded to an Engineering Development team on a new project, where we were tasked with coming up with a solution to an age-old problem: the British weather. More specifically, we needed to help the media get clear pictures of the 11th August Total Eclipse. Leaving aside the fascinating engineering challenge, it was the technical communication challenge that set me on a career path I’ve been happily following ever since.
However, thankfully, the main production process was carried out over a small NT 4.0 network using AutoCAD and Office 95 to produce policy documents, modifications, and maintenance instructions. This was a marked improvement, as it allowed us authors to create documentation, peer review, and finalise without manually marking up and printing various drafts.
I spent the next 4 years producing documentation for various aircraft modifications. My responsibilities started with document reviews and updates, before moving on to running a small team that managed document control, auditing, and quality to help keep 27 aircraft and crews safely in the air. Towards the end of my career in the RAF I became involved in the roll-out of electronic publications. This is where I was first introduced to XML architecture and digital output.
Way too much Word
From 2007 the main tools of my trade were still Microsoft Office software, Adobe, DOORS document compiler, and Autodesk inventor. This included integrating these documents into electronic learning courses. Although the tools had moved on, there was still quite a bit of saving documents into various different formats, and manipulating them depending on how they were going to be used.
Microsoft Word still dominated too, and it was getting more powerful. The WYSIWYG improvements, integration of graphics and tables, and linking with the wider Office suite tools made it a tempting tool for large organisations to focus their investments on. The ease with which reliable PDFs could be created also accelerated the consolidation of Word.
But of course, we technical communicators knew better, and I was not immune to the favourite sports of Word and PDF-bashing. Word struggled with large documents, both in pages and in file-size, the various tables of contents features never seemed reliable, and templates and styles you had spent days creating were ditched at the whim of less careful colleagues.
The paperless office, which had been a promise for a decade or more, seemed further away than ever. The limited communications bandwidth many companies contended with often forced writers and readers alike to print documents or save them locally, causing no end of version control trouble and reams of soon-to-be-obsolete manuals.
New principles and new tools
In the last ten years wholly digital documentation has started to become the norm for authoring, publishing, and reading. Unfortunately, the companies employing me were still sticking with the idea that although they were investing in their engineering teams using the latest technologies for managing their assets, the same wasn’t the case for the documentation. I could only look on with admiration as more informed and forward-thinking companies were recognising the importance of applying principles such as:
- separating the content from the published format
- using databases and XML architectures to manage reuse
- using topic-based authoring to create flexible, modular sets of information
- making HTML web-content as easy to publish and distribute as PDF and print
- making it easier for the ‘manual’ to feel like part of the ‘product’
I’ve been a Member of the Institute of Scientific and Technical Communicators (ISTC) for many years and that has made it possible to keep up with the latest developments and understand how I could keep my own skills honed. The last five or so years have seen an acceleration of these new digital documentation principles becoming embedded in tools, and companies like 3di have often shared their experiences through ISTC journal articles, conference presentations, blogs, and web articles.
Since joining 3di, I’ve been able to combine my years of authoring experience, with the more recent learning about how to get the best from the latest tools. I’ve been involved with projects using Madcap Flare, Schema ST4, easyDITA, and Cosima. Although they are each suited to slightly different customer contexts, they are all applying the new principles.
With Madcap Flare, document creation is not controlled by the output media, making it a great tool to be used for end-to-end documentation such as user guides and online help. It is an extremely robust piece of software that allows documents to be created and manipulated to a customer’s exact specification, which can greatly enhance the look and feel of the final product. Used in conjunction with the Kaizen Plugin, you can adjust some default features, such as tags and tables of content. You can also import Excel files containing your planned content structure, and create your Flare topic file structure at the push of a button. Personally, I find this a really useful little, but powerful, tool.
The tools I’ve used for image creation and manipulation have also changed significantly over the years: From basic screen capturing of AutoCAD and Inventor images, photograph and image manipulation using Photoshop and Illustrator, and creating GIFs and images with SnagIt for use in training and e-learning modules.
Keeping up by enjoying the learning
The advances in technology, while improving the delivery and turnaround of documents, has meant that some authors of the older generation have faced a fairly steep learning curve getting to grips with, and keeping up with technology. Gaining and maintaining the required skillsets for authoring, with a near-constant advancement in the software and tools used, can be a daunting task. As the software we use advances there seems to be less of a need to understand the language behind it due to program interfaces displaying the relevant output document in a required layout.
However, it is always useful to have some knowledge of the markup language behind these products, as it can be very helpful when investigating output errors. Hence it’s a requirement for authors, young and old, to keep up to date in the packages being used and ensure they still have the practical knowledge to fix these issues.
It’s also worth remembering that, although technical communication tools have changed dramatically, the fundamental and distinctive skill of being able to design and write clear, useful content has remained the same for the past two decades. Thankfully, that skill will always be needed, even as new devices and methods of content delivery replace the current latest thing. My advice to budding authors and those that deal with technical communication is to embrace changes and use them to your advantage, and remember that every day is a school day!
If you have any questions regarding the latest technical authoring practices or need help or advice with your technical communications projects, get in touch with us at firstname.lastname@example.org