[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

RE: Future of FrameMaker: InDesign?



A reply and comment to David Cramer's latest...

David makes some good points about MIF's stability compared to dodgy RTF.
<holy war diatribe>It doesn't surprise me.</holy war diatribe>

I am also not knocking FrameMaker or FrameMaker+SGML. If you need to produce
printed pages in a soundly structured authoring environment, FM is the tool
of choice - but not one I would fight to keep in competition with another
SGML editor. Holy wars are reserved for threats to go back to Word! But in
the Tenix environment, we are tending towards an authoring model where we
want our authors to create logically connected content, and will leave
output formatting to one or two specialists. What our authors need is only a
simple editor that gives them a reasonably formatted view of what the text
will look like when formatted (but absolutely no control over that format),
and an optional GUI that shows them which elements are allowed where. FM
meets all of these requirements quite well, but gives the authors a lot of
things to change we would rather they didn't have.

David's comments about XML's present immaturity re output formatting are
also spot on. But hey, guys XML is still a baby! Yes, much more work is
required to make it friendly to the human reader (to say nothing of the page
designer), but I think the market will ensure that work is done.

On the other hand, as we move into an increasingly screen-based reading
environment, there is a lot of what a lot of what we do in the paper
environment we can afford to dispense with. And in saying this I think it is
worth mentioning that I actually have some significant experience in the
printing trades (a year of print shop in high school - where we set type
character by character and laid out the page by hand). I love the smell of
printers ink and see a well laid out page to be a work of art.  However, if
my own way of working with commercial and professional documentation is any
way representative, I find a simple and uncluttered screen format far far
easier to apprehend than something that is trying to look like paper. It
also displays faster. As a reader, (even with a 21" screen) I find simple
HTML to be far preferable to any .PDF file - I am probably reading the 2nd
or 3rd HTML screen before the .PDF has even finished loading, and then the
majority of .PDF documents I read are two column or formatted in such a
small type font or with such wide margins that they can't be read when sized
to fit the screen, etc., etc.. To read the damn thing I probably have no
choice but to actually print it, which costs still more time and adds to the
pile of paper that already sits on my desk, and is lost the next time I need
to refer to it. From my point of view as a user of documentation, XML really
doesn't need to do any more than HTML already does. If my prognostication of
the future is right, Adobe has a lot more than its market for FM to worry
about - and if developed properly, FM would provide them the platform to
ensure they keep a big piece of the hugely expanding XML market.

Anyway, this will be my last on this subject for a while - tomorrow we are
starting to load our full set of live maintenance routines into SGML,
collapsing 8,000 ship-set "paper paradigm" files into ~2,000 class-set SGML
instances and adding substantial value to the text by doing it. However, we
still face the one-off need to manually manipulate at least 4,000 documents
to achieve this.

Regards,

Bill Hall
Documentation Systems Specialist
Integrated Logistic Support
Naval Projects and Support
Tenix Defence Systems Pty Ltd
Williamstown, Vic. 3016 AUSTRALIA
Email: bill.hall@tenix.com <mailto:bill.hall@tenix.com> 


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