TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
The Best Practices section probably falls under the categories of "useful
to the customer" and "helps make the sale." Now all you need to do is
approach the people who can confirm this, and the Tech Support and Sales
Engineers in our company can confirm for you if this is indeed true. In my
division in my company, technical writing and training are part of the same
group so if I am debating whether or not to write something I can approach
one of the trainers and find out whether the information is useful to the
customers.
To me this is always the best approach to adopt when in doubt.
Have a great day,
Yehoshua Paul,
Community contributor and documentation expert,
www.technicalwriting.com
On Tue, Jun 12, 2012 at 4:48 PM, McLauchlan, Kevin <
Kevin -dot- McLauchlan -at- safenet-inc -dot- com> wrote:
> We have people who are paid to talk to customers. In the technical realm,
> those are Tech Support and Sales Engineers. The company wants to control
> the number of contact points, and to minimize external interruptions for
> non-customer-facing employees (like … oh… developers and writers). ****
>
> ** **
>
> So, my personal response to such questions is to talk to Tech Support and
> to Sales Eng. Still working on that. ****
>
> ** **
>
> It might be that I already have much of the info in the docs, but it’s not
> gathered under one heading.****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* ysp10182 -at- gmail -dot- com [mailto:ysp10182 -at- gmail -dot- com] *On Behalf Of *yehoshua
> paul
> *Sent:* June-11-12 12:21 AM
> *To:* McLauchlan, Kevin
> *Cc:* techwr-l -at- lists -dot- techwr-l -dot- com
> *Subject:* Re: Developer "Best Practices" content****
>
> ** **
>
> To me the answer is obvious: what do your customers say?****
>
> Have you ever gotten any feedback from your customers saying that they
> need such a section, or that a Tips and Tricks page would help? Or do they
> agree with you and think that such information is redundant for expert
> users like them.****
>
> If you can find out what your readers want than that is the answer to your
> question.****
>
> ** **
>
> Disclaimer: This is my generic answer for these types of questions. I
> personally do not document products where you supply SDK toolkits.****
>
> ** **
>
> Have a great day,****
>
> Yehoshua Paul,****
>
> Community contributor and documentation expert****
>
>http://technicalwriting.com/****
>
> ** **
>
> ** **
>
> On Mon, Jun 11, 2012 at 2:24 AM, McLauchlan, Kevin <
> Kevin -dot- McLauchlan -at- safenet-inc -dot- com> wrote:****
>
> This is for list members who document software/hardware/firmware products
> where a customer might be expected to program an app that uses your
> product, or to integrate your product into a third-party application.
> In other words, with your product you supply a developer's toolkit.
>
>
> An inhabitant of a corner office has decided that our documentation lacks
> a page or section that would be Best Practices for programmers using our
> SDK.
>
> From my point of view, the entire SDK docs are what a customer/developer
> might want to know.
>
> Some years ago, that portion of the docs included a Tips and Tricks page
> until I was asked to remove portions that had become outdated. The whole
> thing went away.
>
> I see no need - and I think even corner-office would agree - for material
> that any programmer should already know or can find in an O'Reilly book (do
> they still publish those?), in a C# for Dummies or a Java for Dummies book
> or similar.
>
> Our headers and sample code are as standardized as we can make them, and
> include comments relevant to each major language that we support, so
> there's nothing additional to say about compile options, etc.
>
> What do y'all do on this topic?
>
>
> - k
>
>
> The information contained in this electronic mail transmission
> may be privileged and confidential, and therefore, protected
> from disclosure. If you have received this communication in
> error, please notify us immediately by replying to this
> message and deleting it from your computer without copying
> or disclosing it.
>
>
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Create and publish documentation through multiple channels with
> Doc-To-Help. Choose your authoring formats and get any output you may need.
>
> Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
>
>http://bit.ly/doc-to-help
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as
> yehoshua -dot- p -at- technicalwriting -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives****
>
> ** **
>
> The information contained in this electronic mail transmission
> may be privileged and confidential, and therefore, protected
> from disclosure. If you have received this communication in
> error, please notify us immediately by replying to this
> message and deleting it from your computer without copying
> or disclosing it.
>
>
>
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
