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

Overcoming design challenges in HAT-based multichannel publishing






Total Views
Slideshare-icon Views on SlideShare
Embed Views



1 Embed 134

http://lavacon.org 134



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.

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

    Overcoming design challenges in HAT-based multichannel publishing Overcoming design challenges in HAT-based multichannel publishing Presentation Transcript

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