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.
In response to Bill's suggestion about listing issues/reasons for markup
languages and related data management:
--get rid of the maintenance of redundant information (all too prevalent in the
three flavors of our product)
--provide a knowledge database for employees (fewer internal calls to find
answers)
--provide a knowledge database for customers (hoping that an easier time finding
information will mean fewer customer support calls)
--faster and more accurate creation of additional documentation (the training
guides are created separately from the user guides right now and repeat a lot of
the information--sometimes not quite correctly)
--a central repository for documentation. (right now several different groups
maintain the different documents in various file formats and on various
platforms, also provides a way to perform complete backups of the information)
--the central repository should make it easier and faster for us to recreate the
documentation from a release of software
Some of our internal considerations/issues:
--several telecommuters, core development is in Wisconsin, technical support and
manufacturing are in California, marketing and customer support are scattered
throughout the US. In addition, the core users are on PCs and Unix workstations
so we are trying to find a solution with a good, manageable web interface. A
common tool that users can access from anywhere.
--foreign languages. The solution must accept European and Asian languages and
"match" the translated pieces to their English counterparts so that we can
provide a knowledge database that has several languages.
--the solution will not only contain user documentation, but within the year
must contain the system specifications, quality assurance test plans, regulatory
procedures, field service information, and some various marketing literature
--the ability the "scale" the editing/reviewing user interface so that casual
users don't have to re-learn the interface each time they use it.
Sigrid Schoepel
HALL Bill wrote:
> A suggestion to the list members: it would be a good project for the whole
> group to think of the kinds of issues in our present businesses that could
> potentially be addressed by standard markup languages and the related data
> management technologies. This is almost a necessary defensive exercise given
> that we are in the midst of a technological revolution. If you don't think
> of the process improvements and your competition does, and implements them,
> whose business is likely to succeed?
--
Sigrid Schoepel
ADAC Laboratories, Geometrics
6400 Enterprise Lane, Suite 201
Madison, WI 53719
phone: 608-298-2100, x8118
fax: 608-298-2101
email: sschoepe -at- adacgeo -dot- com
I feel much better now that I've given up all hope...again.
