RE: any cons to single sourcing?

["Murrell, Thomas" <TMurrell -at- alldata -dot- net>]

> From: 	Mike Starr[SMTP:writstar -at- wi -dot- net] 
> 
> My position is that both the help and the printed document should contain
> the same information on the theory that most users will turn to their
> preferred method of information delivery (print, PDF, help, etc.) and if
> they don't find what they're looking for, their next step will be to pick
> up the phone and call tech support. 
> 
I'm not so sure that most people will immediately call tech support if they
don't find their answer in the documentation.  Some will, but I see an awful
lot of users asking someone in a near by office or cubicle, calling their
personal computer guru or giving up in disillusionment.  Actually, I'm not
that sure that most people even go to the documentation (in whatever form
they can get it, let alone whatever form they prefer it).  If they can't
puzzle it out, they work around it, ignore it, or simply complain about it.

> If they don't find what they're looking for, then I haven't done a good
> enough job of providing all the information they need. That's the problem
> inherent in the documentation for so many products. The information just
> ain't there!!! If it were, the users wouldn't have to call. 
> 
I'm rapidly coming to the conclusion that documentation, and hence technical
writing, is limited in how it can help people.  A strong argument could be
made, I think, that if the user has problems using the software that is the
fault of the software design, particularly the user interface design.  It is
possible that users are looking for information in our documentation.  I
have had a few contact me with the usual mix of questions, suggestions,
corrections, and abuse.  I seldom hear from most users and if I do the
contact is very indirect.  Usually they're complaining that they can't
figure out how to use the software.  They aren't looking to the
documentation at all.  They are coming to expect the software to be somehow
intuitive.

> I get extremely frustrated when I look up a control in a dialog box and it
> tells me no more than the label of the control. If it doesn't tell me how
> changes to that control are going to affect what I'm doing and why I might
> want to make those changes and what the limits of those changes are, then
> the documentation provided is insufficient. That's not the fault of the
> delivery mechanism. It's the fault of the writer for not providing
> complete
> information. 
> 
I agree with everything Mike says in the last paragraph.  However, I'm no
longer convinced that if writers do the best possible job of documentation,
in whatever media can be used, that it will be sufficient.  I know, too,
that there is no hue and cry for user analysis and user-friendly designs,
particularly for user interfaces; however, I do think that users gravitate
toward software that doesn't have to have a lot of documentation support
because they can easily figure it out and use it without having to be
bothered by the documentation.

I realize that my opinions in this area may not be popular with writers.
Frankly, I don't much like it myself.  Too often documentation is at best a
requirement fulfilled and a hope that it will correct the deficiencies in
design that the company is not willing to spend money to correct in the
implementation.  So I slog on, doing the best job of documentation I can,
knowing that few will read it, despite my best efforts.

Tom Murrell