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.
RE: datasheet vs. product bulletin vs. app note vs. tech note vs. case study ?
Subject:RE: datasheet vs. product bulletin vs. app note vs. tech note vs. case study ? From:"margaret Cekis" <margaret -dot- cekis -at- comcast -dot- net> To:"'Monique Semp'" <monique -dot- semp -at- earthlink -dot- net>, "'TechWR-L'" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 28 Mar 2016 15:43:34 -0400
Monique Semp discussed the contents of datasheets and related documents for software products:
"I tried to differentiate these docsâ content (see below), but am hard-pressed to see a big difference between, for example, an Application Note and regular user guide, or between a Product Bulletin and a Technical Note. So comments are eagerly awaited!
A. Datasheet:
* â1-pagerâ (but expected to be front & back, so two pages).
* Meant for high-level sales prospects; good for trade-show collateral.
* Identifies high-level problem/solution.
* Describes high-level architecture/design, and includes a diagram/illustration.
* Lists primary features/benefits.
* Lists general system requirements.
B. Product Bulletin:
* Any length.
* Less sales-oriented than a datasheet, so omit problem/solution selling.
* More spec-oriented, so bigger lists of applicable industry standards would be appropriate.
* Includes detailed diagrams or detailed charts/graphs.
* Good doc to compare different versions/flavors of the product.
* Good format to inform customers of changes to existing products or procedures.
C. Application Note:
* Could be basically a case study, but different because it might not actually have been done.
* Explores/explains how to address a particular use case or task.
* The âhow-toâ element is key, and a key differentiator between this doc type and a datasheet/product bulletin.
* Might address a specific, well-known issue for which customers are looking for a solution, but might be more of an education thing for customers about a nifty way to use the product.
* Can contain high-level process and implementation steps, so customers get a good idea of what work theyâll have to do.
* Iâd say it would be relatively short (up to 10 or so pages), and so a good deal of info but not a full-blown user guide. But googling shows many application notes that really seem more like regular user manuals to me.
* If the associated user guide covers very generic cases where the customer is expected to interpret how to do things, the Application Noteâs content could almost serve as use-case specific appendix to the user guide.
D. Technical Note:
* This is what I used to call docs that now seem to me to be Application Notes or Product Bulletins. But maybe thereâs some other standard description of this?
* (Technical BriefâIâd always thought that this was synonymous with âTechnical Noteâ, but my googling today shows many hits that say that a technical brief is more of a project plan, identifying who does what on a technical project.)
E. Case Study
* Often presented as a whitepaper.
* A real-world scenario where someone used the product and achieved a good result (less cost, speedier implementation, etc.) when compared to using a different _______________________________________
Monique:
I generally agree with your categories and descriptions above. Most of these document types originated with manufactured products like hardware and chemicals, and then the software industry attempted to adopt them, obviously with uneven results. Data like physical characteristics and temperature and solvent resistance are irrelevant to software operation, and the people who decided they needed comparable documents to sell their software probably had only vague ideas about what data should be substituted, and the engineers and marketers were pulling in different directions.. Thus the confusion you describe.
Margaret Cekis, Johns Creek GA
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
