does it all come from?
Technology has long had its own imperative, so products offer an
abundance of choice, which we document equally
abundantly. For example:
"The first step in creating a format from an existing
file or folder is to create a new graphic FRM
file by either clicking the New icon from the
What To Do section of the Getting Started page
and then clicking the Standard.frm icon from the
Default template tab (as shown in the following
image), or clicking New from the File menu, or
clicking the down arrow on the New icon from the
left side of the Standard toolbar and clicking
Products must also do more and more to ostensibly
please a demanding public, so features are continuously
added. Naturally, these features are also documented
in abundance, or - and I trust the reader will
duly note the irony here - how else would anyone
know they're even there?
Virtually no part of our lives in the Information
Age is unscathed by the time squeeze, least of
all content development efforts. Blaise Pascal
once wrote, "Je n'ai fait cette lettre-ci plus
longue que parce que je n'ai pas eu le loisir
de la faire plus courte."  Precisely. We no longer have the "leisure" to make content efficient
and shorter, so we settle for quantity over quality.
Witness the demise of editing at nearly every
level of content development and localization.
Volume manifests itself in obvious and devilishly
sneaky ways. Take that bugbear of technical writing,
the "template." This is one of the more insidious
ways content becomes "volumized." A template by
definition calls for rigid adherence to principles
which are usually created in a vacuum (or at least
a classroom), to wit:
"Minimum System Requirements
Make sure your systems meets the following minimum requirements:"
The template here calls for a "bridging" sentence
between the header and the bulleted list below.
Good order (a.k.a. tradition) is preserved, but
if you smell a rat, you've got a better nose than
most technical writers. All this template does
is make the user read the same thing twice (oh,
and increase the cost to create and localize the
content - more about that later).
Then there are the San Andreas-sized structural
faults that run through most content. They may
take the form of chunky block text, or text that
describes a graphic in every detail, or every
imaginable screenshot included "just in case." The primal urge to document everything seems to
be too hard for many to resist (it is exactly
inversely proportional to the urge to resist reading
Finally, we have the ultimately unforgivable transgression
of bloviation. Why do writers write, "For more
in-depth information about this topic, please
refer to..." when "See..." will do? Must we really
tell users, "To use this product to its fullest
potential, you must think about how its abilities
apply to your particular organization?!" Is there
a system administrator alive who feels informed
by "The interface is the mechanism through which
you view, enter, and interact with the information
stored in the database?" I think not.
What's so bad about volume, anyway?
All this content volumization has horrible consequences in three
main areas, which every organization battles constantly:
time, cost, and usability. These are interrelated,
of course, but even taken individually, they are
shocking in their deleteriousness.
Time is in short supply, yet we waste it at every
turn in content development. Notwithstanding Pascal's
truism, making more content usually takes longer,
particularly from a global (not just multilingual)
viewpoint. Actually authoring a piece of content
is only the beginning. The content must be reviewed
(even if only by the author), laid out, processed
(bookmarks, cross-references, index markers, tags,
etc.), checked in/out, QA'd, finally assembled,
etc. Add it all up and a 5-minute field label
rewrite could become a 16-hour company chore,
as you see from the accompanying Table.  Of course, this applies only to one field label in the first version.
If there are three new releases per year and 1,000
field labels, well, you do the math.
5 min. rewriting field label
15 min. research 30 min. writing/editing 15 min. to locate in multiple locations
15 min. of disgust 30 min. writing/editing 15 min. to locate in multiple locations
15 min. research 30 min. writing/editing 15 min. to locate in multiple locations
$320 x 15 languages = $4,800
consider localization. Volumized content is processed
by localizers (counted, compared, leveraged, etc.),
translated, reviewed, laid out again, processed
again, checked in/out again, QA'd, finally assembled,
etc. These tasks in localization are done per
language, so the time to do them multiplies geometrically.
Looking at the Time column in the Table, you see
that a simple 5-minute addition for this project
actually takes 1,600 times longer than the authoring
Closely related to the time wasted in volumizing
content is cost. All the extra time spent on the
content is, of course, more expensive. Localization
costs are based primarily on volume, so author
bloviation raises content costs dramatically.
The Cost column in the Table shows that a $5 worth
of content costs 129 times as much to implement
fully in the original language, and a whopping
1,089 times as much to implement globally. Er...
Those are just the direct costs; closely related
are costs like printing and deployment. What if
you could reduce a 40-page install guide to a
tri-fold card? (Don't smirk - I've done it.) Imagine
the print savings. Then more distantly related
costs: tech support calls, marketing communications,
knowledge bases, web content. With single-sourcing
and content automation, direct costs may drop
by orders of magnitude, but the content volume
itself is still the driving cost factor.
Last, and (stupidly) perceived as least, is the
effect of volumization on usability. It goes back
to the time squeeze. If users must read content
(God forbid!), they want the information fast
and easy. The higher the volume, the slower and
harder it is to find anything. Jakob Nielsen,
the web usability guru, has performed countless
studies to demonstrate one undeniable fact: content
usability and volume are inversely proportional.
 Moreover, greater volume almost always also means more authoring
sessions and more authoring sources. This multiplication
of inputs raises the chance of human error, inconsistencies,
scattered information, and the like, lowering
usability, the effectiveness of TM even more.
Was tun? (so, what can you do about it?)
No matter what your position in an enterprise - technical writer,
manager, VP product development, or CEO - do not
for one moment assume that content volumization
is inevitable. Most content costing decisions
today are based on the mistaken assumption that
volume is a constant, so why not apply the lowest
cost factor possible? And the jobs march inevitably
offshore. All that does is lower production costs
for now (a defensible result only in the short
term). The content that results from this effort
is at best no better than before, and usually
much worse and longer. Offshoring may reduce content
production costs, but it could actually raise
localization costs and time, offsetting some offshoring
With volumization no longer inevitable in your
mind, take the right steps to solve the problem
you actually have. If you think technology is
the solution to your problem, then you either
don't have a problem (unlikely), or you don't
really know what your problem is. Volume is a
process problem; it is a people problem. Technology
will not solve the problem, any more than buying
a new refrigerator will make your aunt Sally's
lousy fruitcake disappear. Reducing the volume
of content starts with changing authors' conceptions,
habits, drivers, and skills. It is not an event,
but a lifestyle.
Start connecting content development and localization
more closely. Assemble both teams regularly to
discuss problems. Create a feedback loop - in
both directions. Exchange metrics (see below).
Empower teams to solve real problems (maybe even
in the product itself - er... wow again?!), not
point fingers. Cross-train people in single-sourcing,
TM tools, authoring tools, etc. The siloed nature
of content development and localization creates
huge obstacles to efficiency and cost-effectiveness
in your organization.
You can't fix what you can't measure, so measure
everything. Then focus on the metrics for the
right things: word count, page count, graphics
count, screenshots, time on task, staff costs,
touchpoints. These paint the true picture of content.
Then multiply those metrics by your expected multilingual
workflow. A company I know calculated that their
production cost for incorporating a single screenshot
in a single language was $15. Their localization
requirement currently stands at 19 languages.
One manual for one of their products contains
300 screenshots. These metrics are not at all
extraordinary. Again, I leave you to do the math.
How much do screenshots cost in your organization?
If you don't know, you just touched a real problem.
Finally, you must - absolutely must - think globally,
not just multilingually. Connect content development
with your other business processes: tech support,
product development, marketing, human resources,
training, and so on. Where does content originate?
Where does it go? How is it tracked from release
to release? Calculate the life cycle of products,
the number of releases planned, how the product
will change. How does all this affect the metrics,
usability, and workflow for content development?
Like product development, understanding these
links and planning are the key to less, more effective,
content. The worst thing your teams can do is
just start writing.
Metrics are critical to global thinking, but failing
to measure the right things can lead you astray.
Companies usually have exact localization metrics
(because - more irony here - localizers live and
die by metrics), especially TM percentages. Too
often, though, organizations fall into the TM
trap, letting leverageability drive their content
decisions, instead of the other way around. Ignoring
usability (I don't recommend it), the value of
leveraged TM is just a metric like any other.
The decision to rewrite content, reduce volume,
and improve usability, should include - but never
be driven exclusively by - TM percentages. Most
organizations, however, do just that, and it will
prevent them from ever getting out of the content
volumization spiral. As Abraham Maslow said, "If
all you have is a hammer, you tend to see every
problem as a nail." TM is not, and should not
be, your only tool on the content workbench.
As you can see, content volumization is not inevitable,
but it is disastrous and costly. Like male pattern
baldness, it's a problem that most sufferers think
is less obvious than it actually is. If you insist,
get some mousse and try to give your hair that
full look, but, for heaven's sake, start cutting
Fenstermacher is president and
founder of ArchiText, a language service provider.
He has developed ABREVE, a methodology for reducing
volume and globalizing content. Hans is also the
chair of the GALA Board. He can be reached at firstname.lastname@example.org.