Volumizing: Good for Hair, Bad for Content

Hans Fenstermacher, ArchiText Inc.

Life in the 21st Century centers around information. In practically every waking moment, we create it, we receive it, we process it, we pass it on, we ignore it, but most of all, we need it. Those who process information for a living have developed a relentless informational imperative: If it can be written, it must be written. So, content developers fall into volumizing their content instead of preparing if for the global workflow and end users. In this article, Ill examine why content volumization occurs, what its effects are, and what you can do about it.

Where 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 Format.” [1]

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." [2] 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 it, however).

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. [3] 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.

 

Person	Comments	Instances	Time	Cost
Programmer ($60/hr)	5 min. rewriting field label	1	0.083 hours	$5
Writer ($40/hr)	15 min. research 30 min. writing/editing 15 min. to locate in multiple locations	8	8 hours	$320
Editor ($40/hr)	15 min. of disgust 30 min. writing/editing 15 min. to locate in multiple locations	8	8 hours	$320
Subtotal			16.083 hours	$645
Localizer ($40/hr)	15 min. research 30 min. writing/editing 15 min. to locate in multiple locations	8	120 hours	$320 x 15 languages = $4,800
Total			136.083 hours	$5,445

 

Now 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 effort.  

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… Wow?!  

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. [4] 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 gains.

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 content now.  


 

Hans 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 hansf@architext-usa.com.
 

(Editor's Note: This article was originally published in ClientSide News magazine.)


[1] All quoted content in this article comes from real, published documentation. The identifying characteristics have been changed to protect the perpetrators.
[2] "This letter is longer only because I did not have the leisure to make it shorter."
[3] The table represents actual calculations made by Ben Martin at JD Edwards prior to implementing a radical enterprise-wide global content development process.

[4] Visit http://www.useit.com/papers/webwriting/writing.html for a fascinating study on this topic.