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

No notes for slide

Overcoming design challenges in HAT-based multichannel publishing

  1. 1. Overcoming Design Challenges In HAT-Based Multichannel Publishing
  2. 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. 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. 4. First, Some Mobile Basics
  5. 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. 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. 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. 8. Apps and Tech Comm  And compared to “normal” tech comm, apps are different…  Sometimes weirdly so…
  9. 9. Apps and Tech Comm  And yet, this is “doc”.  As is this…
  10. 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. 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. 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. 13. Help vs. Mobile – Conversion Challenges and Suggestions
  14. 14. Text-Heaviness  Help usually text-heavy, apps not.
  15. 15. Text-Heaviness  Though there are exceptions, sort of…
  16. 16. Text-Heaviness Suggestion down text – not fat but real text – to the bare bones.  A less extreme version of this, perhaps…  Cut
  17. 17. Control Positioning  Usually at top and left in help…
  18. 18. Control Types and Locations  But at the bottom in apps – less tap risk…
  19. 19. Orientation  Landscape in help, portrait (typically) in apps.
  20. 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. 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. 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. 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. 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. 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. 26. And More Still…  You can mobile-optimize your regular site using tools like Mobify or DudaMobile (http://www.dudamobile.com/)  For example…
  27. 27. Web Apps – Creation  Here‟s my regular web site from January…
  28. 28. Web Apps – Creation  Same web site on an iPhone 5… – Works fine via scrolling, pinch and zoom – But hard to use.
  29. 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. 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. 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. 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. 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. 34. Hyper/Word Services Offers… Training • Consulting • Development  ViziApps  Mobile Flare • Mobile RoboHelp  Flare • RoboHelp  Mimic  Single sourcing • Structured authoring
  35. 35. Thank you... Questions? 978-657-5464 nperlin@nperlin.cnc.net www.hyperword.com Twitter: NeilEric