[Elecraft] Parting shot

Guy Olinger K2AV olinger at bellsouth.net
Fri Dec 10 00:34:51 EST 2010


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


More information about the Elecraft mailing list