[Ed. Note: This is the Second of a three-part article on the impact of mobile on technical communication.]
How Mobile Will Change Technical Communication, Part Two
By Neil Perlin
Refocus Our Writing – Look at “Mobile First”
Luke Wroblewski, a product director at Google, wrote an article in 2009 called “Mobile First” in which he argues that web applications should be designed with mobile as the first priority. (Find the article here – http://www.lukew.com/ff/entry.asp?933. It’s a quick read and worth it.) The article makes three points:
- Mobile is exploding
- Mobile forces you to focus
- Mobile extends your capabilities
All of which apply to technical communication.
The goal – Write to the extreme standard of mobile to improve and extend all our writing.
Rethink our Writing Style and Cut Excess Content
Write shorter, simpler, more focused material. Cut out a lot of conceptual material on the grounds that “if users don’t know the concepts that underlie our software, should they even be using it?” Consider moving away from full sentences to sentence fragments.
This can be hard. Sometimes you have to change your entire mindset to make major cuts while keeping the meaning. For example, I can cut this sentence from The Highwayman by Alfred Noyes, “The wind was a torrent of darkness among the gusty trees.” to, with apologies to Alfred, “It was windy.”
The goal – Make content shorter, optimized, and effective for the smallest screen we may encounter.
Consider Changing Navigation Models
My experience with Flare and RoboHelp classes is that fewer and fewer technical communicators create indexes for their projects, preferring instead to use search. This change is even manifesting itself in new interface models like MadCap’s topnav interface released with Flare 11 in 2015, shown below.
Unlike the traditional tri-pane, the topnav model makes no provision for an index. This puts increased emphasis on SEO (search engine optimization) and a growing need to store and analyze user search data for use in improving the output now and customizing its delivery in the future.
The goal – Change your projects’ “findability” to actively embrace search.
Keep Tools Up To Date
Try to avoid using old versions of authoring tools and then leap-frogging intermediate releases to adopt the latest version. The old version may offer proprietary features that were deprecated in later versions and are no longer supported in the latest version. Or offer a feature that’s not supported in a competing tool to which you want to switch. For example, Adobe RoboHelp offers a slick multilevel list feature that lets authors predefine nested list formatting. Unfortunately, this feature is proprietary; text that uses it in RoboHelp projects doesn’t import into Flare. Fixing such problems may require working in the code, which can be more time-consuming and expensive.
The goal – Be able to take advantage of new features and avoid painting yourself into a technical corner.
Don’t Get Blinded By the Latest “Next Big Thing”
There’s always something new and cool coming along. It’s important to look behind the hype to see if they make sense technically and culturally. DITA, for example, offers some significant benefits but can be demanding to use and hard to fit into existing doc group cultures. Another potential cultural misfit is AR (augmented reality). AR can create enhanced service manuals but can suffer from the “Lefty Lucy, Righty Tighty” problem, material so basic that the target audience may be insulted and refuse to use it, or material distracting enough to cause safety problems. (See http://joebarkai.com/augmented-reality-righty-tighty-lefty-loosey/ by Product and Market Strategist and Catalyst Joe Barkai.)
The goal – View new technologies culturally as well as from the business and technical perspective.
Consider the Politics of Change
Anticipate staff turnover because of change. New hires’ willingness to try new technologies will be offset by the loss of institutional knowledge as old hands leave. Moving into mobile may also encroach on the turf of other groups that are more traditionally viewed as the creators of mobile, like IT.
The goal – Consider culture problems that may arise as you move toward mobile.
Part three of this article will conclude with things to start thinking about as technical communicators, including new interfaces and creating adaptive content.
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.