Re: Summary -- Application Notes

Subject: Re: Summary -- Application Notes
From: Rowena Hart <rhart -at- INTRINSYC -dot- COM>
Date: Thu, 30 Apr 1998 10:19:56 -0700

For the list,

Here's summary of answers I received regarding my questions about
application notes:

Q. How technical should the application note be? ie. should I include
code samples, flow charts, architecture diagrams, etc.

A 1. Only as technical as needed by the audience to understand the
concept. To view some application notes on my company's web site, look at:

A 3. Detailed enough so that a user can actually do what you are talking

Q. How do I make an application note different from a white paper, esp.
if the white paper also identifies applications for the product? I guess
the question is actually, how is an application note different from a
white paper?

A 1. White papers talk about the product or technology in general
(see the white paper on our site), while App Notes are specific
applications of the product. The product could have many application
notes to help the customer envision uses for the product.

A 2. App notes are different from white papers in that an app note actually
tells an engineer how to make the best use of the product in his design.
You'll find this especially true in the semiconductor world, so find and
read a semiconductor device data book from someone like Intel, AMD,
Motorola or Texas Instruments. These folks are the major players who
set the standards a long time ago. Better yet, go to Intel's developer
site. Start at and click on Developer to get to

A white paper explains how the basic technology works but doesn't always
address the real-world issues that design engineers will face in product
incorporation into the design.

By their very nature, app notes are VERY technical, VERY detailed!!!
Flow charts, code samples and a lot more are all included in app

Q. Should an application note be part of a product package, or should
it be designed to stand alone?

A 1. It should be able to stand alone, but can be included in a
product package.

A 3. Standalone with legals and identity.

Q. At what point does the user receive an application note? After the
brochure? After the white paper? After they buy the product?

A 1. App Notes are perfect for handing out at trade shows, etc. to
make potential clients interested in what the product can do for them. I
tend to think of white papers as the background that gives the App Note

A 3. Use them post-sale to build user expertise.

Q. Is it okay if the application note has a distinct sales spin?

A 1. Yes, though my caution is to ensure the App Note doesn't sound
like all business problems will be solved by purchasing product X. Keep
it focused.

A 3. Unneeded. The user already has the product. And, by making that user an
expert, you are creating loyalty which will sell the next few upgrades.

Q. How "desktopped" should it be?

A 1. Highly. Should be slick and professional-looking. Good enough
for cold-calls.

A 3. You need to create a template, so that each one is consistent. It needs
to have legals and identify, but it can be fairly rough. It should however
fax well, so design a fax cover onto its front page, and pay attention to
graphics. You might want to use black and white without any grays.

Q. If the product has not yet been tested in "real world" situations,
is it acceptable for the application note to be based on our best guess
about real world applications?

A 1. You don't say what your product is, so I can only guess ... the
App Note is about what the product is intended to do. Our company: our
product is intended to run voice over frame relay networks. Technicians
know what that means and respond with "wow", but will the Exec Director
of a large non-profit agency understand the significance? Probably not.
So we explain the exact situation, i.e. "You already have your computers
talking to each other through data lines, so why not run voice over
those same lines and save all the long-distance costs between your
offices. Here's how." Each "here's how" is a separate App Note, because
people can't envision how they could benefit from the technology.

A 3. No. An application is a way to automate a domain, and within that
domain an application should enable or improve performance. Before an
application can be designed, there are task performance requirements.
Go back to the requirements. Contrary to what programmers may think
technology in and of itself cannot be sold. Before you can sell technology,
it must solve a problem. Specific task performance is what people are buying
not features or advantages. Task performance is the solution to the user's
problems. And, it is that task performance that the Application Note

Be aware that there are tasks related to the software that do not
arise from the task domain. These tasks are usually not the kind of tasks
you want to create Application Notes for. You should try to figure out
what the goal related tasks are and document those instead.

Thanks go out to Wendy Putman <wputman -at- castleton -dot- com>, George Mena
<George -dot- Mena -at- esstech -dot- com> and David Locke <dlocke -at- bindview -dot- com> for their

- Rowena

Rowena Hart
Technical Writer
Intrinsyc Software, Inc.

Previous by Author: Re: This page blank...
Next by Author: Re: Summary -- Application Notes
Previous by Thread: Re: Now numbering issue, was Re: This page blank...
Next by Thread: Re: Summary -- Application Notes

What this post helpful? Share it with friends and colleagues:

Sponsored Ads