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.
Re: best practices for internal repository of published docs?
Subject:Re: best practices for internal repository of published docs? From:"Pro TechWriter" <pro -dot- techwriter -at- gmail -dot- com> To:"Sam TechWriter" <samtechwriter -at- yahoo -dot- com> Date:Wed, 11 Jul 2007 13:22:49 -0400
Do you have an intranet available to you? We have published our docs in a
"library" format in WebHelp format to the company intranet. You could also
use Sharepoint or even a department Web site built with FrontPage or
Dreamweaver. This would allow you to add a search capability and an index.
It's worked pretty well for us. If you want details, let me know.
HTH,
--PT
On 7/11/07, Sam TechWriter <samtechwriter -at- yahoo -dot- com> wrote:
>
> I'm looking for best practices for storing published documents so our
> company employees can find them.
>
> Our current practice depends extensively on file shares, with backup
> copies in source control. Many of our releases contain many products; A-Z
> 2.0 could contain ABC, EFG, and XYZ (in this example HIJ and other
> products do not require updates for compatibility with 2.0). The final CDs
> combine software with documentation. If I want to update the XYZ 2.0 User
> Guide for the next CD build, I "drill down" through the 2.0 directory to
> find the XYZ folder, then copy the document there (overwriting any previous
> copy). When the A-Z CD is built (using scripts that point to the XYZ folder
> I put my document in), a copy of the build is placed in a separate
> directory.
>
> The result: Two directories, one containing the most recent "drop" from
> the documentation group and another containing copies of all CD builds. When
> we reach GA (general availability), that build is labeled "GA." Anyone in
> our company can easily locate the released CD contents, which include the
> published documents.
>
> This practice assumes that we'll never update the published documents,
> that every document is strictly related to a particular product, and that
> all documents are intended for the same audience. Recently we've created
> documents that defy these assumptions. Now we need to figure out where to
> put them. Internal folks wouldn't know how to find updated or
> multiple-product docs (such as an A-Z 2.0 doc) or docs intended for a
> limited audience - even worse, they might not even know they are available.
> Now that we've begun updating documents that are already on the CD (which
> cannot be changed), and producing documents that aren't strictly related to
> one product, I'm guessing that the-powers-that-be should roll out a new
> directory structure that doesn't carry these problematic assumptions.
>
> Would you agree?
>
> Remember - this question is limited to the internal repository. See my
> other message about getting the updated docs to the customer.
>
> Thanks in advance!
> "Sam TechWriter"
>
>
>
>
> ____________________________________________________________________________________
> Yahoo! oneSearch: Finally, mobile search
> that gives answers, not web links.
>http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Create HTML or Microsoft Word content and convert to Help file formats or
> printed documentation. Features include support for Windows Vista & 2007
> Microsoft Office, team authoring, plus more.
>http://www.DocToHelp.com/TechwrlList
>
> True single source, conditional content, PDF export, modular help.
> Help & Manual is the most powerful authoring tool for technical
> documentation. Boost your productivity! http://www.helpandmanual.com
>
> ---
> You are currently subscribed to TECHWR-L as pro -dot- techwriter -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
>http://lists.techwr-l.com/mailman/options/techwr-l/pro.techwriter%40gmail.com
>
>
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwr-l.com/ for more resources and info.
>
>
--
PT
pro -dot- techwriter -at- gmail -dot- com
I'm a Technical Technical Writer!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-