Mobilizing your content

Today the “right place” for content is almost anywhere. Content formerly delivered only on the desktop or in print can now be published continuously where it can easily be found and used – on mobile devices.

Mobile options

Help authoring tools can be used to single-source to three outputs that will work on mobile devices: mobile Help, browser-based Help, and EPUB. You can access all three on phones, tablets, and eReaders.

Image: Mobile output and its browser-based counterpart

You only need to “mobilize” content for mobile Help – EPUB (for the most part) and browser-based Help are fine as-is. Standard Help authoring tool (HAT) features make it easy. Mobile Help that takes advantage of jQuery and jQuery Mobile makes it possible to create mobile Help that is browser- and device-independent.

And we can still simultaneously deliver manuals and other types of Help when necessary. In fact, some of the changes made for mobile can improve those outputs also.

The mobile persona

There are a few generic traits of those accessing content on mobile devices. These traits should be factored into our audience analysis, and to the specific scenarios that content will be used in. Mobile customers are:

• often distracted
• using one hand
• “fat finger” the device (hit unintended keys/links)
• use their device(s) in varying situations
• impatient; want fast load times
• prone to quit and move on to something else if they think something is broken

Your scenario may be that users (for example, service technicians) need the information, and will wait for it, but you can improve load times and unintended “fat fingers” by following a few best practices.

Tips and best practices

Following are a few single-sourcing tips and best practices for making your content work in a mobile Help format.

Images

Avoid large graphics, because users may have to “swipe” to view/read them. To solve this issue, you can use conditions to designate one version of a graphic for desktop Help; and another smaller, or more targeted version for mobile. You may even want to eliminate some graphics in your mobile outputs altogether because they take longer to load than text.

Single-source strategy:

• Create two versions of images: one for mobile, one for everything else.
• Use conditional text features to tag graphics. Tag some images to appear only in desktop Help.

Tables

Avoid tables that are large, with dense text, because users will have to “swipe” to view/read them. Swiping to read across and down a table makes the information less usable, because the context is lost. One way to handle this for mobile Help is to remove the table and reconfigure the information using collapsible text. That is a great option in browser-based Help and other Help outputs. You could also leave the table in the browser-based version and manuals and use conditional text to display the collapsible text version only in mobile.

Single-source strategy:

• Remove tables and reconfigure information to using collapsible text features.
• Use conditional text to mark tables only for browser-based Help and manuals.

Table of contents/hierarchy

It is best to keep the table of contents to no more than two levels, so customers can find information in two taps. Since they can’t view all the TOC levels at one time (as they can in desktop Help), this makes information more findable.

The topic names in the table of contents should be short, so the entire topic name has a better chance of appearing on the screen. (This will vary by device, so there is no standard length limit.)

Single-source strategy:

• Create output-specific TOCs for mobile that are only two levels deep (or restructure the TOC for all outputs)
• Shorten the names of the topics in the TOC, or create shorter names for mobile and mark them with conditional text as mobile.

Terminology

Standard software terminology – for example “click” – does not apply to mobile. You will want to use “tap” instead. When single-sourcing, you can handle this with variables (reusable chunks of text). You may find this “touch gestures reference guide” useful for learning mobile terminology.

Single-source strategy:

• Manage device-specific terminology with variables
• Avoid using device-specific terminology when possible.

Writing style

Writing concisely is a good best practice for all outputs. Concise writing also improves usability and cuts down on translation costs. Make topics easy-to-scan and keep information short and to the point.

Single-source strategy:

• Review and revise content to make it more concise.
• If there is content that is useful, but not necessary for mobile Help, you can mark this content with conditions so that it only appears in desktop Help and print manuals.
• Variables can be used to display targeted content to different outputs.

Formatting

Collapsible text (which also adds to the usability of desktop Help) is a great way to make information more readable in mobile outputs, because it can be used to “chunk” content logically and users have control over which details they’d like to display.

Bulleted and numbered lists may take up valuable real estate in mobile outputs; experiment with using conditions to create lists without bullets and numbering and see if they are more readable in mobile outputs.

When creating links within topics, make sure none are placed too close together, because users could touch more than one link at a time. You may want to move all links to the bottom of each topic, and/or convert the links to buttons for mobile.

Single-source strategy:

• Incorporate collapsible text for longer topics.
• Consider using conditions to remove bullets/numbering from mobile Help.
• Move links to the bottom of each topic, or make sure that links aren’t placed too close together.
• Links that need more prominence can be displayed as buttons.

Video

Approximately one billion YouTube videos are streamed on mobile devices every day, so you may want to consider adding additional videos for mobile outputs. Using more video and less text may be the optimum mix for your mobile outputs, and videos are also valuable in desktop Help.

Indexes

Indexes are not necessarily needed in mobile Help (because using Search is preferable in this environment); if you’ve created an index for desktop Help and manuals, you may choose to hide it in mobile outputs.

Single-source strategy:

• HAT should provide ability to hide the index in mobile Help.

Testing

Testing mobile Help on devices is optimal, but with over 200 on the market, you will probably need to use emulators instead. See www.mobilexweb.com/emulators and Joe Welinske’s book: Developing User Assistance for Mobile Apps. Another site that is good for a quick test of your Mobile Help in different size windows is Resize My Browser. (Since Resize my browser uses the browser on your machine, it doesn’t provide an exact picture of how your content will render.)

Go mobile

Mobile Help can be accessed almost anywhere – and can be created as part of your single-sourcing strategy. Just consider the environment and constraints, and follow a few best practices. And some of the changes made for mobile can improve other outputs at the same time. Remember our aim to get the right content, well designed, to the right places. Enjoy going mobile.

Further reading and references

• Ten best practices for your mobile website
• Ten mobile site best practices 
• Mobile web design best practices
• Mobile in the enterprise infographic from gigaom.com 
• User interface guidelines for mobile and tablet devices 
• Touch gesture reference guide by Craig Villamor, Dan Willis, and Luke Wroblewski
• Carroll, John M. The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill, MIT Press, 1990
• Welinske, Joe. Developing User Assistance for Mobile Apps, WritersUA, 2011
• STC Intercom Magazine, November 2011 issue “Tech Comm on the Move: Mobile Communication Technologies and Strategies”