By Neil Perlin | Fellow
This column presents overviews of new technologies that may affect technical communicators in the near future. If you have feedback, or would like to suggest topics for subsequent columns, please contact Neil Perlin at nperlin@concentric.net.
There’s a school of thought in tech comm that says that tools aren’t important; what counts is the ability to communicate well. This is partly true. If we can’t communicate well, the best tool is useless. But without tools, we can’t deliver our content to readers no matter how good it is. So tools are important. But which ones?
This used to be easy to answer. Word and a screen capture tool would do it. But the increasing number of variables in today’s technical communication world has changed this. Consider:
- Markets. For example, online vs. hard-copy.
- Variations within markets. Does “online” mean web, online help, mobile, social media, or some combination? Does “hard-copy” mean paper or PDF?
- Genres. Text-based online like help or web sites vs. visual-based online like Flash or video?
- Technology change. Like the move from HTML to XML and, possibly, HTML 5.
- Methodologies. Topic-based authoring, structured authoring (not necessarily DITA), etc.?
So what do we do? The rest of this column looks at toolbox suggestions from a different perspective, with actual tools being the last thing on the list. What we need in our toolkits, in my opinion, is as follows:
- The right attitude, in three areas:
- Acceptance of change and our need to change with it. We may think that social media is silly, for example, but it’s here and we need to factor it into our work, not ignore it.
- The need for lifelong learning in order to keep up.
- The need to think from a business sense, not a documentation sense. Our job is not to create user guides or online help but to solve business problems. If excellent documentation will do so, good. If lower-quality documentation will do so and more quickly or inexpensively, good. And if replacing documentation with something else will do so, good. (We just have to make sure we’re involved with whatever replaces it.) Hanging on to “documentation” because that’s what we’ve always done is a good way to end a career.
- The ability to analyze and re-direct our careers. There’s a tendency to get a job, learn how to do it, and stick with it until we’re forced to change—or in some cases, refuse to change. But the world won’t stop for us, so not preparing now means greater disruption later. Career analysis can be formal, in STC workshops and conference sessions, or informal, on long drives or plane trips.
- Accepting that standards are becoming increasingly important and working that way. This sounds very geeky but it can change our employability. For example, I often hear from companies that use standards like CSS that they hire people who turn out not to know how to use styles and CSS and instead format locally, a practice that can require expensive cleanup efforts later. So demonstrating a willingness and ability to use proper standards might make us more employable.
- A “brand” that helps potential employers think of us. You’re not just “that tech writer” but rather “that tech writer who’s an expert in structured FrameMaker.”
- Operational flexibility. This means making sure you’re known as a “category X developer,” not as “tool X developer.” For example, make sure you’re known as an online help developer who uses ForeHelp, among other tools, rather than as a ForeHelp developer. That protects you if one of your tools disappears, as happened with ForeFront, maker of ForeHelp, ten years ago.
- A commitment to following the business context of our work. For example, in the early 1990s, Web development was an esoteric job in high demand and thus paid well. In the late 1990s, Web work began to be done by college students and the pay nose-dived. Many people I knew who had been doing Web development moved on to other, better-paying areas.
Finally, select tools based on the points above. Everyone is different so I won’t recommend specific tools. Instead, I’ll describe my toolkit and its rationale as an illustration.
- Hard-copy tools—Word. When I started Hyper/Word Services in 1990, I decided that my focus would be online rather than hard-copy. My business almost immediately went in that direction so I never had much need for FrameMaker or similar tools.
- Web tools—xMetal, Contribute. When the web first appeared, I used traditional web authoring tools like Hot Dog Pro, HotMetal, Dreamweaver, and others. However, in the mid-1990s, I began focusing on help authoring so I narrowed down my web tools. Today, I use Contribute to maintain my website, xMetal for DITA and XHTML work, and editors like Notepad and Notepad + +.
- Help authoring tools—Use and am certified in RoboHelp and Flare. I’ve always made it a policy to be certified in at least two such tools and familiar with one or two more to be flexible and to present myself as partly neutral to companies looking for tool consulting. (I was also certified in ForeHelp before it died ten years ago.) RoboHelp and Flare also support two forms of mobile output, which fits into my strategic direction.
- Mobile authoring tools—Use and am certified in MobiFlex, an app development tool. MobiFlex lets me create native mobile apps, which rounds out my mobile strategy of being able to create eBooks, mobile-optimized web sites, and native apps.
- Visual Help tools—Use and am certified in Captivate and Mimic and have used Camtasia and the first such tool, Lotus ScreenCam in 1993. I long ago saw that writing was becoming a relatively smaller part of tech comm and decided that I needed to extend into visual help and elearning.
- Browsers—IE, Firefox, and Chrome. IE because that’s what much of my market uses, Firefox because it’s a rising competitor to IE, and Chrome because of its strategic implications.
- Social media—Twitter, Facebook, and LinkedIn. I initially started using these tools not because I necessarily wanted to use them myself but because I saw them as emerging forces in the market and decided that I needed to be familiar with them on a hands-on level.
- Support and other tools—Screen capture tools, graphic editors, mobile authoring emulators, file validators and format converters, and, specifically, Google Docs. Some of these tools are simply obvious choices, like screen capture. Others, like Google Docs, have a very specific rationale based on my strategic direction.
It’s an eclectic set of tools and I can already foresee changes. But each tool has a specific reason behind it, either in response to a client’s need or in response to a need that I foresaw.
Two crucial points in summary:
- Don’t get locked into a small set of tools. Instead, watch for changes in your business environment (your company’s operational needs and your employability) and your technical environment.
- Watch technical trends and business operations beyond the bounds of a tool to be able to discuss a range of perspectives from the code level to the tool level to the strategic level, which adds to your employability.
All this takes a continuing effort to stay current, but the continued employability and intellectual challenge make it worth it.
Neil Perlin (nperlin@nperlin.cnc.net) has 32 years’ experience in technical communication, with 26 in training, consulting, and development for various online formats and tools including WinHelp, HTML Help, CE Help, WebHelp, RoboHelp, Flare, mobile, and others. Neil is a columnist and frequent speaker for the STC and other groups, a member of STC’s Boston Chapter, the creator of the Beyond the Bleeding Edge stem at the STC Summit, and a 2010 Fellow of STC. He can be reached at www.hyperword.com and tweets as NeilEric.
