RE: merging Robohelp projects?

Subject: RE: merging Robohelp projects?
From: <Brian -dot- Henderson -at- mitchell1 -dot- com>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Mon, 4 Jun 2012 09:55:28 -0700

I think the problems with Help that Kevin talks about here should be one
of the top pet peeves of any professional tech writer. Seems to me there
are many more examples of bad Help design/organization than good ones.
So many more that I now consider it a small miracle whenever I encounter
Help done right.

(Disclaimer: The intensity of my feeling on the subject may be due to
the fact that I'm currently working on a project that involves reading
owner's manuals from every automotive manufacturer on the planet.)

-Brian H.

-----Original Message----- From: Kevin McLauchlan

I think one of the things that I really like to see on Help pages is
Too often, some random help page just jumps into its own little
procedure, with all kinds of unspoken (unwritten) assumptions about how
the user/reader got there, and why they need to do what they're being
told to do right now, and what they should already have done.

As someone who can occasionally be found on this list likes to say
(might be the title of his blog...) "Every page is page one."

It's not like a book that has Intro and flow and continuity. A person
entering help might enter it at any point, for a variety of reasons.
Useful help has to let them know that they are in the right place, as
well as tell them the actual steps to do what they came for... if it
turns out they've actually landed on the page they needed... and not one
that has a similar/related procedure, but which doesn't apply to their
actual situation... and might actually hurt their situation if they
don't clue-in in time.

So a help page that includes a procedure should provide the continuity
by saying explicitly where it assumes the reader is arriving from, and
maybe what steps they should already have taken or what state they (or
the product) should already be in, for the current help page to be

ON THE OTHER HAND... :) Your structure and visual conventions should
show an experienced reader where the meat starts, so they can quickly
skip over the orientation material, if it's old-hat to them, and they
just want a refresh on the particular steps of procedure XYZ.

One of the biggest problems I encounter with Help on the web (if only
Microsoft and Adobe and others were listening) is knowing enough
background to decide that I'm on the right page for what I need. I
usually arrive from a Google search, so the specific instructions on the
page I'm reading might be perfectly accurate and easy to follow... but
completely wrong for what I need to accomplish. Or, it might be
completely right, but it just sounds wrong, because it appears to be
talking about something different than what I thought was my problem or
task. Glue. Glue is good.

Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.

Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @


merging Robohelp projects?: From: Becca
RE: merging Robohelp projects?: From: Myles Owens
Re: merging Robohelp projects?: From: Rick Stone
Re: merging Robohelp projects?: From: Becca
RE: merging Robohelp projects?: From: McLauchlan, Kevin

Previous by Author: RE: TECHWR-L Digest, Vol 80, Issue 10
Next by Author: Dilbert Today
Previous by Thread: RE: merging Robohelp projects?
Next by Thread: Re: merging Robohelp projects?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads