Re: DTV antennas?

On Thu, 17 Jul 2008 09:36:22 -0700, "Joel Koltner"
<zapwireDASHgroups@xxxxxxxxx> wrote:

"Jeff Liebermann" <jeffl@xxxxxxxxxx> wrote in message
news:idjt74lqkr1amea1kpgsolm8cit15ro5c2@xxxxxxxxxx
Incidentally, I've been told that about 90% of tech support questions
are answered in the documentation or web pages. That implies the 90%
of the customer base has some form of written or on-screen learning or
communications problems.

I don't think that necessarily follows. Plenty of times people have problems
because...

1) They don't *think* to read the documentation/web pages

How about they can't find the documentation to read? Ever try to
actually read the help files? I mean linearly start at one end and
read to the other end. It's not easy, rough reading, totally
disjointed, and fairly difficult. Yet, the few users that actually
tried the built in help did exactly that. They expected it to read
exactly like the printed documentation and were instantly lost when
confronted with something different. Similarly, the documentation on
disk is often difficult to find and use. I recently installed some
wireless card that had the docs on disk. The problem was that I had
to slog my way through 2 splash screen, several "click here to do
something obvious", and a list of obscure menu choices on a garish
page, in order to get to the docs. To insure failure, the search
feature would only work on single words.

My guess(tm) is that most of the called did try to find or use the
help, but failed.

2) They don't *want* to read the documentation/web pages

Well, I don't want to read the docs either. In fact, I don't. I
consider it a personal disgrace to need to read the docs. If the
product were any good, it wouldn't need any docs. My customers also
fail to appreciate the merits of me reading the docs in their
presence. The usual question is "do you know what you're doing?"
implying that reading the docs is somehow a mark of technical
ineptitude. Until we find a way to eliminate the stigma from reading
the docs, NOBODY is going to read them.

3) The documentation/web pages are so poorly arranged that it's difficult to
find the information

I have quite a few opinions on this topic. I'll supply just one
observation. Manuals that are full of illustration and examples work
far better than big thick wordy creative writing projects. In other
words, a picture is literally worth 1000.0 words.

What has happened in my chequered past is that the docs mirror the
personality of the tech writers. If the writers have a military
background, the docs will resemble at military field manual with lots
of decimal numbered sections, huge parts lists, monstrous indexes, and
very little in between. If the writer has a flair for illustration,
it will resemble a picture book or cartoon book. If the writer has a
classical education, it will be as if Shakespeare had written the
instructions.

Worse, it is literally impossible to scribble a manual that will
satisfy everyone. I previously had an old cartoon from Mad Magazine
on my office wall. It was a scene from a TV drama, as edited by all
those involved in the production. All were radically different and
slanted in the preferred direction of the author. There was also a
similar cartoon in EDN(?) magazine, showing a child's swing, and the
various ways different engineering and field service departments
butchered it into something useless.

The same applies to the target audience of a manual. If you're
writing for a couch potato, with a grammar skool education, the copy
is not going to make a professional programmer very happy. Similarly,
targeting the programmer, is going to make the manual unintelligible
to Joe SixPack. I have some ideas on how to partially solve this
dilemma, but that can wait for another rant.

I've listed these in what I think is the order of frequency.

I don't have enough experience playing support to do the same.
However, I once had access to the support logs from a rather large
domestic support organization. I vaguely recall that reading the
manual to the customer over the phone was a common activity, which
implies that they either didn't have the manual, didn't want to read
the manual, or couldn't understand the manual. I have no numbers to
separate the probable causes.

That being said, we've still come a long way where, today, pretty much anyone
can sit down at a PC and create a document with various fonts, typefaces,
colors, margings, graphics, etc. in on time flat compared to the old days of,
e.g., DOS WordPefect 5.1.

Agreed. I still occasionally use vi and nroff for word processing,
but am slowly switching over to GUI based processors. Many years ago,
I challenged a fast typist to a race between her using MS Word 97 and
me using vi, nroff, spell, and such. We picked 5 formatted pages of
text from a book and started typing. She was faster on the typing,
but I caught up when it came time to format and print the result. I
lost because I had to lookup a few nroff dot commands. Both were full
of mistakes but that was to be expected.

What has really happened is that the users of function key driven word
processors (IBM Displaywriter, WordPerfect) and <ctrl> key driven word
processors (Wordstar), have been displaced by GUI driven word
processors. Back in the days when there was still somewhat of a
choice, various tests showed the GUI driven variety to be the slowest,
most error prone, but easiest to learn, of the bunch. Whether this
constitutes an improvement, is subject to debate.


--
Jeff Liebermann jeffl@xxxxxxxxxx
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
.

Relevant Pages

  • Re: Controlling (La)TeX
    ... documentation based on an excuse may be correct, ... but some people mostly learn by reading ... I suspect more people have always tried ... read automibile manuals, don't read microwave oven manuals, don't ...
    (comp.text.tex)
  • Re: Controlling (La)TeX
    ... correct that many users tend not to read documentation, ... by reading and others mostly learn by trying. ... (remember that we're talking only about computers here - the way I learn ... automibile manuals, don't read microwave oven manuals, don't don't read ...
    (comp.text.tex)
  • Re: Python documentation moronicities (continued)
    ... Somehow I didn't see that link in the ... documentation. ... And please do not make any assumptions about my reading of manuals. ...
    (comp.lang.python)
  • Re: Hyperref queries
    ... TeX documentation really does need to be re-written for people who are ... Indeed - I can work with car maintenance manuals, ... Another difference with TeX is that it's not just a toolbox - it's more ...
    (comp.text.tex)
  • Re: 50G flag -78
    ... I wonder why it back-referenced all the way to the HP48; ... if one does pay a visit, a more recent AUR will be found. ... is that it is listed as a documentation download on the 50G Manuals ...
    (comp.sys.hp48)