[Ed. Note: This is the first of a three-part article on the impact of mobile on technical communication.]
How Mobile Will Change Technical Communication
By Neil Perlin
If you’re fairly new to technical communication, the images below may look unfamiliar but both were turning points in the evolution of the field.
We’re now looking at the next turning point, mobile. Consider this chart from Gartner IDC:
“Mobile” goes beyond phones, even beyond devices. As Kevin Benedict from Cognizant’s Center for the Future of Work put it, “The age of the mobile app is dead… it’s now the ‘mobile me’ experience.”
As mobile spreads, our readers will expect to get documentation the way they get news or social media. How will those expectations affect technical communication? That’s the subject of this article.
I’ll first briefly discuss the impact of mobile and what we need to do now to fit it into our worldview. I’ll then discuss some technologies that are five to eight years out but that we need to start thinking about today.
This article is based on a presentation that I’ve given at several conferences. That presentation is based on Flare and RoboHelp consulting, app development consulting, and a think tank put on by Huawei in Plano, TX in the fall of 2015 in which I participated. All parties will be acknowledged at the end of this article.
What to Do In the Short Term
In this section, I’ll briefly discuss things we should be doing anyway, mobile or not. The advent of mobile only increases their importance.
Define the Benefit That We Offer
Show that technical communication goes beyond writing manuals. Instead, it supports the company’s business strategy and might even act as a revenue generator (discussed in the next section).
The goal – Make sure the doc groups are active players in the company’s technical and business strategy and thus have the credibility to participate in any mobile effort.
Look at New Business Models for Technical Communication
As long as I’ve been in the field, there’s been debate about how to turn technical communication from a cost center into a profit center, or at least a revenue generator. How might we do this?
One interesting example is Dozuki (www.dozuki.com) and iFixit (www.ifixit.com) that offer post-sale service manuals online and sell tools and parts along with the manuals. Whether or not something like this might work for you, it’s a clever alternative to traditional technical communication.
The goal – Look outside the traditional technical communication business box.
Define What “Mobile” Means for Your Situation
When online help shifted to HTML in the late ‘90s, there was a lot of confusion over terminology. Was “HTML Help” the same as “HTML help”? Was “WebHelp” the same as “Web Help”? Did we have to use WebHelp for material on the web and HTML Help for material to be stored on users’ local PCs? This confusion led to companies buying the wrong authoring tools, hiring the wrong developer, creating the wrong outputs, or all three.
Today, we face the same definition issue with “mobile”. Is it a mobile-optimized web page? Responsive design? An app? Something else? Until you define what “mobile” means in your circumstances, you run the same risk of buying the wrong tools, hiring the wrong person, or developing the wrong output. Defining “mobile” isn’t difficult; it simply has to be done.
The goal – Set a clear direction for moving into mobile to avoid repeating the mistakes of the past.
Every language and tool has hacks and workarounds that are fun to find and interesting to try, but they can be trouble. The latest version of your browser may not recognize a hack that worked three versions ago. Conversion tools may not recognize your cool hack that worked in an older version of the tool or that was meant to be run by hand. As someone once said, “A hack is a one-off; good coding is forever.”
The goal – “Future-proof” your material to be able to take advantage of new mobile outputs and tools without first having to clean up those hacks that originally seemed so clever.
Become More Technical
Technologies like CSS have great capabilities, such as the ability to create adaptive content, but if you’re not at least conceptually familiar with the technology, you’re limited to the features that your GUI tool supports. Becoming more technically adept opens up those capabilities. For example, learning how to place images using the IMG tag’s float property rather than using tables will allow you to place images that automatically adapt to the size of the display screen.
The goal – Be able to use mobile and related technologies to their fullest extent now rather than having to wait for your GUI authoring tool to catch up.
Part two will continue with more short term practices to consider including the “mobile first” approach and navigation models.
About the Author
Neil is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA. He has many years of experience in technical writing, with 31 in training, consulting, and developing for online formats and outputs ranging from WinHelp to mobile apps and tools ranging from RoboHelp and Doc-To-Help to Flare and ViziApps. He has also been working in “mobile” since 1998.
Neil is MadCap-certified in Flare and Mimic, Adobe-certified for RoboHelp, and Viziapps-certified for the ViziApps Studio mobile app development platform. He is an STC Fellow, founded and managed the Bleeding Edge stem at the STC summit, and was a long-time columnist for STC Intercom, IEEE, and various other publications. You can reach him at firstname.lastname@example.org.