TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> -----Original Message-----
> From: jimmy -at- breck-mckye -dot- com
> > In the next ten years, I expect improved reporting on how people use
> > help will have far more effect on how we produce that help than any
> > changes on the back end or improvements to authoring or presentation
> > tools.
>
> On a related note, I think anyone rolling out web help needs to look
> into using web analytics - even free, off-the-shelf solutions like
> Google Analytics. Hard data about what people are reading - and more
> importantly, what people are reading and leaving without needing to
> re-search for more help - is the sort of evidence no stakeholder can
> argue with.
This would be where you create WebHelp that runs on a server
in your own company?
If you are writing WebHelp to accompany a product that you
sell to other companies or to private individuals, then
the options appear to be:
a) it's deployed on the user's own hard drive, so the
analyzer would need to be an executable running on
the user's own system (perhaps hidden in your
application program), and you'd need a way to get
the analysis results back to your own company;
b) it's deployed on a server in the customer's IT
department, and serves WebHelp to people in their
premises or on their WAN/VPN... and you need
the server to phone you and dump the data and/or
analysis.
Do you have customers who are that lax about their
own security? What industry is that? If we tried
that, it would amount to offering the keys to the
kingdom to our competitors. It would be considered
a "back door".
> >> What I liked about the idea was that the system grew in response to
> >> users' questions. Instead of shipping out a fixed help system that
> is
> >> simply updated periodically, we would provide something that would
> >> grow as people used it.
> >>
> >> Obviously, you would need to keep control of the content and
> >> organization. But your customers' actual needs would define the
> scope
> >> and guarantee that it was helping them. Wow.
> >>
> >> While I appreciate the cautionary replies you've received, there
> >> *are* real innovations out there that you can investigate. I do
> >> thoroughly agree with this idea: The most important source of ideas
> is
> >> your end user.
>
> Ah, but the devil's in the implementation. How do you get users to
> effectively communicate their needs? How do you make sure that users
> with unusual requests or requests they otherwise can't articulate
> easily
> still get served? And what happens when users aren't aware of the full
> gamut of deliverables? There's the rub...
Indeed. And I've pointed out some barriers to simply
automating the collection of data.
-k
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. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
