Describes the philosophical, programming, methodology, and business standards needed to keep technical communication current in an increasingly technical era.

1. Developing for
the Unknown
Future-Proofing Our Work
and Jobs, and Introducing…

2. Who Am I?
 Neil Perlin - Hyper/Word Services.
– Internationally recognized content consultant.
– Help clients create effective, efficient, flexible
content in anything from hard-copy to mobile.
– STC‟s lead W3C rep – ‟02 – „05.
– Certified – Flare, Mimic, Viziapps, RoboHelp
in process of renewal.

3. The Problem…
 In the past, technical change was unexpected.
 Today, we know it‟s coming, just not the details.
 Content must be efficiently extensible,
including to changes that don’t yet
exist or are dissimilar.
 This means we can no longer:
– Violate syntax and hack code to be cool.
– Exploit tool peculiarities to take shortcuts.
– Not understand the future.

4. The Solution
 Consider the future, even if unknown.
 By setting and following standards for:
– Philosophy.
– Programming.
– Methodologies and procedures.
– Strategic business support.

5. Philosophy

6. Philosophy
 Remember our main competitor…

 Think web, web-side access, multi-device, SEO.
– Local formats fading in a web-oriented world.
 Think open source, standards compliance.
 Keep up.

7. Programming

8. In General
 Automate everything possible.
– But never fully trust an automated process.
 Follow standards and best practices.
 Use tools properly for future compatibility.
 Learn about your outputs, tools, technologies.
 Use styles and style sheets for anything you can.

9. CSS Recommendations
 KISS and document it, esp any unusual features.
– Don‟t assume your successors will understand them.
 Use CSSs for char styles as well as paras, other.
– Supported by Flare, RH,
others…
» To avoid local
formatting, hide
text formatting
toolbar and use
style pod/pane.

10. CSS (cont‟d)
 Give custom styles unambiguous names.
 Review CSSs often to eliminate “barnacles”.
– Like H1, head1, and heading1 styles.
 Don‟t use multiple CSSs on the same topics –
elegant but potentially confusing.
 Validate CSSs for adherence to W3C syntax.
– Try http://jigsaw.w3.org/css-validator.

11. Validation Example
 For example, this page:

12. Validation Example
 Gives this result from the Jigsaw validator – the
question is whether these errors matter.

13. CSS (cont‟d)
 Checkthe browsers your apps use and see what
CSS settings they support correctly.
– www.webdevout.net/browser-support-css

14. CSS (cont‟d)
 Switch from absolute to relative style size units.
 Vital for extensible single sourcing.
– %, Ems, Exes vs. points.
» % and Ems resizable by browsers, Exes resizable
but not well supported, points not resizable.

15. Why Relative Sizes?
 Image at absolute width in
a too-narrow space.
– Note horiz. scroll bar.
 Relative width in same space.
– No horiz. scroll bar, width of
50% makes browser show
image at 50% of available
space – e.g. “relative”.
– In effect, each browser does
the formatting for you.

16. Media Types/Mediums
A feature of the W3C‟s CSS2 standard.
– See http://www.w3.org/TR/CSS2/media.html
– Called “mediums” in Flare.
 To define alternate style settings for different
outputs within one CSS – easier maintenance.
 Consider using media types if you single source
to multiple outputs.
 Extended in CSS3 to “media queries” that drive
“adaptive content”.
– And for HTML5, the basis for “hybrid apps”, more.

17. Local/Inline
 Hard to update effectively.
 Hard to import to new formats.
– To eliminate, you may have to:
» Look for local formatting in the first topic.
» View that formatting code.
» Replace the local formatting
code with a CSS style in all
your topics in code view.
» Repeat…

18. Table Styles
 Ifyour authoring tool allows, create and use
CSSs for tables 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 just makes it easier to visually
integrate all the table elements.

19. Topic Templates
 Define topic templates to control:
– Structure of material for each type of topic.
– Boilerplate content for each type of topic.
 Apply the CSS to all templates to automatically
give topics the structure plus the styles.
– Moves you toward structured authoring even if you
don’t use DITA.
 Start by defining your information types.

20. Define Information Types
 Identifythe types of content you create and put
them in a few standard categories.
– 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.

21. 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.

22. 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…

23. What‟s First – Template or CSS?
 Elements in templates – heads, lists, etc. – are
the elements you must define in a CSS.
– Keep a list of them as you define the templates.
– Don‟t create custom styles if standard styles will do.

24. Define Standards Adherence
 Identify (and enforce) standards to follow, like:
– W3C code compliance.
– DOCTYPE declaration in topics to use strict/
standards vs. quirks browser mode.
» Determines if browsers render CSS features in
compliance with new, correct standards or still
work with older browsers.
– Others…

25. Methodological,
Procedural, and
Business
Solutions

26. Methodological In General
 Beforeadopting any new methodology, be sure
you understand it and it makes sense for you.
– Don‟t adopt DITA, structured authoring, topic-based
authoring, Agile, etc. because they‟re new and cool.

27. Procedural In General
 Develop in-house expertise on formats, tools,
methodologies, etc.
 “Stay between the lines.”
– Use tools correctly and avoid hacks.
– “Standards are portable and hacks aren't”
 Avoid hand-coding – slow, quirky, error-prone,
narrows your hiring pool.
 Design for flexibility.

28. Business
 Support the company – Tech comm is often the
only department that rebels at the idea.
– Starting to accept the idea of cost-justification, but
that‟s not enough.
» Pure cost-justification usually = outsourcing.
– Be able to show how tech comm supports company
strategy in ways that outsourced doc does not.

29. Business
 Get credibility – become a techie.
 Keep it – be active in product dev.
 Become a resource for subjects that IT may not
be familiar with, like sound-alike formats.
– “WebHelp” = “Web Help”?
– “HTML Help” = “HTML help”?
– “XHTML” = “XML” = “HTML 5”?
 Learnabout business – debits, credits, ROI, etc.
 And as a teaser for my next session…

30. Hyper/Word Services Offers…
Training • Consulting • Development
Flare • RoboHelp
Viziapps • Flare/RoboHelp Mobile
XML
Single sourcing • Structured authoring

31. Thank you...
Questions?
Hyper/Word Services
978-657-5464
nperlin@concentric.net
www.hyperword.com