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.
I have not only seen it, I have been actively encouraging it for many years.
But I think we first have to address the idea of "entire publication". In
the paper world, an "entire publication" was a collection of paper pages
bound together with glue. The publication process was massively physical
manufacturing process with complex logistics, and so the "content" part of
the process was really oriented around achieving a finished state at the
moment that the work went to press.
In online publication, whether that is a true hypertext or a books-on-glass
style PDF, there is no such physical manufacturing process and so no need
for a publication-wide definition or achievement of a finished state. We
still organize our processes around that concept, in many cases, but the
essential economic imperative for it has gone.
It a true topic-based information set (as opposed to a lego-block approach
to assembling larger documents) the topic is the unit of publication. It is
part of a much larger information set, but there is no reason for that
entire information set to ever reach a global finished state at a given
moment. New information is always turning up, and we are always discovering
new information about customers and their tasks that drive changes to
information and information design. An information set should be a living
thing.
In this environment, the topic is the only logical unit of publication and
the only one that can be meaningfully reviewed. However, that topic also
lives in an information set, and a reviewer may well need to see it embedded
in that information set to make sure it is fulfilling its proper role. (For
instance, do we need an example inline here, or is there a link to an
example?) Review should not take place in isolation, but individually in
context.
The model I encourage is to set up a work in progress server which publishes
the current state of the entire doc set internally on a daily basis. When a
topic is finished, you ask the reviewers to view it on the WIP server, so
that they see it in full context.
This requires much more than a change in review policy. It is a review
policy that is the logical outcome of a change in information design.
You have to review content in coherent units. A building-block topic is
usually not a coherent unit. An Every Page is Page One topic is a coherent
unit. Review policy follows information design.
Given that you make the changes in information design, however, review now
becomes much easier and more accurate. Review happens closer to the time
that the developer worked on the feature, and it happens in units and at
times that are less disruptive to their schedule. It is easier to see
problems in a smaller unit, particularly if it follows a well-defined
subject-specific topic type.
Mark
-----Original Message-----
From: techwr-l-bounces+mbaker=analecta -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+mbaker=analecta -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf
Of Erika Yanovich
Sent: Wednesday, April 6, 2016 1:08 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Developments in the review cycle
In the "good old days", tech writers followed the Outline-First
draft-Second-draft-Camera ready model. We would submit an entire publication
for review (perhaps with some minor TBDs inside) and the world was a simpler
place.
What I see nowadays is more dynamic: partial drafts (or bunch of topics)
sent to different reviewers at different times. The stages are blurred and
the follow-up more complicated.
I know some of you don't believe in complete publications anymore, just in
separate topics that get compiled daily (or whenever) into a larger entity,
but publications are still alive and kicking out there.
So my questions are:
1. Do you also see this transformation?
2. If yes, how do you cope with it?
3. Should we manage each chunk separately according to the old model (sounds
a bit crazy) or replace the old model with a new one?
Erika
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and
content development | http://techwhirl.com
Looking for articles on Technical Communications? Head over to our online
magazine at http://techwhirl.com
Looking for the archived Techwr-l email discussions? Search our public
email archives @ http://techwr-l.com/archives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
