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:eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 24 Oct 2003 14:12:40 -0400
Kim Roper <kim -dot- roper -at- pixelink -dot- com> wrote on 10/24/2003 01:15:06 PM:
> 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.
Yes, out of context like that they're all users. In meta-discussions about your
company's products they all need to be addressed. But it still seems to me that
if we're talking about documentation in-context it's wrong get tangled in
definitions of user.
Are ALL of these customers being addressed/targeted in one set of documentation?
If so sounds like poorly designed docs.
Or are the docs split into different tasks/work definitions? The docs aimed at
the end-users need only have 'user', 'you', or just simply be written using
instructions from the user's standpoint. And do the developer docs really need
'end user'? To the developer, that's the user. If an API function can be used to
prompt the end user or address another API function then: "With option 1, the
function prompts the user.", "With option 2, the function passes information
to...". No need for end user.
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.