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.
Subject:RE: end user vs end-user From:Kim Roper <kim -dot- roper -at- pixelink -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 24 Oct 2003 13:15:06 -0400
Eric Dunn wrote:
> Seems to me you're just documenting input and output. So just
> leave it at that.
> Where the data comes from and where the output goes is the
> programmer's problem.
There is an erroneous default assumption here. Our product is not just
software being sold to developers to create rebranded applications. Rather,
we design hardware products and the APIs to create custom applications to
control them. Some of our customers are developers, some are end users,
many are both. They're all users of our products, but some things are
relevant only to the developers among them. Those developers could be
designing for other users, other developers, or just themselves.
The assertion that "Where the data comes from and where the output goes is
the programmer's problem" is simply not true. When we create an API, we
have to accommodate the needs of both the developer and the end user. One
of the selling features of the API is that it allows a developer to create
custom applications quickly. He isn't necessarily creating a third-party
product where a quick time-to-market would be nice. Often, our products are
attached to or designed into an already functioning system, and the time
needed to integrate the products is effectively downtime. So, the
implementation time is an critical factor--if a developer needs to get the
end users at his site up and running as quickly as possible, we need to know
what his output requirements are so we can minimize downtime.
This is a case of "know your audience." The developer's data problem *is*
our problem, by the nature of the industry. If we don't create API
functions with this in mind, he could have a huge or impossible task ahead
of him, and that's not good for our business. We have competitors, and the
developer has the option of buying another product.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
