1. Overcoming Design Challenges In
HAT-Based Multichannel Publishing

2. Who Am I?
 Neil
Perlin - Hyper/Word Services.
– Internationally recognized content creation and
delivery consultant.
– Help clients create effective, efficient, flexible
content in anything from print to mobile.
– Working with mobile since Windows CE and
WML/WAP c. 1998
– Certified – Viziapps, Flare, Mimic, RoboHelp.

3. The Issue
 Should
tech comm get involved in mobile?
– If we don‟t, someone else will.
 …how?
– See my workshop on “pure” apps, this session
on web apps and ebooks from HATs.
 What
to expect when we single source our
content to “mobile”?
– Let‟s take a look…

4. First, Some
Mobile Basics

5. Terminology – eBooks
 Electronic
books a
la Kindle, Nook.
– Largely linear format
and design.
– Generally sit on the
reader device.
– Good for stable,
linear material.
– Largely the focus of tech comm now, in my
experience.

6. Terminology – Apps
 Applications
for mobile devices.
– Highly focused – “micro-tasking” – compared
to PC-style applications.
– Native – Follow a platform standard, easily run
on-device resources.
– Web – (“Mobile web”.) Run in browser on any
device, can‟t easily run on-device resources,
may be mobile-optimized – e.g. WebHelp vs.
WebHelp Mobile.
– Hybrid – Combine native and web, HTML5.

7. Apps and Tech Comm
 Little
app dev from tech comm so far, in
my experience, for several reasons.
– “Mobile” is still new in the tech comm world
and companies aren‟t sure of the need yet.
– Until Flare and RoboHelp added mobile output
support, “going mobile” required a whole new
set of tools and skills.
» Like the situation in „91 when online help appeared
and „97 when online help went to HTML.

8. Apps and Tech Comm
 And
compared to “normal”
tech comm, apps are
different…
 Sometimes weirdly so…

9. Apps and Tech Comm
 And
yet, this is “doc”.
 As is this…

10. Why Terminology Matters
 Affects
choice of hardware and softwarerelated delivery “mechanisms”.
 Terminology mixups can spell disaster.
– Risks buying the wrong tools or hiring the
wrong developer.
– Like not being clear re WebHelp vs. Web Help
or HTML help vs. HTML Help.

11. Authoring Tools?
 Depends
what “mobile” you want:
– eBooks – ePub, using RoboHelp 8+, Flare 8+.
– Web apps (general) – Any HAT that outputs
browser-based help like WebHelp.
– Web apps (mobile-optimized) – Flare 6+, “mobilizers” like DudaMobile and Mobify, ViziApps.
– Native apps – RoboHelp 10, GUI app dev tools
like ViziApps, iBuildApp, appmakr, etc.

12. Why Author Using a GUI HAT?
 Why?
– You may know the tool, so you only have to
learn a few new features.
– Keep you out of the code.
– Set technical boundaries for you.
 Why
not?
– HAT may not offer features you expect in a
“real” app.
– Possible code bloat.

13. Help vs. Mobile –
Conversion
Challenges and
Suggestions

14. Text-Heaviness
 Help
usually text-heavy, apps not.

15. Text-Heaviness
 Though
there are exceptions, sort of…

16. Text-Heaviness Suggestion
down text – not fat but real text – to
the bare bones.
 A less extreme version of this, perhaps…
 Cut

17. Control Positioning
 Usually
at top and left in help…

18. Control Types and Locations
 But
at the bottom in apps – less tap risk…

19. Orientation
 Landscape
in help, portrait
(typically) in apps.

20. Some Screen Design Points
 Help
is usually created in landscape format
for large screens with the main controls at
the top of the screen.
 Mobile on tablets is similar.
 Mobile on phones is the opposite, unless
screen rotation is enabled.

21. More Screen Design Points
 Consider
the effect of
screen rotation on an
app jammed into a
portrait mode screen,
like this one:
 Can you force screen
rotation to off?

22. Some Content Design Points
 Images
may be too wide for phone screens.
– Can size them dynamically to fit by setting the
width to % and height to auto.
– But are they still legible?
– If not, can you conditionalize them out?
– If you do, does that affect the contents?
– May call for greater granularity of content…
– And need a CMS to deal with the greater # of
content chunks even if traditional help did not.

23. More Content Design Points
 Ditto
wide or “complex” tables.
 Consider SWFs.
– Won‟t run on iOS – must be MP4 or HTML5.
– Are text captions legible or must you replace
them with audio, which means creating 2+
versions of each movie.
– What happens to interactivity in a mouseless
world?

24. Still More…
 Consider
platform differences for feature
support and need to rework material.
– Minimal table support in ebook formats.
– Lack of support for Word bullets in KDP even
though Createspace supports them.
– Many more, no doubt…
 “Invisible”
problems like tables, graphics,
SWFs, popups, etc., embedded in snippets.
 Popup links that convert to jumps.

25. And Still More…
 Features
with no equivalent controls in
mobile, like Flare togglers.
 Graphics management may have to change
as graphics get stored in the cloud, perhaps
using Amazon S3.

26. And More Still…
 You
can mobile-optimize your regular site
using tools like Mobify or DudaMobile
(http://www.dudamobile.com/)
 For example…

27. Web Apps – Creation
 Here‟s
my regular web site from January…

28. Web Apps – Creation
 Same
web site on an
iPhone 5…
– Works fine via scrolling,
pinch and zoom
– But hard to use.

29. Web Apps – Creation
 Same
site partly mobileoptimized via DudaMobile.
– Aesthetics need work but now
a much better mobile site.
– Still a web site – e.g. a web
app.
– NOT a native app.
– $9/month for hosting.
– But…

30. Web Apps – Creation
 The
web and mobile versions don‟t match.
 I created the mobile version by hand.
 Because the original site was never meant
to be mobilized; the result showed it.
 Lesson – expect to redesign your content
before you can multichannel publish it
effectively.

31. A Design Tool
 Here‟s
what you have to
work with.
 Where does your thumb go?
What can you reach? What
do you obscure?
– If you‟re a righty?
– A lefty?

32. Design Conclusions
 Help
converted to mobile won‟t look like
Fruit Ninja.
 If you‟re single sourcing a help project to
mobile, plan for mobile before starting the
project.
 More than just outputting a help project to
“mobile”.

33. Summary
 Lots
of new technical, design, and output
options to balance.
– Define your terms, platforms and differences.
 It
sounds daunting, but so did the move by
tech comm to online help and the web in
the „90s and still today.
 We met those challenges – time to do so
again.

34. Hyper/Word Services Offers…
Training • Consulting • Development
 ViziApps
 Mobile Flare • Mobile RoboHelp
 Flare • RoboHelp
 Mimic
 Single sourcing • Structured authoring

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