Columns

Tech Comm and Mobile: What You Need to Know

November 30, 2011

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.

Tech comm has undergone three major changes since the early 1980s—word processing, online help, and the Web. Each went through a turbulent period before entering the mainstream of the field. We're now in the midst of a fourth change—mobile. And after some turbulent years, it too is going mainstream. If you're a technical communicator, it's time to start looking at mobile.

Any new technology can be confusing, and mobile has its share of new terms, unfamiliar standards, and confusing tools. The goal of this column is to cut through that confusion by discussing three main mobile issues—why use it, what forms does it take, and how to create them (with a focus on options for tech comm).

Why Use Mobile?

Some reasons seem obvious:

  • Provide information when and where users want it—“now” and “here.”
  • Provide information in a form users expect—increasingly, mobile. (It's hard to give firm statistics for this, since you'll find statistics supporting any position you want. But from observation, I'll say that the younger or more techie the users, the more they use mobile.)
  • “Mobilize” desktop apps for use in the field, or create unique apps that have no equivalent on the desktop, like sports bar finders and guides to public toilets (seriously) that rely on a mobile device's knowing your location and providing directions accordingly.
  • Mobilize online help or documentation built using authoring tools like RoboHelp or Flare.
  • Differentiating your brand for marketing purposes—e.g., “We're mobile, they're not. Hire us.”

Types of Mobile

The term “mobile” is vague, so before getting involved in a mobile effort it's vital to specify what we're talking about. Here are three major types.

Apps

“App” is short for application. The term long predates mobile, but it's increasingly used in the context of mobile—e.g., “iPhone app.”

Apps usually focus on one task, unlike sprawling PC applications. For example, CamCard exists solely for scanning and storing business cards; Messier Objects track observation of a type of astronomical object. Below are two more, a guide to museums of Sacramento that I created for the 2011 STC Summit, and a guide to the periodic table, from Apple.

For this discussion, I'll classify apps in two categories:

  • Native apps—What we think of as “mobile apps.” They reside on the mobile device, are written in the device's native language, and can use the device's native resources (camera, GPS, etc.). If the app uses data, that data can be on the device or on a server accessed via the Internet.
  • Web apps—A tricky term that boils down to the app's running in a browser on any device from a smartphone to a PC. To a degree, the browser is the app; what we view as “the app” is content in the browser. If you create WebHelp Mobile using Flare or WebHelp using Flare, RoboHelp, or another help authoring tool, you're creating a web app. This has implications for tech comm.

Sites

A “site” is basically a web app. Sites fall into two categories:

  • As is—The site is viewed in a browser with no redesign to account for the properties of mobile devices vs. those of regular displays. At the top left of page 33, for example, is MadCap Software's knowledge base as is in full-screen, and viewed through the Safari browser on my iPhone. Both are quite legible, though it's obviously more difficult on the iPhone because of the need for scrolling.
  • Mobile optimized—The site is redesigned to take into account the properties of mobile devices. At the top right, for example, is a page from an online reference guide created in Flare, shown as is, and reformatted for viewing on a mobile device. Both images (top right) are perfectly legible, and I've modified some technical aspects (but not the design) of the material to optimize it for mobile.

As is site

eBooks

eBooks are basically books in electronic format for viewing on handheld readers like Amazon's Kindle or Barnes & Noble's Nook, or general-purpose mobile devices like smartphones or PCs with an eBook plug-in. Here are two small examples of each, below. The example in the next column is an ePub-based eBook created in RoboHelp and running on Adobe's Adobe Digital Editions eBook viewer.

Implications for Tech Comm

As of August 2011, all three types are “silos”—separate technologies that don't work together. But there are signs that they can, and in ways in which tech comm can participate.

For example, conventional wisdom says native apps don't need help, but this may not be true. They may have unintuitive navigation features, or may need a lot of domain knowledge. How do we convey this information to users?

We can add help text to an app, but apps aren't designed to handle lots of text. Instead, we can add links between the app and online help so that app users can access the help, browse it to find information, and return to the app to keep working. As of August 2011, I've worked out a way to do this between an app and a mobile-optimized site using an app development tool called MobiFlex, discussed below, and Flare, and am working on doing the same thing for ePub eBooks. The upshot is that technical communicators can get involved in creating online help for native apps, just like we've been creating online help for PC applications for 20 years. Another new market for tech comm to look into.

Mobile optimized site

Pros and Cons of Each Type

How do you choose between each type? It depends on your needs, but here are some high-level points.

Apps

  • Pros—Apps may be what your audience expects. Also, they can take full advantage of platform- or device-native resources like the camera or GPS.
  • Cons—“Versioning” apps (modifying them to work on multiple devices, platforms, and versions) is an expensive proposition.

Sites

  • Pros—Sites, mobile-optimized or not, can run on any device that has a browser. Also, there are fewer browsers than there are devices and platforms, so versioning is simpler.
  • Cons—Don't take full advantage of resources (camera, GPS, etc.). (HTML5 may change this.)

eBooks

  • Pros—eBook readers are dedicated to and optimized for one task, unlike multipurpose devices.
  • Cons—Readers face pressure from multipurpose devices like tablets, which may kill them (or not, depending on the statistics you read). Also, the ePub standard does not support an index.

How to Create Mobile Outputs

How do you create the different types of mobile output? Two options:

  • Manually—If you can work in code and are willing to learn XHTML, CSS, Objective-C, and so on, you'll have total flexibility. But working manually can be difficult, slow, and error-prone.
  • GUI tools—Using a GUI tool is more limiting than manual coding, but faster and easier, and a good tool produces clean and syntactically correct code for you. The tool also sets technical boundaries for you. You don't need to know as much XHTML or CSS. Finally, if it's a tech comm tool like Flare or RoboHelp, you may already own and know it, so you just have to learn a few new features instead of a whole new tool.

Here are the three output types and related GUI tools. (I'm certified in RoboHelp, Flare, and MobiFlex, but this isn't a pitch for them, just a list of some well-known and easily available tools.)

I think these tools will change app development like FrontPage did for the Web and Doc-To-Help did for help. The GUI interface opened development to nonprogrammers and created much of today's tech comm world.

  • Unoptimized site—Any help authoring tool that offers WebHelp output. (They all do now.)
  • Optimized site—Flare 6 or 7.

Some Planning Notes

It's easy to try a mobile conversion, especially if you own Flare or RoboHelp. Change the project skin (Flare) or run a script on the project (RoboHelp). In the long run, however, you'll also need to:

  • Define a “content strategy,” especially if you plan to single source to different outputs, including mobile. Suggestions:
    • Define how mobile supports the company's strategy or solves a business problem.
    • Identify your sources of content and how to support them.
    • Implement a consistent tool set in the company.
    • Support those tools with templates and training.
  • Develop standards to get coding and content consistency and thus automatability. Suggestions:
    • Define your terms. Be sure everyone understands what “mobile” means in your context.
    • Select and/or define external and/or internal standards.
    • Define and enforce levels of standards adherence.
    • Think inside the box—no tool hacks.
  • Do research to find out:
    • What users and wannabe users want, not what we want them to want.
    • What sells? Visit third-party mobile stores to see the priority with which they exhibit different devices. Can you draw any inferences?
    • What devices sell most heavily in market niches you want to target.

Summary

It can be nerve-wracking fun to participate in the birth of a market. But we've been through this with word-processing, help, and the Web and after the initial bumps each became an accepted part of tech comm and opened new jobs and new markets. Mobile appears to be following a similar track. Now is a good time to start preparing for it.

Neil Perlin (nperlin@nperlin.cnc.net) is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA. He has 32 years' experience in technical writing, with 26 in training, consulting, and developing for online formats and tools including WinHelp, HTML Help, JavaHelp, CE Help, RoboHelp, Flare, and some now exhibited in museums. Neil is a member of the STC Boston Chapter, a 2010 STC Fellow, and the founder and manager of the Beyond the Bleeding Edge stem at the STC Summit.

Tags