Two birds, one stone (were: FrameMaker Required b/w Decline of Language)

[Peter Gold <pgold -at- NETCOM -dot- COM>]

Bird #1, FrameMaker Required
Disclaimer: I am a full-time FrameMaker trainer at an independent
(non-Adobe owned) VAR in Silicon Valley.

There are several issues intertwined in this thread.

 - Can employers hire whomever they want, with whatever skill sets they
feel they need? Of course.

 - Is writing ability tied to a particular tool? Probably not.

 - Does "formal" training in a tool beat self-innovated hacking, and if
so, how? Depends on the quality of training and the abilities of the
hacker. "Features training" ("this menu item does this cool thing, and
that one does that..., now press Return or click 'OK'") is not the same as
"process training" ("Your documents must fit into the publishing
requirements of the company you are writing them for. Here's a picture of
the requirements and how they work; here's how documents fit into that
picture. Here's how tool X's features can make that happen. Here's how
feature 1 works, and how you use it to fit into the picture.")

I train people to use FrameMaker. Some of the trainees are writers in
corporate positions, some are looking for work, some are contractors, but
most are *not* writers, but technical employees in corporate positions
whose jobs are being expanded to encompass writing "(documentation", if
you prefer) tasks. "Documentation", of course, has expanded to include
page layout, text formatting, creation of illustrations, code examples,
machine output examples, screen examples, management of review cycles,
maintaining syncronization with "moving target" projects, and more. Most
writing projects they see have no formal templates or style guides; many
are handed-off legacies, or copies of legacies. In other words, these are,
in varying degrees, often projects with no formal established writing or
documentation standards, but with real requirements and real deadlines.

I try to present FrameMaker as a tool for information manufacturing that's
as dependent on standards as the code these trainees write, the circuits
and masks they design, the wafers they fabricate, and the chips, modules,
subsystems, or computers they ship. Their writing tasks should be seen as
just another tributary that flows into the mainstream assembly line of
their finished products.

I'd teach Word, InterLeaf, or even the stone-age counterparts of our
modern tools (hammer, chisel, wood type, pencil, and the 'roff macro
family) the same way, namely, "This is the picture you are rying to
accomplish, this is one task towards that goal, this is the tool for
the task. Next task, next tool, we're another step closer.")

Contrary to one poster's remark, there *are*employers and managers who
hire writers without tool knowledge and expect them to learn tools
without allocating resources for formal training, or even time to
self-teach. "Here's the old stuff; figure it out and get going. If you
need help, don't bother the gurus, it slows them down. We don't have
support either. I think the manuals used to be in the bottom drawer, but
they might not be there anymore. Gotta go." This isn't the majority
situation, but it's not uncommon. Most realitieslie along a continuum from
thisexample on one end, to full-depth training on the other.

When a position requires C++, say, we don't wonder if that's out of line;
we'd likely even accept that someone who didn't know brand X C++ but did
know brand Y C++ could probably have a chance of getting hired, because
the C++ language provides a common basis, a standard of expectation.

What's the difference, then when a writing tool is named as a hiring
requirement? HTML, the World Wide Web markup language, is helping to
change this situation a bit; it represents a similar sense of standard
that a particular programming language does. "HTML skill required" implies
the writer must understand that documents need to be encoded properly to
appear a certain way in a web browsing tool. In other words, the
information must be processed in a standard way for a standard result.
Whatever tool the writer uses to achieve the required HTML result, whether
it's a familiar or new one, the skill of processing and encoding to a set
of standards is what's required for the job.

Until strong information structuring standards, such as HTML and SGML,
(I'm not advocating any specific one) become the norm for writing and
publication, hiring preferences for these positions are likely to be
defined in terms of one's skills with the tools currently in use at the
hiring employer.

Bird #2, the decline of language
"If anyone thinks genderish pronouns are a writing challenge, they
can...etc." could be easily restated as "Those who think (assumes
people who write think about what and how they write) genderish pronouns
are a writing challenge can...etc."

Peter Gold pgold -at- netcom -dot- com

. .. ... .... ..... ...... ...... ....... ....... ......... ..........
  "A short .sig is like a banana without a monkey."
  No! Try, "A short .sig is like a monkey without a banality."
  Wait! Make that "A short monkey in a bandana is something like a .sig
  that, um, uhhh, hmm...,  ...is in your pocket? ...happy to see you? 'Bye!"
. .. ... .... ..... ...... ...... ....... ....... ......... ..........