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.
Architecture
Integration
Performance capabilities and bottlenecks
Protocols
Language bindings
Depth and breadth of API exposure
Not to mention the quality of the SDK (as something over and above the API, I might add). Decision makers consider these things. If the sale of the product depends on its API, then you need to reach the decision makers.
On Fri, Apr 20, 2012 at 4:27 PM, Robert Lauriston <robert -at- lauriston -dot- com> wrote:
> I still don't get why an end user would need to know anything about an
> API other than *what* it can be used for, which is typically a bullet
> list.
>
> Why would anyone other than programmers need a diagram of *how* an API
> works? I don't see the business case for creating such a document.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
