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.
You all seem to be forgetting the "value added" aspect of THICK printed
manuals. When a customer pays $500+ for a package, they want something
HEAVY to carry out of the store.
> Geoff,
> I think I'll play devil's advocate here to stimulate our little tech-writer
> brains :-):
> > In response to the original poster (now lost in the mists of time and
> > digestion) who asked how to justify retaining paper documentation, I'd
> > provide the following rebuttals:
> > - A few posters noted that you can't read online info. in the bathroom
> > (unless you're a real wirehead and have LCD screens right above the
> > toilet paper). You also can't read it while commuting; based on
> > personal experience, and the number of manuals I've seen being read on
> > subways, trains and airplanes, this is significant.
> Well, you can read help on an airplane, etc., if you have a laptop.
> (Hopefully, no famous TV actors will appear on the screen while you do
> this... :-)). The programming manager who suggested the idea may state that
> the number of users who will require a paper manual is insignificant
> compared to the cost of the manual. A personal anecdote may not be enough
> for this guy. Geoff, honestly, did you really see if those people were
> reading software manuals? How many did you see being read? What percentage
> of the people who work while commuting read software manuals? What
> percentage of people who work while commuting would be able to find
> something else to do besides read software manuals? ... I think without
> data, this argument won't wash...
> However, I think it is a good argument in general. People *like* books...
> because of their convenience. We just need some data to back ourselves up
> with this one....
> > - There are sometimes significant hardware and/or network requirements
> > for online help.
> This is not a consideration for every application and environment though.
> For instance, in my situation, my client has a series of LANs connected to
> the WAN throughout the state. There is plenty of room for the help systems.
> So this argument is good, but may not sway the engineering manager in every
> case.
> What about CD ROM... Plenty of room for online doc!
> > - Most online help can't be displayed on-screen at the same time as
> > the application it refers to; this can be due to deficiencies in the
> > software or inadequate hardware (e.g., my 14" VGA monitor has no
> > room). Thus, you have to toggle back and forth between the help and
> > the software, and you may also have to write down a summary of the
> > list of steps in a solution so you can follow the steps when you
> > return to the original software that posed the problem
> In winhlp, you can size the help screen to about any size you want and move
> it around the screen, so this argument would not apply to the winhlp
> environment. Also you can print topics, so for some of those longer or more
> complicated procedures you can hang them up next to your 'puter.
> I think we need to go to the users on this one. I think we need to start
> doing studies, assembling information, and writing papers, journal articles,
> and articles for the popular PC press. I think as individual writers, we
> have to ask our users.
> I believe that even in the winhlp environment, users need or want a book,
> along with the hlp. The type of book will depend on the user and the
> application. In my current environment, we designed the help to be the
> full-fledged documentation and have designed the docs as tutorial guides.
> As was noted before, this would not fly in every environment. We did demos
> with our users before trying this and got buyoff. Unfortunately, we're
> still in an early stage of delivering the on-line help, so have not gotten
> full feedback on if our solution worked.... We've gotten feedback on the
> tutorial docs and they seemed to pass muster so far...
> But our audience is unused to *any* type of documentation and that might
> make a difference. They may be more open to learning to rely on online
> systems, especially since they will be able to print, not only single
> topics, but all or a portion of the topics. Perhaps some of the resistance
> to online docs is based on what users are accustomed to....
> Personally, I look in the help first. Then if the info isn't there I resort
> to the document (and yes, I am an avid reader). I would use a document to
> train myself, then put it aside when I got more facile with the system. The
> studies that "minimalist" documentation were based on seem to match my
> personal style. (Sorry I can't give references for minimalist doc now; my
> stuff is at home and I'm at work...).
> > You could probably prove your point by sitting down with the engineer
> > and asking him to work in some software with online help for half an
> > hour. Push him to try new things he hasn't tried before. But take away
> > the printed manual and get him to rely solely on the online help and
> > see how he feels after half an hour.
> This seems kinda risky to me. First, he might choose an application with a
> great help system, and find it helpful. Second, he might refuse to do it
> altogether. Third, he might be closeminded and stubborn and nothing, not
> even the truth, will convince him. I believe the individual in question
> *may* be someone who has a learning style like mine and will feel
> comfortable playing around. The real point is that he -- and I and you and
> the originator of the question -- none of us are average users, and we need
> to find out what *they* want and need.
> Rose A. (the 'A' is for analytical) Wilcox
> rwilc -at- fast -dot- dot -dot- state -dot- az -dot- us
> "Never put pen to paper!"
> Lady Ida Sitwell
