By Neil Perlin | Fellow
The first mobile device was the Compaq portable. The size and weight of a sewing machine, it was on the cutting edge of technology in 1986. Fortunately for our backs, it was replaced by today’s light laptops and netbooks. But for many people, even those devices are too big.
The drive toward pocket-sized computing and communication has been ongoing since the late 1990s. The communications side has been so successful that pay phones are vanishing. The York Daily Record (www.ydr.com/remember/ci_10226075) noted that “there were more than 2 million pay phones in the U.S. in 1997 … to about 1 million … in 2006. Cell phones … leaped from 90.6 million to 217.4 million between 2000 and 2006, according to the FCC.”
The computing side hasn’t done as well. Microsoft’s Windows CE, Apple’s Newton, and WML (Wireless Markup Language) all failed in the mass market. But new mobile computing efforts are underway and, this time, they may succeed. If so, they will change how people use information and how technical communicators create it.
In this column, I’ll discuss three points about supporting mobility—why, why now, and, for technical communicators, how? Some of this is opinion, but it’s also based on current developments and historical precedent. You may not plan to support mobility as part of your company’s content strategy today, but you can’t ignore it.
Why Support Mobile?
Society is increasingly mobile, and mobile information is worth considering if your products can be used away from a desk. That’s clear in cases like medical applications, civil engineering, or public utilities, but consider less obvious cases like accounting software for use in warehouses for inventory or engineering software for use on a manufacturing plant floor. In a column in the 8 March 2010 ComputerWorld, Scot Finnie wrote that “mobile is no longer just the future; its time is now” and “IDC predicts 20.9% growth in smartphone sales from 2009 through 2013.”
But we’ve heard equally rosy predictions since 1998. They didn’t pan out. Why now?
Why Now?
Two reasons, in my opinion. First, the user experience is better. Figure 1 shows a slide from a presentation on WML programming of mobile web pages that I gave in 1998. Look at the output, at the bottom right, as well as the code.
The interface was limited and bland. Many applications, like horoscopes, were just silly. And the timing was bad. Users might have accepted a bland interface and silly applications if mobile had arrived in the early 1990s, when much of the web looked like this. But by the late 1990s, the web had improved so much that WML output looked prehistoric. Compare it to an example of today’s output, shown in the iPhone app in Figure 2.
The second reason is a better authoring experience. There were few GUI tools in 1998, so we hand-coded. The code is simple, but any hand-coding is slow, typo-prone, and subject to syntax errors. Today’s tools are just better.
So using and creating information for mobile devices today is simply more attractive. That change is likely to increase use, which leads in a virtuous circle to more and better applications and better tools, just as it did in the early 1980s when PCs began to enter the business world, and in the mid-1990s with the Web and the business world.
How does this apply to technical communication? If mobility follows the virtuous circle, companies that try it will probably still have to create the “normal” online help or documentation. Mobile will be the latest in a series of outputs—single-sourcing taken to the extreme. So what publishing and output options do we have?
Publishing and Output
A problem today is choosing from many options for the model, output, reader, and tool. (For this column, I’m lumping smartphones and eBook devices into a generic category of “mobile devices.”) Each of these factors has too many options to list in detail here, so what follows is an overview and some references.
Model
Anders Rosenquist of ZAAZ, a digital agency in Seattle, described two models in a presentation on “The Mobile User Experience: Trends and Best Practices” at the 2010 Writers UA conference. The models, and their attributes, were as follows:
Mobile site—A website to run on mobile devices. This offers:
Simple deployment—There’s nothing to download to a mobile device or run in an app store.
Broad applicability—The site isn’t tied to specific devices, so we don’t need to make painful decisions about targeting the output.
Currency—The site runs from a server, so users always have the latest version.
(I’ll suggest a variant on the mobile site model — a mobile app based on a standard like ePub. This means the app can run on any device that supports that standard.)
Mobile app—An application targeted to a specific device, such as the iPhone. This offers:
Targeted development—Takes advantage of a specific device’s operating system capabilities and other features, such as the presence of a camera or global positioning system (GPS).
Better user experience—Adheres to design standards and user expectations (e.g., an iPhone app looks like an iPhone app, not just some generic app on an iPhone).
Output Options
The best-known mobile operating systems are, in no special order, the iPhone, Windows Mobile, Android, Symbian, Blackberry, and the Palm Web OS. The best-known mobile browsers are, in no special order, Mobile IE, Safari, Opera Mobile, and Blackberry. These operating systems and browsers have a web-like style, making them good for the short help topics that technical communicators often create. A good starting point for information about mobile operating systems can be found on Wikipedia: http://webopedia.com/quick_ref/mobile_OS.asp. For mobile browsers, try http://en.wikipedia.org/wiki/Mobile_browser.
The best known eBook formats are, in no special order, ePub, Kindle/MobiPocket, and PDF. These formats have a book-like style, so they may be less suited for creating typical online help but good for documentation. A good starting point about eBook formats is http://en.wikipedia.org/wiki/Comparison_of_e-book_formats.
Some readers are tied to one output option, like the iPhone. In other cases, readers may support multiple output options, like the Barnes & Noble Nook that supports ePub, eReader/PDB, and PDF. A good starting point about e-readers is http://en.wikipedia.org/wiki/List_of_e-book_readers. For smartphones, albeit with more calling plan details than you may want, read www.gearfuse.com/new-generation-smartphone-comparison-chart-lays-down-the-facts/.
Authoring Tools
There’s a wide choice of authoring tools ranging from commercial products to shareware and freeware. A good place to start is at a specific device vendor’s site or a standard’s sites. However, a standard’s site may be too detailed at first, such as the International Digital Publishing Forum site at www.idpf.org, which has information about ePub tools, but too much information overall. Instead, I found a good starting list of ePub tools on Wikipedia: http://en.wikipedia.org/wiki/Epub.
If you already use RoboHelp 8 or Flare 6, you have an additional option for testing the mobile information waters. Both tools offer mobile information output features.
Flare 6 offers a WebHelp Mobile output target that follows the mobile site model. This lets authors convert a Flare project to the WebHelp Mobile output that should run on any device with a microbrowser. Technically, it’s easy. The problem lies in conditionalizing content designed for a large-screen device like a laptop to fit into the tiny screen of a mobile device. (There’s a case study about Flare’s mobile output at www.madcapsoftware.com/casestudy/Thinking Windows.aspx. See also Ed Marshall’s review of Flare 6 in this issue of Intercom.)
Adobe has made available a conversion script for RoboHelp 8 to let authors convert a project to ePub. The script is now available. For information about Adobe’s perspective and to download the script and a related file, read the blog of Ankur Jain, RoboHelp Product Manager, at http://blogs.adobe.com/techcomm/.
Mobile support in a help authoring tool (HAT) may seem like just one more new feature, but it has a strategic effect. It makes it easier and safer for companies to test the mobile waters because there’s no need to buy and learn new tools. Mobile output is simply a new feature in a tool that you already own and know. And, if mobile turns out not to be what you were looking for, it’s easy to back out and return to your traditional outputs.
Summary
Mobile has been named “The Next Big Thing” so many times that we have to take any announcement with a grain of salt. But mobile does fit societal and business trends toward mobility, so it’s worth looking at to see whether it should be a part of your content strategy. And if you enjoy intellectual challenge, you’ll like creating and designing information in a way that will fit on anything from a traditional big-screen PC to devices with screens the size of a sticky note.
Neil Perlin (nperlin@concentric.net) has 31 years’ experience in technical communication, with 25 in training, consulting, and development for various online formats and tools. Neil is a columnist and frequent speaker for STC and other professional groups, a member of the STC Boston Chapter, the creator and manager of the Beyond the Bleeding Edge stem at the STC annual conference, and a 2010 STC Fellow.
