RE: Ideas for Help 2.0

Subject: RE: Ideas for Help 2.0
From: "McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>
To: "jimmy -at- breck-mckye -dot- com" <jimmy -at- breck-mckye -dot- com>
Date: Wed, 11 Jan 2012 17:36:37 -0500

> From: jimmy -at- breck-mckye -dot- com [mailto:jimmy -at- breck-mckye -dot- com]
> > This would be where you create WebHelp that runs on a server
> > in your own company?
> Of course. No other context would make sense.

I'm curious how many people create Help for internal
use at their own employer, or for use by external
customers, but served from the employer's website,
how many of us create Help for products that we sell
to companies or individuals, to be used on their
desktops, behind whatever firewalls and IT policies
the customers might have.

There might also be those of us who would provide
help for software, that our big customers might
serve from their own servers to their own people
(and maybe to their own further customers, with whom
we have no connection).

> > Indeed. And I've pointed out some barriers to simply
> > automating the collection of data.
> I don't like your tone. I didn't say the idea of 'iterative feedback'
> was bad, just that there were tricky details to iron out. I then said
> that those producing help online (web help as in help on the web, not
> help that's marked up in HTML but deployed locally) would find it
> useful
> to exploit analytics for ammunition when handling stakeholders.

Granted, you said (lowercase) web help, while I create
WebHelp that is never actually served on the web, and is
never, ever served by my employer. So I have no path to
collect analytics data. I'm probably not alone in that.
That's all I'm saying.

I understand that a lot of writers create WebHelp because
it is cross-platform and will therefore work on Linux, Solaris,
HP-UX, AIX, etc., using only generic browsers, with no need
for installed run-time engines, not because they expect to serve it
to the web at large. Others _do_ write for their own employers'
web servers, and do get to observe (or let an analytics engine
observe) people visiting with browsers and trying to find
stuff. That's a distinct advantage over the rest of us, who
might never see an actual customer interact with our products
or help.

In the absence of fairly blatant sign-posts (in this medium of
e-mail anyway), imputing "tone" is a subjective undertaking
at best.


The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.


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
or visit

To subscribe, send a blank email to techwr-l-join -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 @


Re: Ideas for Help 2.0: From: Nancy Allison
Re: Ideas for Help 2.0: From: jimmy
RE: Ideas for Help 2.0: From: McLauchlan, Kevin
RE: Ideas for Help 2.0: From: jimmy

Previous by Author: RE: Ideas for Help 2.0
Next by Author: RE: Techno-fuddyduddy getting anxious
Previous by Thread: RE: Ideas for Help 2.0
Next by Thread: RE: Ideas for Help 2.0

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

Sponsored Ads