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

Overcoming design challenges in HAT-based multichannel publishing

on

  • 471 views

 

Statistics

Views

Total Views
471
Views on SlideShare
318
Embed Views
153

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 153

http://lavacon.org 153

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Overcoming design challenges in HAT-based multichannel publishing Presentation Transcript

  • 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