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

Subject: Re: Shipping a product with only the online help [long response]
From: Eric Thomas <eathomas -at- DBITS -dot- COM>
Date: Wed, 21 Oct 1998 09:54:38 -0500

At 10:27 AM 10/21/98 -0400, Karen Molloy wrote:
>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.

One of the biggest challenges of this, I've found, is that depending upon
how you're creating your printed documentation, Acrobat Distiller can
really mangle the images. At one point, my company was considering
providing PDF versions of our printed manuals on the CD, but I could never
get the images to look anything better than totally blurry. So we gave up
- especially after having several discussions with Adobe and being told "we
know about the problem - but there's nothing we can do right now."



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

Personally, if I was in your shoes, a printed installation guide is a must.
We have three manuals, of which the installation one is by far the
smallest (around 20 pages), and although I personally would lobby against
not providing the other two manuals at my company, I would only put my foot
down when it came to the initial installation. As for readme files -
they're great, if the person installing the program looks at them before
they run setup.exe.


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

I have to comment on this one. As a tech writer, I've found myself getting
involved in the user interface design of our product - and totally loving
it. It is so true that if the UI is good, then there's less to have to
explain. So by being in on this from the start - and helping craft UI
standards, and sitting on an oversight committee for the user interface - I
really can make my job easier, and, more importantly, the product better
for end users.


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

Nice quote. Looks like I'll have to go to Borders tonight... ;)


>
>Karen Molloy
>
>karen_molloy -at- i2 -dot- com
>
>From ??? -at- ??? Sun Jan 00 00:00:00 0000==
>

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




Previous by Author: JavaHelp vs. HTML Help in a Java application
Next by Author: Re: SCREAM CAPTURES
Previous by Thread: Re: Shipping a product with only the online help [long response]
Next by Thread: Profession Ethics/Standards


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


Sponsored Ads