Your SlideShare is downloading. ×
Overcoming design challenges in HAT-based multichannel publishing
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Overcoming design challenges in HAT-based multichannel publishing


Published on

Published in: Technology, Design

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 (  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 Twitter: NeilEric