overcoming design challenges in hat-based multichannel publishing

Post on 10-May-2015

393 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

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 software-related 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+, “mo-

bilizers” like DudaMobile and Mobify, Vizi-Apps.

– 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 Cut down text – not fat but real text – to

the bare bones. A less extreme version of this, perhaps…

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 mobile-optimized 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 • DevelopmentViziAppsMobile Flare • Mobile RoboHelpFlare • RoboHelpMimicSingle sourcing • Structured authoring

Thank you... Questions?

978-657-5464nperlin@nperlin.cnc.net

www.hyperword.comTwitter: NeilEric

top related