Wednesday, September 6, 2017

We’re Going Mobile! Great! But What Does That Mean? And Are We Ready?

So, your company has decided to take its documentation mobile. Great! But has the company considered:

        What does “mobile” mean? People often assume that “mobile” means an app on a smartphone but does everyone share that definition? If not, different groups can wind up going in different directions.

        How do you plan to go mobile? Creating responsive versions of the documentation, converting the online documentation to an app, creating a “true” app, or something else?

        Should your content authoring practices change? You may be authoring in ways now that violate good practice, such as local formatting in Word, but that have been working until you decide to go mobile.

        Will your business practices support an organized and maintainable mobile effort? If not, the move to mobile is likely to be a one-off that wastes resources and loses management’s support.
In this post, I’ll briefly discuss these questions. The post is based on the “We’re Going Mobile! Great!...” presentation that I gave at the STC annual conference in Washington, DC in May, 2017 and the TCUK conference in Nottingham, England in September 2017.

What Does “Mobile” Actually Mean?

It sounds silly, but poll everyone involved to make sure they’re defining “mobile” the same way. Often, they may not be and the result can be chaos if you’re trying to set up a company-wide mobile strategy.

How Do We Plan to Go Mobile?

There are three primary approaches – responsive output, converting online documentation to an app, and creating a “true” app.

1 – Responsive Output

Responsive output means creating one online document or web site that can detect the properties of the device on which it’s displayed and automatically reformat itself accordingly. This can be very useful because if your material has to be displayed on desktop PCs, tablets, and smartphones, you only have to create one output rather than one output for each device.

And, depending on your authoring tool’s features or your code skills, you can not only change the screen layout, such as collapsing the menu, but change the layout of the content, such as changing from a horizontal to a vertical format, and even change wording, such as changing “click” when the material is displayed on a PC to “tap” when it’s displayed on a mobile device. All automatically.

2 – Converting Online Doc to An App

Because so much online documentation is primarily text and graphics, we tend not to think of it as being suitable for an app. Yet many apps are largely text and graphics. Check out the Messier List and Encyclopedia Britannica apps for example.

How can you convert your online documentation to an app? Two quick options:

·        If you use Flare, you’ll use the cloud-based PhoneGap Build ( See my May 2017 post on MadCap’s MadBlog at

·        If you use RoboHelp 2015+, you’ll use the built-in PhoneGap ( For information, see this post by Robert Desprez –

·        For general information, see PhoneGap Essentials by John Wargo.

Not everything will convert smoothly. Popups convert to hyperlinks. Some head styles converted to italic when I converted a RoboHelp 2015 project, though this may have been fixed in v. 2017. But the main content, structure, and features converted surprisingly well.

3 – “True” Apps

Need the look and features of a “true” app? The last few years have seen the appearance of code-light or code-free app development tools. These are sometimes referred to as DIY (do-it-yourself) app tools, or categorized by Forrester Research as Rapid Mobile App Development (RMAD) tools. (Look for a future post on the subject of RMAD tools.)

RMAD tools have two uses for the purposes of this discussion.

        Let non-programmers create apps.

        Let programmers create apps by making the interface creation, workflow, and data access tasks simpler than working in code in order to free up time to concentrate on the code-heavy tasks.

By way of disclosure, I’m certified in one RMAD tool called ViziApps ( For a list of other RMAD tools, see “10 simple tools for building mobile apps fast” at

Why create true apps rather than using responsive output or converting your help to an app? Two primary reasons.

        User expectations – If you say “app” to most smartphone users, they’ll have expectations about the look and features that responsive output or converted help may lack.

        The need for new capabilities such as location or orientation sensitivity, a built-in camera, RSS feeds, transaction processing, and more.

What Effects Might Mobile Have on Your Development Practices?

If you plan to make your content mobile in an efficient and maintainable way, you may need to make some changes in how you create and maintain that content. Some examples:

        No more hacks – Hacks may be impressive but they’re often a bending of good coding practice that can be hard to maintain and may not work as you upgrade your authoring tools or code version. As someone once said, “A hack is a one-off; good coding is forever.” Eliminate existing hacks and make it a policy that new hacks are not permitted.

        No more local formatting – Local formatting is inefficient and overrides the styles in your CSS. This is not a not a mobile issue per se, though it bulks up files and may slow downloading. But it’s just bad coding practice and may break something in the future.

        Replace local formatting with styles, which may mean cleaning up your CSS.

        Rethink your writing style. Make it shorter, more granular, and more focused.

        Eliminate excess content.

        Tables can be hard to fit into small screens, so rethink what purpose your tables serve and how to use them. If your tables are containers for multiple content pieces, only one of which is used at a time, can you replace your tables with lists of links or searches?

        Consider changing navigation – Indexes are being replaced by search. Does this affect you?

        Use up-to-date, commercial tools – Look for tools that offer new features like responsive output and get rid of outdated tools. Be wary of tools with proprietary features that may not translate going forward. If you use such tools, be wary of leap-frogging multiple versions to get up to date or switch to a different tool.

Do Your Business Processes Support Mobile?

You can be okay regarding definition, technical approach to conversion, and cleanup of development processes and still have the move to mobile fail because it isn’t supported by your business processes. Some examples:

        Management buy-in – Have you given senior management sound business/strategic reasons for going mobile in order to justify the effort and build long-term support? If not, the effort will die.

        Training – Have the authors been formally trained in the correct and effective use of their tools? Peer-to-peer training may work if the trainers are experts, but too often this simply promulgates bad practices.

        Standards – Have authoring standards been clearly defined, promulgated, and enforced across all authoring groups? Without such standards, it’s almost impossible to share content between groups and projects.

        Development metrics – Are there clear, focused metrics?  If not, it’s very difficult to identify weaknesses in the development processes. Something as simple as time-per-content-unit is a convenient way to keep track of the effort and resources required.

        Usage analytics -  Do you collect and analyze usage data to find out what users, if any, are using what material? Without such data, you’re basically throwing your mobile content into the darkness and hoping for the best.

        Governance – Is there any formally defined process for managing the workflow and ensuring that material meets internal and any external requirements?

        And more…


It’s easy to go mobile – buy an authoring tool, figure out how to use it, and convert your content to a mobile format. Unfortunately, this approach can be very inefficient and lead to results that are neither maintainable or reproducible.

Similar problems arose in the early days of online help in the mid-90. But back then, much of the effort was experimental, user expectations were minimal, and schedules were loose. Today, “mobile” is a much more culturally accepted form of presenting content, which means that user expectations have been conditioned by a decade of smartphones, and users want their mobile content now.

Proper planning before going mobile will help your company better meet those expectations.