The Evolution of “Mobile” in TechComm & The Scotch App

By Neil Perlin, Hyper/Word Services

I was introduced to mobile, in the form of Microsoft Windows CE, in 1998 by Joe Welinske of WritersUA. By late 1999, I was giving conference presentations on Mobile App (pre-iPhone) programming, cellular technology, and other bizarre (by TechComm standards) topics. The image below is a page from a single malt scotch guide that I created in 2000 to illustrate the coding.

Scotch - old

Pretty cool, huh?

The image below is also a guide to single malt scotch, which I didn’t create, done as an iPhone app.

Scotch - new

These two generations of what’s basically the same app say a lot about product timing and the market’s look-and-feel expectations that users of Adobe RoboHelp 10 will face as we start using traditional help authoring tools to move into the mobile app space. In this post, I’ll touch briefly on what I think we can learn by looking at these two mobile apps.

I’ll begin by quickly summarizing the mobile-related features added in RoboHelp 10:

Timing

Early mobile efforts failed for various reasons, one of which was just bad timing. Early websites looked like the mobile apps of the late 1990s – gray and bland. Unfortunately, by the time the first gray and bland mobile apps appeared, the web was starting its shift toward the colorful and graphic web that we know today. Mobile looked dowdy.

A lesson here for tech comm is to not fall out of sync with market expectations. For example, I find that many technical communicators are delaying adopting smartphones. But smartphone use is growing overall. If technical communicators don’t at least become familiar with smartphones, the danger is that tech comm will go mobile, but that traditional technical communicators won’t be the ones doing it.

Look-and-Feel

A big problem will be the creation of content that can function in very different worlds. Consider three questions. (What follows applies to smartphones. Tablets like the iPad are also mobile devices but, for the purpose of this post, I’ll view them as equivalent to laptops with the keyboard removed.)

Question 1 …

… how do we create traditionally text-heavy help content that can be converted effectively to a text-light app environment like this one, from Dozuki (www.dozuki.com)…

Dozuki App
https://blogsimages.adobe.com/techcomm/files/2012/09/Dozuki-App.png

… or to a somewhat text-heavy app like the Messier List app shown below.

M1 one

M1 - Description

It’s more text than the Dozuki app but still not much compared to a help project.

Question 2 …

… how to deal with controls whose type and position differ between the different outputs, like those shown below in a sample, and typical, RoboHelp project – invariably at the top and left sides of the screen …

RoboHelp WebHelp Output

… versus at the top and bottom of the screen in many apps, like the Messier List screen below?

M1 - Description

Question 3 …

… how to deal with shifting orientations, going from the landscape orientation of most help projects, again like the sample RoboHelp project shown below …

RoboHelp WebHelp Output

… to the portrait orientation common on smartphones, like the one below from an iPhone app that I did for the 2012 STC Summit.

Add a Restaurant Screen

The example above worked nicely in portrait mode, with the image rotation feature turned off. But what if it had been turned on? Rotating the page to landscape mode would have completely altered the format. We have to create RoboHelp projects destined for viewing on smartphones with the possibility that our carefully laid out design may be rotated.

Summary

Three final thoughts:

The design differences discussed here, and many others, plus some major business differences between help and mobile, will make any output from help to mobile to be a challenging task.