Parting shot
Locked
 
|
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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
FWIW, the user manual is fine. What you are describing, is a service manual.
Mel, ________________________________ From: eric manning <[hidden email]> To: Jim Garland <[hidden email]> Cc: [hidden email]; "Eric Swartz - WA6HHQ, Elecraft" <[hidden email]> 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:[hidden email] 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
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 <[hidden email]> wrote: > FWIW, the user manual is fine. What you are describing, is a service manual. > > Mel, > > > > > ________________________________ > From: eric manning <[hidden email]> > To: Jim Garland <[hidden email]> > Cc: [hidden email]; "Eric Swartz - WA6HHQ, Elecraft" > <[hidden email]> > 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:[hidden email] > > 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:[hidden email] > > 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
> 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<[hidden email]> wrote: >> FWIW, the user manual is fine. What you are describing, is a service manual. >> >> Mel, >> >> >> >> >> ________________________________ >> From: eric manning<[hidden email]> >> To: Jim Garland<[hidden email]> >> Cc: [hidden email]; "Eric Swartz - WA6HHQ, Elecraft" >> <[hidden email]> >> 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:[hidden email] >> >> 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:[hidden email] >> >> 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:[hidden email] > > 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
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 <[hidden email]> 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<[hidden email]> wrote: >>> >>> FWIW, the user manual is fine. What you are describing, is a service >>> manual. >>> >>> Mel, >>> >>> >>> >>> >>> ________________________________ >>> From: eric manning<[hidden email]> >>> To: Jim Garland<[hidden email]> >>> Cc: [hidden email]; "Eric Swartz - WA6HHQ, Elecraft" >>> <[hidden email]> >>> 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:[hidden email] >>> >>> 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:[hidden email] >>> >>> 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:[hidden email] >> >> 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
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 <[hidden email]> 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<[hidden email]> 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<[hidden email]> >>>> wrote: >>>>> >>>>> FWIW, the user manual is fine. What you are describing, is a service >>>>> manual. >>>>> >>>>> Mel, >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> From: eric manning<[hidden email]> >>>>> To: Jim Garland<[hidden email]> >>>>> Cc: [hidden email]; "Eric Swartz - WA6HHQ, Elecraft" >>>>> <[hidden email]> >>>>> 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:[hidden email] >>>>> >>>>> 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:[hidden email] >>>>> >>>>> 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:[hidden email] >>>> >>>> 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
Sorry, Joe, but that "entitlement" comment is just garbage. This thread originated with a comment from somebody that the K3 manual does such a poor job of being a manual (even Wayne refers to it as a "reference", not a manual) that it most likely costs Elecraft sales ... and that by definition refers to people who don't have the K3 sitting in front of them. The manual also is organized so poorly (and it is clumsy enough to find stuff in it that you don't often use) that people need to resort to keyword searches through the pdf version to find their answer. That certainly doesn't help dispel the perception out there that the K3 is an overly complex rig to learn. The complaints about the K3 manual aren't coming from people who are too lazy to search a library for the book they need. It's coming from people who are tired of finding the books scattered all over the floor. Dave AB7E > On Thu, Dec 9, 2010 at 11:37 PM, Joe Subich, W4TV<[hidden email]> wrote: >> >> 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. >> Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
The difference of opinion in this thread is mostly about different
perceptions of "the K3 manual". Is it a compact, easy to access, reference? Or, is it a training course? Or, something in between or both? People are different and have different needs in a "manual". While some people may be looking for a different format K3 manual, the current structure is exactly what I want. What's right or wrong about the K3 manual is largely personal preference. Some people want a training manual on radio usability. Others know how radios work and simply need to know the specific K3 details. No matter how long or how heated this thread becomes, there is no single answer as to what "the K3 manual" should be for everyone. Ed - W0YK Dave, AB7E, wrote: > Sorry, Joe, but that "entitlement" comment is just garbage. > This thread originated with a comment from somebody that the > K3 manual does such a poor job of being a manual (even Wayne > refers to it as a "reference", not a manual) that it most > likely costs Elecraft sales ... and that by definition refers > to people who don't have the K3 sitting in front of them. > The manual also is organized so poorly (and it is clumsy > enough to find stuff in it that you don't often use) that > people need to resort to keyword searches through the pdf > version to find their answer. That certainly doesn't help > dispel the perception out there that the K3 is an overly > complex rig to learn. > > The complaints about the K3 manual aren't coming from people > who are too lazy to search a library for the book they need. > It's coming from people who are tired of finding the books > scattered all over the floor. > > Dave AB7E > > > > > On Thu, Dec 9, 2010 at 11:37 PM, Joe Subich, > W4TV<[hidden email]> wrote: > >> > >> 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. > >> > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
In reply to this post by Guy, K2AV
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<[hidden email]> 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<[hidden email]> 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<[hidden email]> >>>>> wrote: >>>>>> >>>>>> FWIW, the user manual is fine. What you are describing, is a service >>>>>> manual. >>>>>> >>>>>> Mel, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> From: eric manning<[hidden email]> >>>>>> To: Jim Garland<[hidden email]> >>>>>> Cc: [hidden email]; "Eric Swartz - WA6HHQ, Elecraft" >>>>>> <[hidden email]> >>>>>> 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:[hidden email] >>>>>> >>>>>> 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:[hidden email] >>>>>> >>>>>> 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:[hidden email] >>>>> >>>>> 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
In reply to this post by David Gilbert
> even Wayne refers to it as a "reference", not a manual I've never used any "owner's manual" as anything other than a "reference." Read it once to learn how to hook up/install a device and get an overview (K3 manual: satisfies that purpose) and from that point on manuals are a reference for specific functions/features. > The manual also is organized so poorly (and it is clumsy enough > to find stuff in it that you don't often use) that people need > to resort to keyword searches through the pdf version to find > their answer. Of necessity, I support a wide variety of other manufacturer's equipment. I have as many of their manuals in PDF format as I can get and I *always* use keyword searches (unless the manual has been scanned) when I need to find the answer to a customer question. 99.9% of the time, I will find the answer *in the manual* even though I am not (and never have been) a user of that model or even "brand" of transceiver. (Yes, it would be much easier to say "that is function of your transceiver, read your owner's manual.) The K3 manual is no more difficult to use, or less complete, than those or other manufacturers. Printed manuals have tables of contents and/or indexes to allow the reader to locate desired information quickly ... the keyword search function is the pdf equivalent of (and more convenient than) an index. 73, ... Joe, W4TV On 12/10/2010 1:54 AM, David Gilbert wrote: > > Sorry, Joe, but that "entitlement" comment is just garbage. This thread > originated with a comment from somebody that the K3 manual does such a > poor job of being a manual (even Wayne refers to it as a "reference", > not a manual) that it most likely costs Elecraft sales ... and that by > definition refers to people who don't have the K3 sitting in front of > them. The manual also is organized so poorly (and it is clumsy enough > to find stuff in it that you don't often use) that people need to resort > to keyword searches through the pdf version to find their answer. That > certainly doesn't help dispel the perception out there that the K3 is an > overly complex rig to learn. > > The complaints about the K3 manual aren't coming from people who are too > lazy to search a library for the book they need. It's coming from > people who are tired of finding the books scattered all over the floor. > > Dave AB7E > > > >> On Thu, Dec 9, 2010 at 11:37 PM, Joe Subich, W4TV<[hidden email]> wrote: >>> >>> 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. >>> > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
In reply to this post by Ed Muns, W0YK
On 12/9/2010 11:34 PM, Ed Muns wrote:
> What's right or wrong about the K3 manual is largely personal > preference. Some people want a training manual on radio usability. Others > know how radios work and simply need to know the specific K3 details. I think most K3 users want to know 1) What functions, adjustments, and settings the radio has 2) where to find controls for those functions, adjustments and settings 3) the nature of specialized adjustments (like AGC) that are available and how those adjustments affect how the radio works in a given application 4) A well organized table listing functions, adjustments, and settings, and where to find them, both in the manual and on the radio IMO, the primary shortcoming of Elecraft documentation is that it is organized by "where the controls are" (the menus), rather than the function itself. This shortcoming could be overcome without a major rewrite, simply by adding a GOOD index. As an experienced K3 user, I'm often answering questions about "how find a control" that should be obvious but isn't. The second most asked question is, "why is the radio doing something I don't expect?", which often happens when the user has unintentionally operated a control that set the rig in a different mode (like TX TEST). For example, NI6T, a VERY experienced operator and retired EE, called me to ask, "how in hell do I get this radio in split mode so I can call a DX station?" Yes, it's easy, but the manual sure doesn't help. The other major shortcoming of the documentation is that it fails to tell you things you need to know about the details of how something works. For example, that if the rig is in VOX mode, breathing into the mic will stop DVR playback. This is CRITICAL information, yet you don't learn it until you buy a DVR, plug it into the radio, and try to use it during a contest, at which time you find it is useless if you want to use VOX. 73, Jim K9YC ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
In reply to this post by Joe Subich, W4TV-4
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 <[hidden email]> 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<[hidden email]> >> 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<[hidden email]> >>>> 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<[hidden email]> >>>>>> wrote: >>>>>>> >>>>>>> FWIW, the user manual is fine. What you are describing, is a service >>>>>>> manual. >>>>>>> >>>>>>> Mel, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> From: eric manning<[hidden email]> >>>>>>> To: Jim Garland<[hidden email]> >>>>>>> Cc: [hidden email]; "Eric Swartz - WA6HHQ, Elecraft" >>>>>>> <[hidden email]> >>>>>>> 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:[hidden email] >>>>>>> >>>>>>> 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:[hidden email] >>>>>>> >>>>>>> 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:[hidden email] >>>>>> >>>>>> 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
In reply to this post by Eric Manning
Good point. In fact, in my early work history as a tech writer for Hughes Aircraft, we had a minimum of three people involved in editing or reviewing text. I would write it, some one would review and edit. I would review that and correct anything I thought was needed. It went to a third reviewer and back to me and then the two others would again review and so it would go. Why it would take 3-weeks to write a page. I was an engineering writer, so I was in charge of content (technical accuracy). But one of the best experiences was a week long seminar put on by our Phd english expert on how to write documentation. It followed me thru the rest of my career, where the ability to write for comprehension mattered more than most engineers would admit. Yes, I did technical work, but often I was asked to explain (quarterly reviews) or write procedures for the un-technical personnel. An example I often love to tell is when I was a college student taking FORTRAN programing class (1965). The instructor was a complete disorganized idiot. That is not how you teach programming (a logical subject). Fortunately, the text book was great. I put together a 30-page outline of the course for teaching myself. Once that was known in the class I had several request for copies. I like to think I helped get several thru that class. A case of the recently learned teaching better than the "staff". BTW the "prof" started class by taking his old battered briefcase and dumping the contents onto his desk, sorting thru a heap papers for his class notes...ugh. But the perspective of the non-expert who has recently learned a topic having better delivery of instruction than the "expert" is good one to realize. Same approach of doing user evaluations. Some times targeted documentation is better than "does all" type. A user manual; A reference manual.; An installation manual; and a service manual. But that takes human resources to generate. BTW I had a Navy tech once tell me that all they used from our tech manuals were the diagrams! ;-) I think the K3 handbook is technically pretty good, but maybe could use some rearranging. Topics are segmented throughout the document. A good index is vital to any good manual. K3 index is pretty good, but wish I didn't have to use it so much. ---snipped 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. 73, Ed - KL7UW, WD2XSH/45 ====================================== BP40IQ 500 KHz - 10-GHz www.kl7uw.com EME: 144-1.2kw, 432-100w, 1296-testing*, 3400-winter? DUBUS Magazine USA Rep [hidden email] ====================================== *temp not in service ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
|
|
Suggestion......RE-write a chapter of the manual and send to Wayne. He
might want you to do the rest. Just an idea because of your back ground. Phil Philip LaMarche LaMarche Enterprises, Inc [hidden email] www.LaMarcheEnterprises.com 727-944-3226 727-937-8834 Fax 727-510-5038 Cell www.w9dvm.com K3 #1605 CCA 98-00827 CRA 1701 W9DVM -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Edward R. Cole Sent: Friday, December 10, 2010 2:24 PM To: [hidden email] Subject: Re: [Elecraft] Parting shot Good point. In fact, in my early work history as a tech writer for Hughes Aircraft, we had a minimum of three people involved in editing or reviewing text. I would write it, some one would review and edit. I would review that and correct anything I thought was needed. It went to a third reviewer and back to me and then the two others would again review and so it would go. Why it would take 3-weeks to write a page. I was an engineering writer, so I was in charge of content (technical accuracy). But one of the best experiences was a week long seminar put on by our Phd english expert on how to write documentation. It followed me thru the rest of my career, where the ability to write for comprehension mattered more than most engineers would admit. Yes, I did technical work, but often I was asked to explain (quarterly reviews) or write procedures for the un-technical personnel. An example I often love to tell is when I was a college student taking FORTRAN programing class (1965). The instructor was a complete disorganized idiot. That is not how you teach programming (a logical subject). Fortunately, the text book was great. I put together a 30-page outline of the course for teaching myself. Once that was known in the class I had several request for copies. I like to think I helped get several thru that class. A case of the recently learned teaching better than the "staff". BTW the "prof" started class by taking his old battered briefcase and dumping the contents onto his desk, sorting thru a heap papers for his class notes...ugh. But the perspective of the non-expert who has recently learned a topic having better delivery of instruction than the "expert" is good one to realize. Same approach of doing user evaluations. Some times targeted documentation is better than "does all" type. A user manual; A reference manual.; An installation manual; and a service manual. But that takes human resources to generate. BTW I had a Navy tech once tell me that all they used from our tech manuals were the diagrams! ;-) I think the K3 handbook is technically pretty good, but maybe could use some rearranging. Topics are segmented throughout the document. A good index is vital to any good manual. K3 index is pretty good, but wish I didn't have to use it so much. ---snipped 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. 73, Ed - KL7UW, WD2XSH/45 ====================================== BP40IQ 500 KHz - 10-GHz www.kl7uw.com EME: 144-1.2kw, 432-100w, 1296-testing*, 3400-winter? DUBUS Magazine USA Rep [hidden email] ====================================== *temp not in service ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
Re: Parting shot [Thread closed]
|
Administrator
|
This thread and related ones were closed earlier -yesterday- to prevent list
overload. there are way too many posts on the topic. Please let it take a rest. If it continues we'll have to turn on the list 'moderate' mode, something we rarely do. 73, Eric WA6HHQ Elecraft list moderator === On 12/10/2010 11:37 AM, Phil LaMarche wrote: > Suggestion......RE-write a chapter of the manual and send to Wayne. He > might want you to do the rest. Just an idea because of your back ground. > > Phil > > Philip LaMarche > > LaMarche Enterprises, Inc > [hidden email] > www.LaMarcheEnterprises.com > > 727-944-3226 > 727-937-8834 Fax > 727-510-5038 Cell > > www.w9dvm.com > > K3 #1605 > > CCA 98-00827 > CRA 1701 > W9DVM > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Edward R. Cole > Sent: Friday, December 10, 2010 2:24 PM > To: [hidden email] > Subject: Re: [Elecraft] Parting shot > > > Good point. In fact, in my early work history as a tech writer for Hughes > Aircraft, we had a minimum of three people involved in editing or reviewing > text. I would write it, some one would review and edit. I would review > that and correct anything I thought was needed. It went to a third reviewer > and back to me and then the two others would again review and so it would > go. Why it would take 3-weeks to write a page. > > I was an engineering writer, so I was in charge of content (technical > accuracy). But one of the best experiences was a week long seminar put on > by our Phd english expert on how to write documentation. It followed me > thru the rest of my career, where the ability to write for comprehension > mattered more than most engineers would admit. > > Yes, I did technical work, but often I was asked to explain (quarterly > reviews) or write procedures for the un-technical personnel. An example I > often love to tell is when I was a college student taking FORTRAN programing > class (1965). The instructor was a complete disorganized idiot. That is > not how you teach programming (a logical subject). Fortunately, the text > book was great. I put together a 30-page outline of the course for teaching > myself. Once that was known in the class I had several request for copies. > I like to think I helped get several thru that class. A case of the > recently learned teaching better than the "staff". BTW the "prof" > started class by taking his old battered briefcase and dumping the contents > onto his desk, sorting thru a heap papers for his class notes...ugh. But > the perspective of the non-expert who has recently learned a topic having > better delivery of instruction than the "expert" is good one to realize. > Same approach of doing user evaluations. > > Some times targeted documentation is better than "does all" type. A user > manual; A reference manual.; An installation manual; and a service manual. > But that takes human resources to generate. BTW I had a Navy tech once tell > me that all they used from our tech manuals were the diagrams! ;-) > > I think the K3 handbook is technically pretty good, but maybe could use some > rearranging. Topics are segmented throughout the document. A good index is > vital to any good manual. K3 index is pretty good, but wish I didn't have > to use it so much. > > ---snipped > 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. > > > > 73, Ed - KL7UW, WD2XSH/45 > ====================================== > BP40IQ 500 KHz - 10-GHz www.kl7uw.com > EME: 144-1.2kw, 432-100w, 1296-testing*, 3400-winter? > DUBUS Magazine USA Rep [hidden email] > ====================================== > *temp not in service > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > 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:[hidden email] > > 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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html |
«
Return to [K3]
|
1 view|%1 views
| Free forum by Nabble | Edit this page |