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.
Your clarification was very enlightening. Now my question is, why haven't you approached the kbase moderator to figure out how to make better use of it? It's not your "domain" but if your role is to communicate technical information to end users, then you certainly are a stakeholder. Instead of waiting to be approached, I'd get out there and approach them-SME's, developers, moderators, whoever it takes to figure out better ways to deliver relevant information to people who've got a job to do, and have to use your product to do it.
The kbase, if maintained well, should be a great source of articles and information for the newsletter. Integrate the two! Reference the kbase in the newsletter--and in your help system. Research how to track usage of all three, and evolve them as you find out more about the issues users are having.... then communicate that back to developers and product management for future development. I have both external and internal customers--engineers, management, sales people, field personnel, end users, and finding better ways to integrate communications, requires information flow in many directions.
To tie several of these threads together--TWs are often in a terrific position to faciltate information sharing among many stakeholders. I am not merely a writer of manuals, or a user advocate, or despairing of the "great divide". I am a professional in an organization, and my job is to make sure relevant, useful and accurate knowledge is shared among the people who need it. If someone says "newsletter", I find out why that solution is being advocated and see if there are other alternatives to consider. Same with training, demos, user manuals, reference articles, sales presentations and online help.
Who controls it is important, but not nearly as important as whether it's the right, appropriate or necessary thing to do.
MTC
Connie Giordano
Knowledge Management Supervisor
Time Warner Cable
-----Original Message-----
From: bounce-techwr-l-175203 -at- lists -dot- techwr-l -dot- com on behalf of Lyda Woods
Sent: Fri 5/13/2005 3:11 PM
To: TECHWR-L
Cc:
Subject: Client Newsletter
It's fascinating the different assumptions people have made based upon
what I wrote in my original email. Watching this process unfold has
been a great writing lesson in itself.
I think Kathleen's careful reading got it right...
1. This is not an either/or situation. There is going to be a
newsletter. Users want it. Tech Support wants it. Others want it.
2. There already is a database driven kbase for clients which isn't
receiving much use. The kbase is not my domain. My input is not sought
on the kbase. It has a moderator apparently. Not sure why it is not
being used by clients.
3. A key point for the newsletter (or whatever it is called) is that it
will be an HTML page that can be continually updated, between releases.
Otherwise, I can't continuously update online help between releases. An
entirely server-based help system won't work for us right now.
I appreciate the thoughtful feedback I've received. I hope this helps
clarify things a bit.
