Boston Broadside
November/December 2001
Vol. 59,  No. 2
    Newsletter of the Boston Chapter of the Society for Technical Communication


Copyright © STC Boston 2001

Skill Building

Infoneering: Beauty and the Beast

By Bruce A. Sesnovich

As someone who has been working as a writer in the high-technology field for better than a dozen years now, I have been watching with interest and enthusiasm the slow convergence of the disciplines of writing, interface design, and engineering. In the design of integrated help systems particularly, the traditional boundaries for developing content, interfaces, and features have blurredresulting in a collaborative enterprise that I refer to as infoneering.

This convergence is no longer newsworthy. Driven by the growth of the Internet, the trend has been long afoot and well observed. Don Norman remarked upon it in his 1992 book Turn Signals are the Facial Expressions of Automobiles, which contains a lucid section titled "Writing is Design, Design is Writing."

For years now, I have been working with programmers, quality assurance professionals, graphic designers, and usability experts. As a team, we develop access methods, information types, presentation formats, and whizzy new features, while also taking the occasional moment to grapple with English syntax and determine the most felicitous way to phrase a potentially befuddling error message.

I have been fortunate to be a member of some good teams in which there was a lot of give and take in the design process. We respected but were not cowed by one another's expertise. We felt at liberty to express our amateur opinions, however harebrained, because we felt that they might ultimately lead to something usefulas they often did. Together, we designed and delivered systems in which the help was so well integrated that the user could receive vital contextual information without being explicitly aware of using a help system.

I discovered that teams of people who maintain their creative edge tend to generate many silly ideas. Members of such teams are not afraid to be wrong. While they are confident in their own abilities, they are never unduly certain in their opinions. They keep their minds open and ensure that every member's voice is heard.

For instance, even though I was recognized as the "wordsmith" of the design team, I never assumed that my first attempt at phrasing a bit of interface text would be superior to what someone else might devise. The team frequently hashed out wordings together. Many of the people I worked with were extraordinarily clearheaded and plainspoken women and men who had excellent knowledge of the product. Where my writer tendencies would occasionally lead me down tortuous primrose-lined paths into valleys of verbosity (see what I mean?), other members of the team would cut to the chase with refreshingly simple and precise language.

Conversely, because of my longstanding interest in human-computer interaction, I often had excellent insights about ways to improve the usability of a product. These insights would not be ignored by others simply because I lacked the requisite specialized degree or because someone else was the recognized "expert" in these matters.

Unfortunately, the exceptional congeniality of those teams made me slow to perceive the potential dangers of working in a space with widely overlapping charters. It is all too easy for those who enter collaborations with egos rampant to wind up in internecine turf wars, drawing lines in the sand around what constitutes an "implementation issue," a "content issue," or a "usability issue."

Drawing such lines as a means of delineating charters is not a desirable outcome. While it may avoid some unpleasant battles, it only does so by "pulling rank" and precluding the kind of productive give and take that is the hallmark of successful teams.

Further, the attempt to enforce charters ignores the basic reality that infoneering is by its nature transdisciplinary. Not only is the medium the same as the message, but both are synonymous with the product. It does not matter how good the writing is if the help cannot be accessed or if the words scroll off the page where no one sees them. It does not matter how ingenious or elegant the code is if no one can figure out what the product does. And it does not matter how clean the interface is if it cannot help people do useful things.

As a writer, I find the beauty of infoneering is that I get to participate in product design, think about the usability and accessibility of tools and information, and integrate my words with the product in a way that enhances the entire package.

The beast of infoneering, beyond the difficulty of distinguishing where responsibilities begin and end, lies in adapting to new tools and processes. Our documentation team now checks our help files into the same workspace that the engineers use for their source code. This means that we writers must deal with the joys of source management utilities and face the same release engineering restrictions and code freeze deadlines as do the programmers. Writers who find themselves doing infoneering for a living also have a harder job keeping up with the latest technologies in multiple fields. It is no longer only the feature sets of desktop publishing or help authoring tools that affect us. We need to be aware of the possibilities that are afforded by JavaScript, XML, databases, and scalable vector graphics.

We also need to be mindful of the constraints that are imposed by new technology. For instance, our help text could one day be downloaded and displayed on somebody's Web-enabled palmtop.

Though the U.S. economy may have hit a recent bump in the road, the Internet is not disappearing. Look for increasing convergence in the development and design of Web-enabled products and a concomitant need for writers with multidisciplinary focus. Infoneering has been around for years as a concept, but as a practice it is only now springing out of the starter's box. Hang on, because this horse race should be a challenging, exciting, and profitable one, especially for technical writers with the right skills and preparation.

Bruce A. Sesnovich is a Senior STC Member. He works for Sun Microsystems in Burlington, MA, where he is affectionately titled a "Long-In-The-Tooth-Technical Writer." You can reach him at .