By Neil Perlin | STC 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.
“Technical writers don’t use computers.” (Circa 1980, from two writers who turned down a job in a Digital Equipment Corporation documentation group that had just adopted word-processors.)
“Should Technical Writers Be Allowed To Use Computers?” (The title of a 1981 speech given by an STC senior member and reprised in one of my favorite “Beyond the Bleeding Edge” presentations at the STC Summit in the mid-2000s.)
“I’d never take a job that required me to use Word.” (Spoken by many people….)
“Content is key. Tools aren’t important.” (Overheard from multiple people between 1994 and today.)
“I’m not involved in the business side of my company’s operations.” (A common comment from many.)
“Social media? Over my dead body.” (Spoken by multiple people between the late 2000s through today.)
Note: This column is based on my keynote presentation at TCUK ’15 in September 2015.
It’s human nature to stick with what we know and what we are good at. But in a profession whose bow wave is steadily moving forward and opening new areas for technical communicators, that attitude can stunt a career. Every job has to have boundaries based on the nature of the work, but many of the boundaries that I hear about are self-imposed, like the quotes above (all real, some from people I know). In this column, I’ll suggest three ways to break out of self-imposed boundaries—expand, extend, and avoid pigeonholes. I’ve discussed some of these in past columns but I consider them significant enough to repeat here.
Expand (Your Current Strengths)
This is the simplest option. You already have strengths in particular areas, perhaps an authoring tool like Flare or RoboHelp or a methodology like Agile. Simply expand your strengths as they relate to that tool or methodology. For example, if you’re comfortable with Flare or RoboHelp at the GUI level, develop code-level expertise with the CSS or XHTML that’s below the surface. That will let you troubleshoot, let you make the tool do things that it might not be able to through the GUI, perhaps even make the tool do things that the vendors hadn’t thought of. All of which, for a small investment in time and effort, will make you more employable. And if you’re thinking that you’re not a codehead, that doesn’t mean you can’t turn yourself into one.
Extend (Into New Areas)
This is the option with the greatest potential payoff because it takes you into areas in which there may be little or no competition. (Of course, look carefully to see if there’s little or no competition because you’re the first one in the area or because the area’s connection to technical communication is tenuous. If it’s tenuous, then the question becomes whether the connection might grow over time or whether it won’t, in which case you’re moving not only into a new area of technical communication but also into an entirely new field. Because of that uncertainly, never drop what you’re currently doing to move entirely into the new area. I know people who have and who almost put themselves out of business when the new area failed.)
That said, what new areas are there? It’s hard to say because new areas are only obvious after the fact, but here are some possibilities ranging from obvious to speculative.
Mobile
It’s risky to trust statistics on the Internet, but articles like this are very suggestive—“The world is going mobile. Mobile Now Exceeds PC: The Biggest Shift Since the Internet Began” at http://searchenginewatch.com/sew/opinion/2353616/mobile-now-exceeds-pc-the-biggest-shift-since-the-internet-began.
As mobile becomes more common, online documentation itself will have to shift to mobile form in order to follow the larger trend. Going mobile may not always be relevant—accounting software isn’t likely to be used in the field, for example—but it’s worth checking to see whether your company is going mobile and you just don’t know about it. It’s also fairly easy to take traditional technical documentation mobile as the latest versions of our familiar authoring tools now support it.
Going mobile will require that new material be written and coded following mobile best practice. Legacy but still-relevant material will have to be rewritten and recoded for optimum performance in a mobile environment. The skills needed for that, like CSS and XHTML, may be intimidating at first but learning them will make you a better, more flexible, and more in-demand technical communicator.
Apps
Once documentation goes mobile, the next step isn’t too far—apps. It sounds like an unlikely career path for technical communicators, but creating online help was once viewed as equally unlikely. Just as tools like Doc-to-Help, RoboHelp, and others let us create online help without working in code, so too do new GUI app development tools. I’m personally certified in one called ViziApps (www.viziapps.com); you can find a list of others at www.markus-falk.com/mobile-frameworks-comparison-chart. And there are interesting areas of overlap between mobile documentation and mobile apps.
Augmented Reality
Augmented reality may not seem relevant to technical communication, but think about it in terms of overlaying documentation or training on top of real environments, and possibilities suddenly appear. SDKs are available now for the Oculus Rift, Hololens, and Google Cardboard, the latter at https://developers.google.com/cardboard/android/. For more information about augmented reality and virtual reality in a technical communication context, see my column “Trying Virtual Reality on the Cheap With Google Cardboard” in the June 2015 issue of Intercom (http://intercom.stc .org/2015/06/trying-virtual-reality-on-the-cheap-with-google-cardboard/).
Internet of Things
One of the most interesting new technologies around is the Internet of Things. Here’s a definition from Wikipedia (https://en.wikipedia.org/wiki/Internet_of_Things): “The Internet of Things (IoT) … is the network of physical objects or “things” embedded with electronics, software, sensors, and connectivity to enable objects to exchange data with the production, operator and/or other connected devices.” Because the IoT is based on “things,” there probably won’t be much business writing traditional user documentation. But there might be business documenting the APIs and SDKs needed to create the IoT.
Business
Few technical communicators I’ve met have a business background. This puts us at a disadvantage because the crucial thing about most technical communication is whether it supports our company’s business strategy. Understanding that strategy, which requires at least a basic knowledge of finance, accounting, marketing, and strategic planning, lets us tailor our work to the company’s benefit and, incidentally, makes it easier to request funding for new tools. (Note: I have proposed a mini-MBA track at the 2016 Summit that would give overviews of finance, accounting, etc. I have no idea whether the idea will be accepted, but it would be a quick and easy way for technical communicators to at least learn the basics. We’ll see what happens.)
Avoid Debate Pigeonholes
Like every other field, technical communication has its share of debates/feud—Word vs. Framemaker, online vs. print, Flare vs. RoboHelp, and so on. One that’s been with us for years—I first encountered it in 1994—is the content vs. the tools debate. My experience is that this argument tends to be driven by the claim that tools are a minor issue and that the focus must be on the content. My response has always been that both are important. Without content to publish, tools are irrelevant. But without tools to publish the content, the content is irrelevant. The point is that if you adhere to either extreme in this or any other debate, you pigeonhole yourself and limit your options.
How to Break Out of the Boundaries.
Move out of your comfort zone. This is a cliché but, like many clichés, it has an element of truth. Make the effort to learn about new subjects that relate directly and indirectly to technical communication. STC meetings are a great way to do this, but look beyond STC as well, to professional societies related to the type of work you do, including technical interest groups like Boston’s WebInno (http://webinnovators group.com/), Mobile Monday (www.mobile monday.net), and others such as those on meetup (see www.meetup.com).
Summary
I’ve now in my 36th year in technical communication. In those years, there have been times when things were slow and old lines of business or tools were dying. But there have never been times when things were boring or limited. Opportunities are out there if we just look for them and break out of the boundaries that prevent us from doing so.
This will also be my last Beyond the Bleeding Edge column. I began writing it in 2001, with a column on location-based wireless Web services. Subsequent columns covered topics like voice portals, the W3C, grid computing, responsive design, and the CSS float property. It’s been a lot of fun but, after 14 years, time to shift focus. My thanks to past STC president Mark Hannigan and then Assistant to the President Deb Sauer who green-lighted the original Beyond the Bleeding Edge stem and gave birth to this column, the editorial staff at Intercom over the years, and to everyone who’s sent me suggestions, ideas, and critiques over the years. It’s been a lot of fun.
Neil Perlin (nperlin@nperlin .cnc.net) is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA. He has 36 years of experience in technical writing, with 30 in training, consulting, and developing for online formats and tools including WinHelp, HTML Help, JavaHelp, CE Help, XML, RoboHelp, Flare, and others now almost unknown. Neil is MadCap-certified for Flare and Mimic, Adobe-certified for RoboHelp, and Viziapps-certified for the ViziApps mobile app development platform. He is an STC Fellow and the founder and manager of the Beyond the Bleeding Edge stem, which ran at the STC Summit from 1999 until 2014.
