[Elecraft] Parting shot

[Guy Olinger K2AV]

Well, I can't ever think about doc without thinking about good decent
hardworking people who got tripped up by doc. I keep them in my mind.
They deserve it.  It's not a "who's at fault,"  "who do we blame"
thing.  I find that people really like it when they figure it out by
themselves (not thinking about the agony of creating the doc they got,
of course).  It's good business when it happens like that.  Of course
the "neggies" will never be satisfied, and invent astounding reasons
to diss anything put out there, but one must skim those only for valid
comment (after all, pickles come in vinegar) and above all ignore
their tone of voice.

There is this other thing we continually forget, anyone technically
qualified to design something is hugely UNqualified to write the doc
for it.  Only edit after the writing for factuality.  Doc on something
needs to be written by somebody who has freshly learned how to use
that something starting from a position of ignorance.  The most
important thing in doc writing is understanding NOT UNDERSTANDING.
The engineering staff is usually completely opposite, they've never
NOT understood how that something works.  They MADE the d**n thing.

The universal, entire state of documentation across the world is still
largely trapped in paper.  A method based on web access and drill down
(not .pdf of paper doc) is something that is starting to emerge as
companies carefully work new methods with customers.  I know that
there is a lot of SAS success that will not scale down, but a petulant
refusal to explore new modes that are proving very successful
(webinars, youtube's, etc) will just have the same effect as
Yakencom's five or six year refusal to consider front end improvement:
one's own enterprise discovers the validity of new "stuff" when that
new "stuff" has taken away a bunch of customers one has taken for
granted.

People CAN do business that way, but then again, 85 percent of all
startup businesses fail, and no guarantees of a safe landing for the
15 percent do get their wheels up.  Someone walks away with your
customers, you go out of business, not even any ripples in the water
when you sink.

I have been on the RX end of calls from angry customers and listened
to a good deal of abuse.  In such a job one must develop a thick skin
or find alternate employment.  No job is worth ulcers, and not
everyone can work for SAS technical support.  I'd have to say that
most people are emotionally unqualified for that kind of work, and
that is NOT a negative slam.  It's more like saying that only a few
people are qualified to throw 95 MPH fastballs.  It takes a TALENT to
do tech support and stay on an even keel -- I'm not sure that can be
learned if it wasn't already in there somewhere.

The good tech support reps I knew at SAS **believed in** their
customers, and that kept the smile in their voice in spite of the
occasional abuse (and it WAS abuse).  It was a good day when they
could turn a snarl on the customer end of the phone to a smile.

I DO understand that a small enterprise may find some kinds of advance
just simply beyond resources.  But if said enterprise ALREADY has the
talent that can keep up a complicated web page, the foundational work
for new forms of documentation is already in place, already paid for.

73, Guy.

On Fri, Dec 10, 2010 at 10:39 AM, Joe Subich, W4TV <lists at subich.com> wrote:
>
> Guy,
>
>> I'm not arguing this on behalf of the gimme, gimme negative post
>> crowd.  There will always be some of those around.  But as I stated
>> earlier, this thread has not been dominated by those voices.
>
> Even if this thread has not been dominated by those voices, the
> calls for "how to" chapters in manuals, "You Tube" videos, Webinars,
> master classes at various hamfests, etc. are prime examples of the
> "I don't want to learn it myself attitude.  Those are the ones who
> don't want to try various settings of NR or NB to see what works in
> their particular environment, they don't want to remember (or read)
> to select Line In instead of Mic+Line to adjust "soundcard" levels,
> they don't understand the use of RF Gain, Preamp or ATT ... or that
> cross band split is not possible by transmitting on VFO B even though
> the manual documents the controls and limitations.
>
>> I remember one woman tester who became extremely angry.  She was so
>> angry she was shaking and had tears in her eyes.  When asked she
>> pointed to a couple of items in the instructions and on the screen.
>> She said, "I work hard and I do my job, and this thing is making me
>> feel stupid. I can't figure it out."  A little bit of conversation and
>> it became clear how the doc and the screen could confuse a user.  Both
>> screen and doc were revised based on her input.
>
> I'm not saying that poorly organized or confusing manuals should not
> be improved.  I am reacting strongly to those who want "how to"
> manuals that describe every possible operating or failure mode and
> detail "what to do."  I've done documentation and training long
> enough to understand that there are limits to what can be provided
> to the user on a practical economic basis and like W0YK, I consider
> the K3 manual with possibly a few minor tweaks more than satisfactory.
> The overhead costs of "how to" manuals, You Tube videos, webinars,
> etc. are something that don't belong in the cost of the radio.
>
> 73,
>
>   ... Joe, W4TV
>
> On 12/10/2010 12:34 AM, Guy Olinger K2AV wrote:
>>
>> I'm not arguing this on behalf of the gimme, gimme negative post
>> crowd.  There will always be some of those around.  But as I stated
>> earlier, this thread has not been dominated by those voices.
>>
>> When I was testing new GUI's and task setups we always brought in a
>> random sample of future users to be, and carefully observed them
>> attempting the revised clerical tasks with the new GUI interface.  We
>> did the same for certain kinds of documentation.
>>
>> I remember one woman tester who became extremely angry.  She was so
>> angry she was shaking and had tears in her eyes.  When asked she
>> pointed to a couple of items in the instructions and on the screen.
>> She said, "I work hard and I do my job, and this thing is making me
>> feel stupid. I can't figure it out."  A little bit of conversation and
>> it became clear how the doc and the screen could confuse a user.  Both
>> screen and doc were revised based on her input.
>>
>> She's good people.  Years later she was a well-respected, industrious
>> third-line manager. THAT'S who we're writing doc for.  Calling
>> everyone "lazy" who reads and does not understand is really harsh.
>>
>> While at SAS, to be fair, there were calls from some customers that I
>> would just as soon put out a hit contract on. But the bottom line was
>> that SAS' pro-customer take on customer support was a vital element in
>> growing SAS into a 3 billion dollar a year international company.  And
>> yes, in some cases they DID send a CE out to do it for them, but these
>> were very, very expensive turnkey systems that HAD to perform.  This
>> technical stuff we do is just plain hard to learn, and when some
>> improvement to doc CAN be made, it SHOULD be made.  It's good for the
>> business.  It's good for the business when they figure it out faster
>> and better with our stuff and doc than with their stuff and doc.
>>
>> 73, Guy.
>>
>> On Thu, Dec 9, 2010 at 11:37 PM, Joe Subich, W4TV<lists at subich.com>
>>  wrote:
>>>
>>>
>>>> While it IS true that I have 52 years of slogging and suffering
>>>> through electronic misconceptions and outright falsehoods enroute to
>>>> what pitifully little I know, and can definitely say that I came by a
>>>> lot (most?) of what I know the hard way, we have schools because we
>>>> value the idea that it's BETTER that something, which caused ME
>>>> half-a-life's grief to discern, can be taught to a fifth grader out of
>>>> the box.
>>>
>>> While schools (and books, etc.) can certainly teach *facts*, I know
>>> of no book or school in which students set quietly in rank and file
>>> and learn skills without practice.  Even in mathematics and science
>>> courses the teaching method requires *practice" to develop skills -
>>> experimentation if you would call it that.
>>>
>>> No student worth a plugged nickel pays tuition to University and
>>> expects to graduate the next day with the accumulated knowledge
>>> and skills of the entire faculty without attending a day of classes
>>> or spending hundreds of hours "in the laboratory."  Yet it is this
>>> sense of entitlement I see in the "I want a manual that does ... "
>>> refrain.
>>>
>>>> To wish that advantage for our fellow hams is, in a word,
>>>> civilization.
>>>
>>> It's quite the opposite of civilization ... it's anarchy or despotism.
>>> It is the expectation that someone else will do for the "entitled"
>>> individual what he is too lazy (the nicest description I can think
>>> of) to do for himself.
>>>
>>>> To fuzzily extend your documentation thinking, the only worthy
>>>> proper distribution format of a Microham box would be as a box of
>>>> parts, to insure that the purchaser "suffered" enough to be an
>>>> acceptable recipient of the Microham mojo.
>>>
>>> Not quite ... to extend your documentation thinking you would have
>>> me deliver each microHAM interface personally, connect it to the
>>> purchaser's radio and custom configure the hardware/software to
>>> work *exactly* as the purchaser expects, whether the interface or
>>> transceiver is designed to operate that way or not.  Not only that,
>>> you would expect that I would appear instantly (day, night or holiday)
>>> whenever a user wanted to add or modify an application.  I other
>>> words, I would be responsible for all outcomes rather than the user
>>> (purchaser) ... or in economic terms, the purchaser is entitled to
>>> infinite value for comparatively little consideration and "someone
>>> else" should bear the cost.
>>>
>>> When taken to its logical end, the view of documentation expressed
>>> here is that the outcome (understanding) is never the responsibility
>>> of the user.  If the user can not understand the documentation or can
>>> not make the hardware perform the way he wants (even if that is beyond
>>> the design parameters of the hardware), the fault is entirely due to
>>> deficiencies in the documentation.  This is like blaming the school
>>> because Johnny can't read even if Johnny did not attend a single class.
>>>
>>> People can debate forever what constitutes good or bad, sufficient or
>>> insufficient documentation.  However, it is not possible for any manual
>>> (or
>>> documentation writer) to anticipate every possible use scenario and
>>> provide specific "how to" details for each scenario.
>>>
>>> 73,
>>>
>>>   ... Joe, W4TV
>>>
>>>
>>> On 12/9/2010 2:07 PM, Guy Olinger K2AV wrote:
>>>>
>>>> There is an important philosophical point here.
>>>>
>>>> While it IS true that I have 52 years of slogging and suffering
>>>> through electronic misconceptions and outright falsehoods enroute to
>>>> what pitifully little I know, and can definitely say that I came by a
>>>> lot (most?) of what I know the hard way, we have schools because we
>>>> value the idea that it's BETTER that something, which caused ME
>>>> half-a-life's grief to discern, can be taught to a fifth grader out of
>>>> the box.  That IS at some level deflating for the oldies, but we DO
>>>> hope our children can use our learning as FOUNDATIONAL, and take it on
>>>> to a higher level.
>>>>
>>>> To wish that advantage for our fellow hams is, in a word, civilization.
>>>>
>>>> I buy your excellent Microham stuff (and recommend it to others)
>>>> because it gives me a jump ahead, and I can take my pleasant, sweet,
>>>> sipping-a-mint-julip time learning all the cute things you guys put in
>>>> it.  To fuzzily extend your documentation thinking, the only worthy
>>>> proper distribution format of a Microham box would be as a box of
>>>> parts, to insure that the purchaser "suffered" enough to be an
>>>> acceptable recipient of the Microham mojo.
>>>>
>>>> 73, Guy.
>>>>
>>>>
>>>> On Thu, Dec 9, 2010 at 1:04 PM, Joe Subich, W4TV<lists at subich.com>
>>>>  wrote:
>>>>>
>>>>>> 5)  A serious documentation methodology breakthrough certainly IS a
>>>>>> patentable offering.
>>>>>
>>>>> What you are seeking falls in the category of "expert systems."  Too
>>>>> many of the posters here are simply demanding documentation that tells
>>>>> them what to do in every possible situation - no matter how unlikely
>>>>> the situation or whether the operation/usage is even within the design
>>>>> parameters of the K3.
>>>>>
>>>>> In essence, those who are complaining about the documentation are
>>>>> demanding that the learning curve be made flat.  They believe they
>>>>> are *owed* the same operating experience as others have gained
>>>>> through decades/years/months of experience.  This is but one more
>>>>> facet of the "fairness" mantra that has become so prevalent in
>>>>> western societies.
>>>>>
>>>>> I, for one, would be upset at underwriting the overhead of developing
>>>>> and implementing these expert systems when they only serve those who
>>>>> think the world "owes them" and refuse to accept responsibility for
>>>>> their own results.
>>>>>
>>>>> 73,
>>>>>
>>>>>   ... Joe, W4TV
>>>>>
>>>>>
>>>>> On 12/9/2010 12:04 PM, Guy Olinger K2AV wrote:
>>>>>>
>>>>>> I'm right there with you.
>>>>>>
>>>>>> I find the schematics to be of more use for the fine elements of the
>>>>>> HARDWARE aspects of the K3.  But the real meat of the K3 is in the
>>>>>> firmware, which is not going to be published in any way to allow, for
>>>>>> example, to tweak the APF code to suit ourselves.  So for those of us
>>>>>> who have always done our own prying in the hardware and maintained a
>>>>>> degree of independence back in the old world, SMD, high degrees of
>>>>>> functional integration on SMDs, and Software Derived Radio have made
>>>>>> us dependent on the radio manufacturers to a degree with which we are
>>>>>> getting INcreasingly UNcomfortable.
>>>>>>
>>>>>> It's kind of like having a fine topographical/photographic map of
>>>>>> everywhere around Area 51, with of course fences and security at the
>>>>>> boundary, heavy penalties for trespassing, and also of course, having
>>>>>> Area 51 itself blanked out on the map.  It's regretfully, necessarily
>>>>>> a non-negotiable boundary between insatiable public curiosity, and an
>>>>>> armed need for government security.
>>>>>>
>>>>>> And, while I know Eric is trying to shut down this long, long, long,
>>>>>> long multi-paralleled thread for procedural reasons and has been
>>>>>> fairly forgiving of it, I hope Elecraft has noticed some things about
>>>>>> THIS thread that sets it starkly apart from the likes of "true north"
>>>>>> and other famous endless, everybody-weighs-in thread.
>>>>>>
>>>>>> 1) It is NOT being advanced by a NARROW slice of the user base (as in
>>>>>> CW contesters or 2M digital moonbounce operators).
>>>>>>
>>>>>> 2) The usual futzglop of it's-never-good-enough'ers does NOT dominate
>>>>>> the cast of posters.
>>>>>>
>>>>>> 3) ALL aspects of the documentation have been questioned, not focused
>>>>>> on one thing.
>>>>>>
>>>>>> 4) Those with professional documentation training or involvement are
>>>>>> questioning the state of affairs of documentation in general, and
>>>>>> regretfully see the K3 in the same state as documentation in general.
>>>>>>
>>>>>> It seems to be what the Klingon Ruler called the "undiscovered
>>>>>> country" in one of the Star Trek movies.
>>>>>>
>>>>>> Despite all kinds of good faith effort by Elecraft and their
>>>>>> most-excellent volunteer cast, there is clearly an unmet need that
>>>>>> current state of documentation art does not meet.  Sort of like radio
>>>>>> front ends before TenTec, huh?   Oh, yeah...
>>>>>>
>>>>>> 5)  A serious documentation methodology breakthrough certainly IS a
>>>>>> patentable offering.
>>>>>>
>>>>>> 73, and I'll try to pay attention to Eric's end-of-thread.
>>>>>>
>>>>>> Guy.
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 9, 2010 at 11:22 AM, Mel Farrer<farrerfolks at yahoo.com>
>>>>>>  wrote:
>>>>>>>
>>>>>>> FWIW, the user manual is fine.  What you are describing, is a service
>>>>>>> manual.
>>>>>>>
>>>>>>> Mel,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>> From: eric manning<eric.manning at engr.uvic.ca>
>>>>>>> To: Jim Garland<4cx250b at muohio.edu>
>>>>>>> Cc: elecraft at mailman.qth.net; "Eric Swartz - WA6HHQ, Elecraft"
>>>>>>> <eric at elecraft.com>
>>>>>>> Sent: Thu, December 9, 2010 7:42:08 AM
>>>>>>> Subject: [Elecraft] Parting shot
>>>>>>>
>>>>>>>
>>>>>>> Precisely!!!
>>>>>>> I'm trying to diagnose a K2 fault at the moment. I'm largely acting
>>>>>>> as
>>>>>>> a
>>>>>>> robot
>>>>>>> directed
>>>>>>> by Don Wilhelm, thank goodness for Don&        Gary.
>>>>>>>
>>>>>>>  I would be
>>>>>>> even more at sea, out to lunch,  if I were trying to cope with a
>>>>>>> fault
>>>>>>> in
>>>>>>> the
>>>>>>> far more complex K3.
>>>>>>> I've read the K3 manual carefully [fb user manual!] and I still don't
>>>>>>> have a
>>>>>>> clue as to circuit level function, sufficient to infer fault from
>>>>>>> malfunction.
>>>>>>>
>>>>>>> [I did my PhD thesis on electronic fault diagnosis&        co-wrote
>>>>>>> the
>>>>>>> first
>>>>>>> book on the subject . . .]
>>>>>>>
>>>>>>> ERIC
>>>>>>> VA7DZ
>>>>>>> [PhD in EE, F.IEEE, FEIC, P.Eng., etc etc]
>>>>>>>
>>>>>>> ________________________
>>>>>>>
>>>>>>> I'd like to see a K3 service manual, or at least a comprehensive
>>>>>>> circuit
>>>>>>> description. Without some explanation, the downloaded schematics are
>>>>>>> pretty
>>>>>>> worthless to somebody trying to understand the radio. In particular,
>>>>>>> the
>>>>>>> published K3 block diagram is an exercise in obscurity. In my
>>>>>>> opinion,
>>>>>>> it's
>>>>>>> nearly impossible for someone even to follow the receive or transmit
>>>>>>> signal
>>>>>>> path.
>>>>>>>
>>>>>>> 73,
>>>>>>>
>>>>>>> Jim W8ZR
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> This message has been scanned for viruses and
>>>>>>> dangerous content by MailScanner, and is
>>>>>>> believed to be clean.
>>>>>>>
>>>>>>> ______________________________________________________________
>>>>>>> Elecraft mailing list
>>>>>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>>>>>>> Help: http://mailman.qth.net/mmfaq.htm
>>>>>>> Post: mailto:Elecraft at mailman.qth.net
>>>>>>>
>>>>>>> This list hosted by: http://www.qsl.net
>>>>>>> Please help support this email list: http://www.qsl.net/donate.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________________________
>>>>>>> Elecraft mailing list
>>>>>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>>>>>>> Help: http://mailman.qth.net/mmfaq.htm
>>>>>>> Post: mailto:Elecraft at mailman.qth.net
>>>>>>>
>>>>>>> This list hosted by: http://www.qsl.net
>>>>>>> Please help support this email list: http://www.qsl.net/donate.html
>>>>>>>
>>>>>> ______________________________________________________________
>>>>>> Elecraft mailing list
>>>>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>>>>>> Help: http://mailman.qth.net/mmfaq.htm
>>>>>> Post: mailto:Elecraft at mailman.qth.net
>>>>>>
>>>>>> This list hosted by: http://www.qsl.net
>>>>>> Please help support this email list: http://www.qsl.net/donate.html
>>>>>>
>>>>>
>>>>
>>>
>>
>