By Neil Perlin | Fellow
When Windows Help, Microsoft’s pre-HTML online help format, appeared in 1988, authors worked in the code. That changed in 1991, when Doc-To-Help and RoboHelp, the first HATs (help authoring tools), hid the code behind a GUI (graphic user interface). The Web followed this path, with authors typing HTML codes by hand until GUI tools like Sausage Software’s HotDog appeared around 1995. This code-to-GUI path is now repeating itself for mobile apps. I predict that it will have the same effect as the first HATs and Web tools—changing authoring from an esoteric job done by a few specialists to a general technical communication skill.
This article describes the code-to-GUI path for mobile app authoring tools. I’ll first define “mobile,” since the meaning isn’t completely obvious. I’ll then discuss GUI mobile authoring tools in general, and look at some current tools. Finally, I’ll focus on the possible effects on technical communication.
What Is “Mobile”?
For this article, I’ll postulate three types of mobile—ebooks, Web apps, and native apps.
- eBooks—These are books provided in electronic form for viewing on readers like Amazon’s Kindle or Barnes & Noble’s Nook, or general-purpose devices like smartphones or tablets with ebook plug-ins.
- Native Apps—The term “app” is short for application. The term predates mobile but is increasingly used in the context of mobile, like “mobile app” or “iPhone app.” The term can refer to Web apps (see below), but is usually taken to mean “native apps”—what we think of as “mobile apps.” These apps follow the standards of—are “native to”—particular mobile platforms/devices; iPhone apps won’t run on Android phones, for example. This complicates app planning if your users have different devices—iPhones, Androids, BlackBerries, Windows phones, and others—and may drive you toward creating a Web app.
- Web Apps—These apps run in a browser on a mobile device, such as Safari on iPhones. The browser is the app; what we think of as an “app” is instead the content running within the browser. Web apps fall into two categories.
- As is—The app runs as is, without redesign for mobile’s peculiarities or needs—it’s basically a website viewed on a tiny screen.
- Mobile optimized—The app is redesigned for mobile’s peculiarities or needs, changing the window shape or using smaller fonts, for example.
How to Create eBooks and Web Apps
You can create eBooks and Web apps manually or using GUI tools, the latter being faster and less error-prone. Surprisingly, two GUI tools are already common in tech comm—Adobe RoboHelp and MadCap Flare. (I’m certified in RoboHelp, Flare, and Viziapps, but this is not a sales pitch, just a list of common and easy-to-use tools.) To create:
- eBooks—Use RoboHelp 8+. The output is in ePub format. It runs on the Nook or any device with an ePub reader. (You can convert ePub format to Kindle format using third-party tools like Calibre at http://calibre-ebook.com/.)
- Web apps—Use Flare 6+ to create Web apps optimized for mobile. You can also use any HAT to create Web apps not optimized for mobile—browser-based outputs like Flare’s and RoboHelp’s WebHelp.
How to Create Native Apps
GUI native app development tools are fairly new, first appearing in 2010 with Google App Inventor (see http://appinventor.googlelabs.com/about/), and now Viziapps (www.viziapps.com), appmakr (www.appmakr.com), or iBuildApp (http://ibuildapp.com). These tools hide the coding under a GUI skin. Figure 1, for example, is an Austin, Texas guide to BBQ on Viziapps’ screen design pane.
It’s a busy screen, but it’s all GUI. To show you what it hides, Figure 2 shows the properties pane for the Add Your Own Listing button (just above the graphic in the figure).
Figure 3 shows what you’d be entering if you weren’t using a GUI authoring tool.
Knowing how to work in code is useful, but the GUI approach is invariably faster, more consistent, more error-free, and more syntax-compliant.
Figure 4 is another GUI tool example, the new app screen from iBuildApp.
Figure 5 is an example of how to configure a page in iBuildApp, in this case a Twitter feed page.
One field entry, the Twitter Username field at the bottom, is enough to set up the active display. Note that the page has one problem—it’s still associated with a button whose name is “News,” which I’d have to change on the home page, but that’s about it.
Figure 6 shows another example, the new app screen from appmakr. Again, it is straightforward point-and-click.
None of these tools are as simple as they appear. Viziapps’ data management lets authors use Google Docs spreadsheets as a data repository for many apps (SQL or Web services for higher-end needs). But mapping data between the app and a repository is more complex than screen design; it’s where most authors, especially non-programmers, slow down. Figure 7 shows a fairly simple data management screen that passes data from a user entry in the Austin BBQ app to the Google Docs spreadsheet.
Data management is point-and-click but still calls for a conceptual understanding of what you’re doing.
Some General Observations about the GUI App Authoring Tools
The GUI app authoring tool space is so new that there isn’t yet a standard set of features as there is with traditional HATs. Authors have to carefully define their needs; some needs may automatically point to a specific tool. For example:
- Need data handling? Viziapps appears to be the only choice.
- Need to easily monetize—e.g., make money from—an app? The choice is iBuildApp or appmakr.
There’s also the issue of understanding what some features even are and how they fit the environment. Two examples:
- iBuildApp and appmakr offer “push notification.” Good, but what is it? Do you need it? (Think of it as instant messaging to users of your app.)
- iBuildApp and appmakr have emulators that let you see how your app will look and work before you publish. Emulators run on your PC, so they have all its power and no network delays. This is convenient but unrealistic; most mobile devices are less powerful. To realistically test an app on a phone, you must submit it to Apple’s App Store or Android Market and wait anywhere from a day to several weeks while the app is processed. (It may be rejected.) To deal with this, Viziapps offers a downloadable app that lets you preview your app on a mobile device with a few mouse clicks in a few seconds. But you have to understand the shortcomings of emulators and the details of the submission process to understand what the Viziapps preview app offers.
So the tools are easy to use mechanically; what’s hard is understanding the features they offer.
Consider also that these tools are server based. You’re authoring over the network, so the tool may slow down or log you out depending on network traffic. It’s not a big problem (although you want to save your work often!); log back in and keep working. But it takes getting used to if you’re accustomed to authoring tools sitting calmly on your C drive.
The pricing also differs from technical communication. Use of the authoring tool is free. Vendors make money for services—publishing and/or hosting your app, and consulting to help you create your app or creating it for you. So you may need to evaluate cost in different ways than for technical communication tools.
Effects on Technical Communication
Based on my experience with clients and speaking at conferences, I don’t expect mobile, and native app authoring in particular, to have a big impact on technical communication for another year. The reason is that we’re in the middle of some shifts in viewpoints.
- Few companies have a mobile strategy for their products. Mobile is very new; it takes time to fit it into today’s viewpoints—how do we take an accounting package mobile? But the same was true of online help and the Web in their early days.
- If a company has an app strategy for its products, many people think apps are so simple that they don’t need help, ergo no role for technical communicators. But there are always exceptions. An app may be complex enough to need help for its mechanics or required background knowledge (see the 22 January 2012 Fruit Ninja post on my blog—www.hyperword.blogspot.com).
- If a native app does need help, how do we provide it? In theory, app help will have so little text as to be completely different from what we think of as “help.” But can we be sure? If the help is text-heavy, how do we create it? (It is possible to create links between native apps and mobile-optimized WebHelp to use the latter as context sensitive help for the former. I wrote a paper for MadCap Software in August 2011 on how to do this. Email me if you’d like a copy.)
- There’s a view that mobile development—which involves things like MIME types and Objective C—is too techie for technical communicators. But people thought that about online help in the early 1990s, too.
Summary
As technical communication changes, technical communicators are starting to look at moving into other fields. User experience is hot right now, but I’ve seen little discussion about mobile, perhaps because it seems too programmatic. But so did online help and the Web at one time.
If you’re watching changes in the field of technical communication and wondering where to turn, look at mobile. You may be able to get started by using familiar tools like RoboHelp and Flare, and get into new areas like native apps by taking a surprisingly small conceptual step into new tools. What Doc-To-Help and RoboHelp were to online help in 1991, tools like Viziapps and iBuildApp are to mobile apps today. This is a good time to start looking into what might be your next career shift.
Neil Perlin (nperlin@nperling.cnc.net) is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA. He has 33 years of experience in technical writing, with 27 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 Adobe-certified in RoboHelp, MadCap-certified in Flare and Mimic, and a Viziapps-certified consultant. He is an STC Fellow and the founder and manager of the Beyond the Bleeding Edge stem at the STC Summit.
A longer version of this article appeared in Spring 2012 issue of the ISTC Communicator.
