Re: Word vs. FrameMaker

["Marcus Carr" <mrc@xxxxxxxxxxxxxx>]

Katav's post is a convenient vehicle for some points that I have been
meaning to make for some time now.

Katav wrote:

>Maybe I'm missing the point -- or perhaps Bill Gates and Adobe are
>missing the point.
>
>Word is an excellent WORD PROCESSOR with some bolt-on features and
>functions that let users kludge together fairly long, semi-formatted
>documents.


Although I agree with your distinction, this is a choice that many
organisations face, so I think it's valid to discuss it here.

>In a business environment, it is an appropriate tool (along with
>WordPerfect, Applixwords, IslandWrite, etc.) for creating text. It is
>more functional (as a word processor) than any page composition tool
>(including FrameMaker), it is less expensive that most 'professional'
>page composition tools, and it is, overall, easier to learn/use than a
>sophisticated page composition tool. Heck, even an engineer can use
>Word (providing a writer sets up a template with speciality toolbars
>:-]).

The problem is, "creating text" may soon no longer be a category worthy of
creating tools for. What we're striving for are tools that support the
creation of information, not just text.

To take one step back, I would be just as happy to create text in a text
editor, but I use Word for some things because it's a more acceptable
interchange format. That's my justification for not using Frame for
everything - it could only be used by someone with Frame (or a filter) at
the other end, whereas almost everyone has Word. In the event that I knew I
could use Frame to create my document and that I didn't have to be concerned
with whether the recipient was able to use the data, I would use Frame, as I
believe it to be a superior tool.

That covers the exchange of words between two people, but what if the data
also needs to be communicated to a database, not just another person? It's
unreasonable to expect the database application to understand n+1 word
processors, just as it's unreasonable to expect Frame to know enough about
SQL to formulate a read or write command to a database. The only solution is
to provide a common target for all applications that produce data and build
middleware to facilitate communication amongst them. Frame achieves this,
but if Word follows the requirements established by IE 5.0, it may not. In
the future, I might find myself asking the same question as I have had to
with Frame. "Will the recipient of this document be satisfied with this
docuent in Word, or should it be XML in case they require more of the data
than a moderately well typeset copy?".

>I can drive a nail with a beeper (and sometimes I think I might just
>to escape the beeper), but a hammer is a better tool. I also can
>create text - and graphics - with most 'professional' page comp apps,
>but a text editor is the /better/ choice.
>
>To me, the word processor vs. page comp war is a waste of effort. (And
>if not, why don't we also engage in a graphics editor vs. page comp
>app battle? Seems to me it is about the same thing, especially given
>the high-end picture makers' formating abilities.)
>
>Right tool for the job, gentle people.


I couldn't agree more, but the issue for me isn't word processor vs. page
comp, it's word processor vs. information creation. The fact that your page
composition application now supports information creation (via SGML and XML)
suggests that you should perhaps be regarding yourself as more than just one
who composes pages - certainly Adobe do, anyway. As a technical
communicator, you surely feel that you are already a creator of information,
but the goal that you're used to (making people understand) is being
supplemented with other potentially more important imperatives. You will
soon have to consider not only how to make information clear to a user, but
also how to make it clear to whatever other applications may wish to make
use of your data.

I have never really thought much of the ambiguous title 'technical writer',
and I think that as the role of such people changes to embrace the onset of
wider responsibilities, it should be recast, perhaps to something like
'information agent'. After all, a travel agent coordinates actions around an
event - perhaps the role of information agent isn't that different.

It really wouldn't be that difficult to start preparing for this, and even
if everything new disappeared tommorow, the changes may make you more
productive in your current paradigm. For example, when next you create a tag
named 'monospace', think about what you're really trying to represent. Is it
a fragment of code or maybe an application command? Then name it as such.
Perhaps no other application for that data will ever arise, or perhaps it
will. People are quick to quote the 'Chicago Manual of Style', but in real
terms, it probably doesn't keep up. For example, if you write for email, you
may break paragraphs according to slightly different criteria than you would
for paper - after all, people need space to put their comments and the text
is somewhat transitory, so the containment of a complete idea is less
important. If you're following on from someone else's quoted text, you might
start a sentence with an elipsis, following more of a conversational mode
than a formal one. These may be wrong from a classicist point of view, but
not from a pragmatic one.

I'm unashamedly biased - if it was up to me, everyone would produce SGML
data and we would dynamically bolt together fragments in response to
specific queries. Even though that can't happen without impossibly
disruptive upheaval of documentation systems, small steps can be taken
toward that goal without introducing anything detrimental to your current
processes.

In the future that I want, except in special cases, the requirement for
printed copy will be directly and inversely proportionate to the interchange
value of the data electronically. You could do worse than to start getting
ready for this...


Marcus Carr


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **