Single Sourcing To the Max: HAT Mobile to…?

Who Am I? Neil Perlin - Hyper/Word Services.

– In tech. comm. since ‘79 at DEC.

– Creating hypertext since ’85, WinHelp since ’90, HTML since ‘91.

– Training/consulting on HATs since ’95, XML/ mobile/single-sourcing/structured authoring since ‘98.

– STC’s lead W3C rep – ’02 – ‘05.

– Certified – Flare, RoboHelp, Captivate, Mimic.

The Issue – Overview Single sourcing usually means creating outputs

for big-screen devices – desktop or laptop PCs. But new versions of HATs can single source to

mobile devices with very different attributes and requirements.

For example…

Desktop to Mobile

Desktop…

…to Mobile

The Issue How to set up projects technically to efficiently

single source out to mobile? Can we adopt these practices to single source to

other extreme outputs or those that don’t exist yet – future-proofed single sourcing.

Why Mobile – In Brief…

Why Mobile At All? Society becoming increasingly mobile.

– Mobile communication has exploded.

» “… > 2 million pay phones in the U.S. in 1997… about 1 million… in 2006 <while> Cell phones… leaped from 90.6 million to 217.4 million between 2000 and 2006… the FCC.”) (York Daily Record – www.ydr.com/remember/ci_10226075

– Mobile computing, on the other hand...

» Remember Windows CE? WML?

Why Now? Better interfaces:

– From this in 1998 –

– To this in 2010 – or

Why Now? Better applications.

– Many are silly.

– But there are more to choose from that are better accepted by a mass market conditioned by iPods, iPhones, etc.

Why Now? Better authoring experience.

– From this in 1998:

– To GUI tools or authoring within a HAT today.

The examples in the previous slides are apps. We’re not talking about creating apps here but

mobile versions of the help or content you’ve been creating using your HAT.

But the apps have paved the way.

Two Architecture Options Mobile app – Platform-specific – iPhone, iPad,

Android, RIM, etc. Mobile site – Web site for a device that follows

a standard or has a microbrowser.– Standard – Approach taken in RoboHelp with

ePub.

– Microbrowser – Approach taken in Flare with WinHelp Mobile.

Two Dev Options – 1 Platform-specific authoring – iPhone, RIM, etc.

– Pros:

» Takes full advantage of platform’s features.

» Looks consistent with other platform apps.

– Cons:

» Level of authoring complexity – IDE, server setup for mobile MIME types, emulators, etc. – may be unfamiliar to authors today.

Two Dev Options – 2 HAT-based – Flare 6, RoboHelp 8.

– Pros:

» Mobile is one more output from a tool you already have.

» Easy to back out if mobile is not for you.

– Cons:

» Won’t make full use of platform features.

» Ties you to a vendor for whom mobile may not have the same strategic priority.

Single Sourcing To the Max – Philosophy, Programming, and Strategic Support

Philosophy Our main competitor is Google. Think web. Think open source. Think standards compliance. Keep up.

Programming

In General Automate everything you can.

– But never fully trust an automated process. Follow standards and best practices. Use tools properly for compatibility with future

tools, perhaps from the same vendor. Learn about your outputs, tools, and underlying

technologies. More specifically…

Styles Overall Use styles and style sheets.

– Use CSSs for everything you can.

» Or styles if you use Word.

– Do not use embedded styles.

– Local formatting is evil – get rid of it and don’t use it again.

CSS Keep it simple. Use character styles as well as para, other styles.

– Avoid local formatting.

– If possible, hide any text formatting toolbar. Give styles unambiguous names that reflect

their content rather than their formatting:– “Book_Title” rather than “h1”.

Review CSSs often to eliminate duplicates.

CSS (cont’d) Don’t use multiple CSSs on the same topics –

cool but potentially confusing. Validate adherence to syntax, accessability.

– http://jigsaw.w3.org/css-validator.

– www.webaim.org/articles/ais Check the browsers your apps use and see what

CSS settings they support correctly.– www.webdevout.net/browser-support-css

CSS (cont’d) Document your CSS styles in general, and any

unusual features.– Don’t assume your successors will know what

the unusual features are.

CSS (cont’d) Switch from absolute to relative style size units.

– %, Ems, Exes vs. points.

» % and Ems resizable by browsers, Exes re-sizable but not well supported, points not resizable.

– Note – RH supports %, Ems, and Exes but you must type the size unit in the style field.

Vital for single sourcing in the long-term.

Why Relative Sizes? An image at an absolute width in

a too-narrow space.– Note the horizontal scroll

bar.

Why Relative Sizes? And at a relative width in that space.

– Width = 50% tells browser to show image at 50% of window space – “relative” to the available space – so no horizontal scroll bar.

– In effect, each browser handles formatting for you.

Media Types/Mediums A feature of the W3C’s CSS standard.

– Called “mediums” in Flare. To define alternate settings within one CSS for

styles to be used in different outputs– easier maintenance.

Consider using media types if available.

Embedding If you have embedded styles in files from older

projects, search for and delete them if you can.– XHTML supports embedding from its HTML

legacy, but few tools support embedded styles in their GUI, which complicates maintenance.

Embedding (cont’d) To detect, look for topics that don’t register a

CSS change.– Ex. – a topic whose h1s remain black after you

changed them to blue in the CSS.

– May occur in Word files imported into HTML.

– The problem – a style under a <STYLE> tag in the head section of the topic overrides the CSS style.

– Must fix in the code, a simple but boring job.

Local/Inline Get rid of it.

– Difficult to update styles.

– Causes problems on import to new formats. To eliminate it:

– Find and remove topic by topic in the GUI, or

– Find in the GUI, then do a multi-file find and replace at the code level.

An awful job since you don’t know what local styles were used, and thus what to search for.

Table Styles If your tool allows, create and use table CSSs

instead of local formatting. A table CSS is a standard CSS focused on table

styles, so a regular CSS works too. A table style editor simply makes it easier to visually integrate all the table elements.

All previous points re styles apply to tables too.

Topic Templates Define topic templates to control the:

– Structure of material for each type of topic.

– Repeated content for each type of topic. Apply the CSS to all templates to automatically

give topics the structure from the template plus the styles from the CSS.– Moves you toward structured authoring even if

you don’t use DITA or structured Frame. Start by defining your information types.

Define Information Types Identifying and categorizing the types of content

you create.– Concept, task description, reference, process,

show-me, troubleshooting, etc. Try to fit all content into <10 types.

– If some doesn’t fit one of the types, see if:

» It could fit if it was modified somewhat.

» It calls for a new type.

» It’s just weird.

Attributes of Good Templates Limited to your main information types. Simple to use, esp. for non-techie authors, and

needing little or no training. Self-documenting, since instruction sheets get

lost or increase perceived complexity. “Sold” as primarily benefiting users, rather than

the doc group.

A Sample “Task” Template

[delete and type the title]

[delete and type the intro description]

Date of Applicability

[delete and type the date]

Required Materials

[delete and type the tools and materials list]

and so on…

What’s 1st – Template or CSS? Elements in templates – heads, lists, etc. – are

the elements you must define in a CSS.– Keep a list of those elements when you define

your templates.

– Decide whether you need custom elements or if standard CSS elements will do.

» Like adding a “related topic” style for heads in Related Topics lists vs. using H2 or H3 style for those heads.

Define Standards Adherence Identify external standards to follow, such as:

– W3C code compliance.

– DOCTYPE declaration in topics to use strict/ standards vs. quirks browser mode.

» Determines if browsers render CSS features in compliance with W3C (IE 6, others) or do not to not break sites from older browsers.

– Section 508 for accessibility.

– Others?

Define Procedural Policies Develop in-house expertise on formats, tools,

methodologies, etc. “Stay between the lines” – Use tools correctly,

avoid hacks. Avoid hand-coding – Slow, quirky, error-prone,

narrows your hiring pool. Always design for flexibility.

Support Company Strategy All groups must support company strategy, but

tech comm is often the only one that rebels.– Tech comm is starting to accept the idea of

cost-justification, but that’s not enough.

» Pure cost-justification often = outsourcing.

– Show how tech comm supports the company in ways that outsourcing does not.

– Become a resource in areas IT may not know.

» Is “WebHelp” the same as “Web Help”, etc.

Thank you... Questions?

Hyper/Word Services978-657-5464

nperlin@concentric.netwww.hyperword.com

Hyper/Word Services Offers…

Training • Consulting • DevelopmentFlare • RoboHelp • RoboInfoMimic • CaptivateXMLSingle sourcing • Structured authoring