In this session attendees will learn: Technical options for going mobile, including responsive design, converting traditional online help to an app, and creating a “true” app using RMAD (Rapid Mobile App Development) tools. The pros and cons of each approach and some of the tools available for creating each option. Anticipated changes in content creation practices and workflows including the elimination of local formatting, adoption of a “mobile first” philosophy, rethinking the role of tables, and more. How company issues like terminology standardization, strategic benefit, politics, and the development of metrics and standards can help or hinder a move to mobile.

1. We’re Going Mobile!
Great!
But Are We Ready?

2. We’re Going
Mobile! Great!
But Are We Ready?

3. Who Am I?
• Neil Perlin - Hyper/Word Services.
– Internationally recognized content consultant.
– Help clients create effective, efficient, flexible
content in anything from hard-copy to mobile.
– Certified – Flare, RoboHelp, Mimic, Viziapps.
– Working in mobile since 1998.
– Certified app development consultant and trainer.
– Lynda.com® author of training for Flare 12,
RoboHelp 2015.

4. Three Questions
• How to go mobile?
– Without repeating the definition errors of the old help
days.
• How should our development practices change?
– Don’t keep developing in ways that can cause trouble.
• How should our business processes change?
– Without supportive processes the effort will fail, or is
a one-off at best.

5. Three Options for
Going Mobile

6. 1 – Responsive Output
• Creating one web site/help output that can detect
a display device’s properties and automatically
reformat itself accordingly.
– Vs creating one site/output for each device.
– Properties include screen size, resolution, if the
device has a screen, others.
• Developed by Ethan Marcotte in 2010.
– See http://alistapart.com/article/responsive-
web-design/
• For example…

7. Pittsburgh Children’s Museum

8. Flare

9. Notice…
• The skin changes as the screen size changes.
– Set up using the Skin Editor.
• The content layout changes as the screen size
changes.
– Set up using the Responsive Layout Editor.
• The text can change as the screen size changes,
like “click” to “tap” – truly adaptive content.

10. And RoboHelp

11. Responsive Design Issues
• Skin properties are global.
• But content layout properties are set topic by
topic.
• So defining content layout properties requires
planning.
• As does adaptive text.

12. 2 – “Appified” Help
• We don’t think of apps from a tech comm
perspective.
• But if our help is largely text and images, these
examples of apps could have been created by
tech comm.

13. “Appified” Help Examples
• Reference – Messier List

14. “Appified” Help Examples
• Reference – Encyclopedia Britannica

15. “Appified” Help Examples
• Procedures/tasks – Drop

16. How To Appify Your Help
• Capability is built into RoboHelp 2015 +.
• Uses Adobe PhoneGap (http://phonegap.com/).
• Process gets into new areas but see this post by Robert
Desprez – http://tinyurl.com/h2y27o2
• PhoneGap or the cloud-based PhoneGap Build
(https://build.phonegap.com/) also works well
with Flare but isn’t built-in.
• I spoke on appifying a Flare target at MadWorld 2018.

17. • Here’s a simple RoboHelp 2015 project output
as an Android app using PhoneGap.

18. Notice…
• The multiple TOC levels came through, but with
no indent.
• The h1 style got funky in the conversion.
• Popups convert to hyperlinks.
• Everything else – index, search, glossary, and
dropdown and expanding links – seems to work.

19. • Here’s a simple Flare project converted to an
Android app using PhoneGap Build.

20. Notice…
• The flyout and (simple) TOC came through.
• The styles appear to have come through fine.
• Want to try this yourself?
– See PhoneGap Essentials by John Wargo or email me.
– See my post in the May 2017 MadCap blog –
http://www.madcapsoftware.com/blog/2017/05/18/co
nvert-madcap-flare-target-mobile-app/

21. • HTML5 output is effectively a web app…
• But do these examples look like what you expect
of an app?
• You can modify the look by using jQuery Mobile,
Dojo Mobile, or Sencha Touch.
• Or use the PhoneGap APIs to add features like a
camera, accelerometer, geolocation, and more.

22. • But if you don’t have the skills, inclination, or
time to work with the code, how do you get
from this:
• To this:

23. 3 – “True” Apps
• If you need the look and features of a “true” app,
the last few years have seen the emergence of
code-light or code-free app development tools.
• Also called DIY app tools.
• Categorized by Forrester Research as Rapid Mobile
App Development (RMAD) tools.
• Goal – let non-programmers create apps and let
programmers create them faster.
• Here’s one example, ViziApps…

24. ViziApps

25. Other RMAD Tools
• See “10 simple tools for building mobile
apps fast” at http://tinyurl.com/hzz4j5c

26. Why Go To Full Apps?
• User expectations – again...
• Adds new capabilities to traditional content –
device location or orientation-based content,
built-in camera, RSS feeds, transaction
processing, and more.

27. Some Effect on
Development
Practices

28. No More Hacks
• “A hack is a one-off; good coding is forever.”
• Get rid of existing hacks.
• No more new ones.

29. No More Local Formatting
• This: <p class=“abc” style=“margin-left: 12px; text-
align: left;”> vs. this: <p>
• Inefficient and overrides the styles in your CSS.
– Not a mobile issue per se, though it bulks up files
and may slow downloading.
– But also just bad coding practice.
• Replace local formatting with styles.
– May mean cleaning up the CSS.
• Switch from points to a relative size unit.

30. Write for Mobile First
• “…often… mobile for a Web application or site
is designed and built after the PC version…
Here's three reasons why Web applications
should be designed for mobile first instead.”
– 1. Mobile is exploding
– 2. Mobile forces you to focus
– 3. Mobile extends your capabilities
» Mobile First, Luke Wroblewski
» http://www.lukew.com/ff/entry.asp?933

31. Rethink Your Writing Style
• Start planning now to make your writing:
– Shorter.
– More granular and focused.
• Say goodbye to concepts, maybe even to full
sentences.
• Consider the effect of screen rotation on design.

32. Eliminate Excess Content
• Focus on new knowledge rather than legacy.
• You can edit content but, at some point, its style
will change.
• May be easier to rewrite existing content from
scratch.
• “The wind was a torrent of darkness among the
gusty trees.” (The Highwayman, Alfred Noyes)
• To, with apologies to Alfred: “It was windy.”

33. Rethink Tables
• Given the trouble fitting tables into small device
screens, rethink what tables are and how to use
them?
• Is a table a container for multiple content pieces, only
one of which is needed at a time?
• If yes, can you replace tables with searches?
• Look for presentation alternatives that may be
more suitable for tiny screens.
– Or no screens.

34. Get Techie
• Get familiar with CSS – ideally at the code level
but at least conceptually.
• Ditto Javascript.
• Be able to go beyond your GUI tools, support
features like adaptive content.

35. Consider Changing Navigation
• Indexes are going away.
• They’ll be replaced by search.
– Flare’s “new” topnav skin has no place for an index.

36. Use Up-to-Date, Open Tools
• Look for tools that support new features like
responsive output, and get rid of old ones.
• 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.
– Such as RoboHelp’s multilevel list problem.

37. Start Looking Forward
• Think about:
• New interfaces – Consider voice, touch, haptic(?).
• Accumulating user search information to improve
your material now and for “the data halo” (Cognizant)
down the road.
• The bigger picture – Information 4.0.

38. Business Practices
to Look At

39. The Business “Foundation”
• Strategic definition – why do this?
• Technical definition – what is “mobile”to you?
• Tools – are your tools appropriate?
• Training – do authors know how to use them?
• Standards – are they in place? Followed?
• Development metrics – how long does this take?
• Usage analytics – do users read the stuff?
• Governance – workflow control?
• Benchmarking – are we doing a good job?

40. Hyper/Word Services Offers…
Training • Consulting • Development
Flare • Flare CSS • Flare Single Sourcing
RoboHelp Troubleshooting, Conversion to
Flare
ViziApps
Single sourcing • Structured authoring

41. Thank you... Questions?
978-657-5464
nperlin@nperlin.cnc.net
www.hyperword.com
Twitter: NeilEric