The evolution of “Mobile” in technical communication and the scotch app

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 tech comm standards) topics. The image below is a page from a single malt scotch guide that I created in 2000.

Pretty cool, huh?

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

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:

• A new, HTML5-based output for mobile devices – the “multiscreen” output. We can generate output for various smartphones and tablets and do so at one time.
• New ebook outputs, plus improvements to the EPUB output added in RoboHelp 8. We can now generate the KF8 and EPUB 3.0, as well as 2.0.1.
• A “media queries” feature to create content that dynamically adapts itself to display device properties like screen size.
• And, intriguingly, the ability to create native apps – iPhone and Android apps – as well as web apps. This feature carries some major technical complexities, plus new and unfamiliar design and business complexities. But it does take RoboHelp beyond the ebook reader and into the full world of mobile. We’ll look at a few of these complexities further down in this paper.

Early mobile efforts failed for various reasons, one of which was just bad timing. Early web sites 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.

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

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

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 …

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

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…

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

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.

Three final thoughts:

• An online Help project converted to mobile is unlikely to look like “an app”. That doesn’t mean the result isn’t an app, it’s just that RoboHelp doesn’t offer traditional app features. Might that cause user expectation problems?
• RoboHelp authors who want to single-source a project out to mobile or use a project as a data portal for an app must plan carefully. Planning is no longer what we’ll do once the project gets rolling. (Note that I’m giving two presentations related to planning at the 2012 Lavacon, one on general planning and best practices for “future proofing” our work, the other on the mechanics of using Help authoring tools like RoboHelp to feed data to a mobile app.)
• Moving from print to online Help has its complexities, but the design problems are eased by the fact that a screen can be thought of as an endless piece of paper. We lose that design “enabler” when we output to smartphone.

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.