Re: Shipping a product with only the online help [long response]

[Karen Molloy <Karen_Molloy -at- I2 -dot- COM>]

John David Hickey wrote:

>To my dismay, my project leader has decided to try sending out a product
>with only the online help. No installation guide, no user's guide. He says
>he'd like to see how much the customer's complain when they don't get any
>documentation.

I always thought online help *was* a type of documentation.

Some products are sold (and used) these days without manuals; but they do
have online help. Without knowing what your product is, it's hard to assess
whether shipping with only online help will be a problem for your users.
This depends on the product and the documentation requirements you and
others have assessed that your audience needs. What do you want to provide
in a manual that you think will not be served well in online help form?

Your project leader has stated a peculiar reason "to see how much the
customer's complain" for not providing manuals, but I wonder whether that
is the real or only reason. Your post doesn't state whether this is a
financial issue. If so, and you feel your company should be providing a
manual in addition to online help, perhaps shipping a manual in .pdf form
on the installation cd would solve that problem. Many companies provide a
.pdf manual, not a hardcopy one.

Geoff Hart wrote:

>Personally, I can't imagine receiving software without so much as a
one-page
> "to install the software, double-click on the Install icon then follow
the online instructions" guide.

Often this kind of info is part of a Readme.txt  file. Depends on the
product. Many do not require an installation guide.  If the installation is
via a wizard such as InstallShield, you can provide online help with it.
Also, you can provide clear text in the wizard dialog boxes themselves.
Again, this depends on the product and the audience profile. If the product
is an enterprise client/server product, it  may require more installation
documentation.

>I've been able to figure out most software installs from the
>online docs and readme file, but then I'm not a typical user.

But we don't know what the "typical user" is in this particular case,
right?

>One can only hope that the manager's same solicitous attitude towards
>your customers doesn't extend to the user interface too.

It's amazing how far a good interface can go in minimizing what you have to
explain in the documentation.

This leads me to quote  from Don Norman's new book, "The Invisible
Computer":

> * Technical writers -- People whose goal should be to show the
technologists
> how to build things that do not require manuals.
> Technical writers traditionally have the cleanup job. When all is
> finished, they are called upon to make it look like the entire design was
> carefully orchestrated as a systematic whole. They are the cleanup
> artists, and often they get the least respect of all.
>
> Technical writing is a difficult skill. It requires understanding the
> audience, understanding what activities the user wants to accomplish, and
> translating the often idiosyncratic and unplanned design into something
> that appears to make sense.
>
> To a user-experience architect, the technical writers should be the key
to
> the entire operation. Have them write the simplest, most elegant manual
> imaginable. Reward them for brevity. (Would you believe that some
> technical writers are rewarded for the length of the manual, as if a long
> manual is somehow more valuable than a short one? That is certainly
> perverse.) Test the manual to make sure people can follow it. Then build
> the device to fit the manual. The technical writer should be a crucial
> part of the development team. Indeed, if the technical writer is
> completely successful, the device will be constructed so well, with such
a
> clear conceptual model, that no instruction manual will be required.


Karen Molloy

karen_molloy -at- i2 -dot- com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=