Features

How Mobile Will Change Technical Communication

By Neil Perlin | STC Fellow

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. Word processors came on the scene in the early 1980s and put an end to typewriters, galleys, and other paraphernalia of a lost age, replacing them with tools like Word and Framemaker. Windows Help was Microsoft’s online help standard from 1989 to 1997, starting the shift from print to today’s browser-based outputs.

perlin-1-1perlin-1-2

Figures 1-2. Turning points in the evolution of technical communication: a Wang word processor and the Microsoft Windows Help circa 1989-1997.

We’re now looking at the next turning point, mobile. Consider the chart in Figure 3 from Gartner IDC.

perlin-3

Figure 3. Device sales per Garnter IDC

And “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 on the horizon.

The article is based on a presentation that I’ve given at several conferences. The presentation is based on my Flare and RoboHelp consulting, app development consulting, and a think tank hosted by Huawei in Plano, Texas, in the Fall of 2015 in which I participated. I acknowledge all parties at the end of this article.

What We Need to Do in the Short Term

This section addresses things we should be doing, mobile or not. The advent of mobile just increases their importance.

Define the benefits we offer

We need to show that technical communication goes beyond writing manuals. It supports the company’s business strategy and might even act as a revenue generator (discussed in the next section).

Goal—Make sure the documentation 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?

Interesting examples include Dozuki (www.dozuki.com) and iFixit (www.ifixit.com) which offer post-sale service manuals online and sells 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.

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 1990s, 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 that was 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.

Goal—Set a clear direction for moving into mobile to avoid repeating the mistakes of the past.

Code correctly

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 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.”

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 now opens up those capabilities. Learn about how to place images using the IMG tag’s float property rather than tables in order to let them automatically adapt to the size of the display screen, for example.

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.

Refocus our writing by looking 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 (www.lukew.com/ff/entry.asp?933). The article makes three points, all of which apply to technical communication:

  1. Mobile is exploding.
  2. Mobile forces you to focus.
  3. Mobile extends your capabilities.

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.”

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 top navigation interface released with Flare 11 in 2015, shown in Figure 4.

perlin-4

Figure 4. MadCap Flare in 2015.

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.

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.

Goal—Take advantage of new features and avoid painting yourself into a technical corner.

Don’t get blinded by the “next big thing”

There’s always something new and cool coming along. It’s important to look behind the hype to see if it make sense technically and culturally. DITA, for example, offers some significant benefits but can be demanding to use and hard to fit into existing documentation group cultures. Another potential cultural misfit is augmented reality (AR). 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).

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, such as IT.

Goal—Consider culture problems that may arise as you move toward mobile.

What to Start Thinking About

This sections addresses technologies that exist but have little presence in technical communication to date, maybe because there’s just no fit yet, or because the fit hasn’t happened yet. For example, HTML and technical communication were in completely separate silos until Microsoft unexpectedly merged them in 1997 with its release of HTML Help. So keep an eye on the technologies discussed here.

“True” apps for technical communication

Responsive design lets us create material that can be read on mobile devices but that doesn’t look like typical apps. Figures 5-7 show examples of responsive design output versus “true” apps. The example in Figure 5 is from a responsive output that I created using Flare 11. It looks rough because I simply output an existing project without optimizing it for responsive output, but it is running on a mobile device. Figure 6 shows a preliminary app for the STC New England’s 2015 Interchange conference. It looks rough because it was a functional prototype, but it illustrates visual capabilities that responsive output won’t have without additional work. And Figure 7 is a completed diabetes-monitoring app.

perlin-5perlin-6perlin-7
Figures 5, 6, 7: Responsive design created using Flare 11, Preliminary app for STC New England’s 2015 Interchange conference, Diabetes-monitoring app

Technical communication and apps aren’t the same thing, you say? Perhaps, but there’s no reason why our content can’t be as visual and word-light as an app while adding an app’s responsiveness, location-awareness, and other features.

Technical communicators with whom I discuss apps rarely think of themselves as app developers because of differences in the technologies and the tools. But here’s the main interface for ViziApps, the tool used to create the two apps in Figures 5 and 6 (and, in the interest of disclosure, a tool in which I’m a certified consultant and trainer). The functionality differs from what we’re used to in tools like Flare but the interface will quickly become familiar.

If traditional documentation isn’t enough and you need interactivity, more of a visual element, location-sensitivity, and similar features, you may find yourself creating apps in the near future. You’ll be buying and learning new tools and concepts. You’ll also be revisiting issues like what email client users have on their phones (which sounds new but is actually similar to the old issue of what browser users had, if any, on their PCs in the mid-1990s). And you’ll be facing truly new issues like putting help content (data) into a database in order to pass it to or share it with an app.

We’re going to have to think differently about our content in order to make it work with apps and take advantage of the capabilities they offer.

New interfaces

Keyboards and screens have been the main interface for years and work fine, but not for mobile where users may not have the space for them. (Although technology may be changing the screen issue, watch this video from MIT Technology Review, https://www.facebook.com/technologyreview/videos/10153952349744798/?fref=nf, to see what new glass technology may do to displays in the years ahead.)

The likely replacement seems to be voice interfaces like Apple’s Siri and the Amazon Echo’s Alexa. Another interesting idea is Google’s Now On Tap intelligent assistant and the ability to get help about what’s on an app screen without leaving the app.

perlin-8
Figure 8. ViziApps interface

Working in this environment means writing content to be spoken instead of read, or both. We may also have to get involved in the technical side of audio, such as the CSS standard’s audio properties like pitch and pause-before. I haven’t heard of any technical communication projects using voice as an interface yet, but the technology is out there waiting. (If you are using voice for the interface on an online help project, please contact me.)

Adaptive content

One looming problem with creating content to be used on multiple platforms or in multiple scenarios is content adaptation. Consider the “click” vs. “tap” issue when content may be used on both desktops and mobile devices, such as for responsive design. How do we deal with this? (You’ll find a discussion of this issue on LinkedIn at https://www.linkedin.com/groups/1276817/1276817-6108413553465708544.)

One answer is to use intermediate words like “select,” but this can be ambiguous or just sound clunky if users have to select an item from a list and then “select OK.” An alternative is to create computer-driven adaptive content that uses CSS and media queries to test for the device display size and change the text accordingly. Mike Hamilton from MadCap Software and I created a prototype of this for Flare in 2014. The code isn’t pretty, but it’s worked nicely in every test I’ve run. (Email me if you’d like to see the code.) Note that this use of CSS also ties back to my earlier point about becoming more technical.

Content customization

Content customization has been with us for years on the Web as user preferences are tracked by various types of analytics software. You see it every time Amazon presents you with a list of options based on your previous purchase decisions. That tracked information can be thought of as a “data halo” (a cognizant term) around users. Most of it today applies to ecommerce, but it may apply to technical communication as well.

For example, if certain users access the same help page or search on the same subject daily, analytics can keep track of that and let you offer that page or search result automatically when conditions are the same as on previous occasions.

You can collect the analytic data to do this using a general technology like Google Analytics or, more specifically if you’re a Flare shop, MadCap’s Pulse add-on.

However you do it, it’s a good idea to start collecting analytic data now. If you want to start creating customized content in the future, you’ll be building the data foundation now. And even if you don’t think customization is in your future, the collected search data will still give you information about what users are looking for and what they can and cannot find, which is information that will help you improve the product and the online help.

Cross-device state preservation

Finally, consider that “mobile experience” users may find themselves starting to read your material on a PC in the office, then go out on the road and want to keep reading the material on a tablet or phone or have it read to them while driving their car. Easy. Just re-open the material and read it again. But what if users want to continue where they left off on the desktop but on a completely different device without having to restart from the top?

I saw the idea mentioned once in 2015 and most recently in a Bright Ideas for 2016 article in the January 2016 issue of Wired (see https://webshelf2.files.wordpress.com/2016/01/wired-january-2016.pdf). The idea is so new that it doesn’t even seem to have a name. I just made up the term “cross-device state preservation” in order to have a reference in conversations. No documentation group that I’ve spoken with has gone far enough down the mobile path for this to be an issue, but one lesson from the rise of online help is that things change and that it’s better to do things correctly from the beginning than to have to go back and fix them afterward.

I’ve spoken with several engineering managers about how cross-device state preservation might work. It will require that the material be stored on a server and dynamically reformatted for whatever device is being used to read it, plus Internet access (obviously), plus a login to let the server and format software know what material to format for which user, plus syntactically correct code, plus extensive use of metadata. All these requirements make cross-device state preservation the most esoteric of all the new mobile experience technologies.

Summary

Some of the effects of mobile on technical communication are obvious: new tool and technology skills, huge changes in how we create content, new problems (and new forms of old problems), plus changing business models and intra-company relationships. But the biggest effect will be the emergence of new and challenging lines of work that I expect can take our field in unexpected directions and bring younger generations into the field.

Thanks

Thanks are due to the following people for their direct and indirect contributions on the subject of mobile and tech comm in this article:

Rhonda Truitt and Sally Martir with Huawei and organizers of Huawei’s Mobile Info Think Tank

Mike Hamilton with MadCap Software, for his work on CSS-based adaptive content

Nicky Bleiel and Bernard Aschwanden, STC leaders and presenters with me at Huawei’s Mobile Info Think Tank

David Kay of D.B. Kay and Associates and presenter at Huawei’s Mobile Info Think Tank

Kevin Benedict with Cognizant’s Center for the Future of Work and presenter at Huawei’s Mobile Info Think Tank

Joe Barkai, product and market strategist and catalyst, and presenter at Huawei’s Mobile Info Think Tank

George Adams, CEO of ViziApps

Michael Kuperstein, CTO of ViziApps

Charles Cooper of Rockley Associates and presenter at Huawei’s Mobile Info Think Tank

Neal Dench, Carol Leahy, and Katherine Judge for serving as an impromptu sounding board at the picnic table at TCUK 2015

NEIL PERLIN (nperlin@nperlin.cnc.net) 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’s Intercom, IEEE, and various other publications.