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.
> Well, I certainly *cannot* recommend Quadrite's RitePro.
> Among other issues,
> they refuse to listen to any customer input regarding their
> clunky web-based
> UI, always stating, "It was specifically designed that way!"
>
> We're now looking ourselves (again)...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Can you give some hints as to what fails or what you
find annoying about using the product?
I have two areas of interest... only because I read and
depend upon the documents produced by the other folks,
to do my own work:
1) At some point - early in the project - the Marketing
Requirements Document (MRD) should "freeze" (stop that snickering)
and become generally available in a public place (inside
our company). Any further discussion and changes to the
content should result in a formal revision-bump. This
should be enforced by the system. Reviews of each version
and the approvals should be enforced by the system. You
can't "release" a new version without it being digitally
signed-off by key persons. You can make your proposed
new version available for review and comment, but it
carries a designation that makes clear it's not been
approved.
2) Documents like the SOW (Statement of Work - Engineering's
response to the requirements in the MRD) should also
become controlled in the same way. Even better would be
if changes to (say) the MRD were to trickle down to
the SOW - or at least, to a proposed new version of the
SOW. In turn, when the SOW update is approved, that would
trigger a review cycle for docs that depend on the content
of the SOW, like the Test Plan(s), Test Cases, Test Reports,
Manufacturability Report, Work Instructions (to the people
who eventually will _do_ the manufacturing), etc.
So....
a) It should be obvious to all that a new rev of a document
is in the works
b) Viewing/finding docs, and seeing their status should be
easy.
c) If "floating" licenses/seats are involved, they should
age and close with inactivity (so the early bird each
morning can't just tie up a license all day when they
don't really use it much).
d) Reviews should be "pushed". It should not be required
that a person come looking for status of a document. If
they are on the Required Reviewer list, or just on the
Info-only list for a document or a set of documents,
they should receive an e-mail or a text message to alert
them that a document is changed.
e) Deadlines should be settable, and automated nagging
should be available, to prompt reviewers to get their
butts in gear when a revised document must get approved.
f) Currency and supersession should be obvious.
g) Relationships/dependencies between/among documents
should be obvious. A new rev of the SOW for a project
should raise a flag for each dependent/downstream
document, that must be mindfully cleared either by
those documents being updated/reviewed/re-approved,
or an authority taking an action to indicate that
the upstream change has been considered and is determined
to NOT require a change to some subset of downstream
docs.
h) All of this stuff - the actions by people and by
the system (any state changes) should go into an
audit trail or log that is timestamped (NTP?) and
carries the person's digital signature. No anonymous
changes to docs in the system.
i) Other stuff that's not coming to mind just now...
Oh yeah! Automated interconnections among docs should
work - at least - for MS Office docs, but it would be
nice if an open file format like .odt were supported, too.
(yes, yes, dream on)
- Kevin
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
- Use this space to communicate with TECHWR-L readers -
- Contact admin -at- techwr-l -dot- com for more information -
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
