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.
Roger Shuttleworth reports that his company develops <<... a product for
which third parties... may develop plug-ins... This can be problematic...
For example, somebody creates a control that is supposed to snap in to our
product but causes problems, and they blame our product. This involves us in
support calls, calls to developers, etc. for which we really are not
responsible. Does anyone on the list know of resources that we could use to
develop a policy document/agreement to handle this area?>>
There are several ways you should attack this problem. First, compare the
kinds of problems that are being reported with how your documentation
describes the development of these types of applications. With luck, you'll
spot a trend; for example, the documentation may no longer match the
development software (i.e., they changed something before the product
shipped and forgot to tell you), or the software may not work the way it's
supposed to work (i.e., the docs are right, but the product is simply buggy
or deviated from the target). Fix these and many problems will go away.
Second, consider some form of certification. Various companies at various
times have implemented testing labs that confirm whether third-party
software or hardware is "certified" for use with their software or hardware.
Sometimes you can develop a standalone program that tests modules to
destruction; in effect, the software uses known combinations of input and
output data to test whether the modules perform as intended. Microsoft is
one well-known examples; when they made the jump to 32-bit Windows,
manufacturers had to go through specific testing and certification programs
before they could say "Windows-compatible" in ads and on product boxes. All
chip manufacturers develop complex testing software to confirm that their
chips work as designed. This is time-consuming and expensive, but may be an
essential form of quality assurance that saves you time and money in the
long run.
Third, consider training, at least in the form of a tutorial that defines
common problems. If you spend any time analyzing the types of problems
third-party developers are creating, you'll quickly identify recurring
patterns that cause problems, and you can develop solutions. Sometimes these
are simple, such as providing good and bad examples of sample code that
developers can copy. Sometimes it's more complex, such as changing your
product so that the code itself is more robust and can solve or prevent
typical problems created by misuse of API calls. Some problems arise when
people retype a code sample but miss an important switch or setting;
providing cut and paste access to good examples of code can eliminate these
problems.
Fourth, consider implementing some kind of formal quality assurance. That
incorporates aspects of all the things I've already said, but most
importantly, it involves a careful analysis of the kinds of problems that
are arising. If you don't know why those third-party developers are making
mistakes, you can't come up with a strategy to stop those mistakes.
I can't speak to issues of legal responsibility, since I'm not a lawyer and
since your products may span multiple legal jurisdictions. But a good lawyer
should be able to craft a disclaimer or usage license that makes
responsibility for correct functioning of a third-party module the
responsibility of its developer. Combine this with "due diligence" (the
proces I described above for rigorously identifying and preventing problems)
and you should be okay.
One final thought: Take a look at the programming tools from any major
developer (e.g., Microsoft's .NET or any other IDE, such as Sun's Java,
Watcom's compilers and so on) to see how they handle this. Since they're in
much the same position as you are, their efforts should provide a good
starting point for covering the legal issues and figuring out how the pros
try to prevent developers from creating problems.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"With Linux, customers end up being in the operating systems business,
managing software updates and security patches while making sure the
multitude of software packages don't conflict with each other."--Microsoft
spokesperson in a News.com article
"And just how would that be different from Windows?"--Adam Engst, TidBITS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
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.
