Reasons to Structure

[Maxwell Hoffmann]

Matt,

Another major benefit of structured FrameMaker is "context sensitive
formatting," which I believe was mentioned before by another forum
member. An added detail is that you can reuse "generic" element tags
which will look dramatically different in different contexts.

In unstructured FrameMaker, it is not uncommon to use 3 paragraph tags
for a 3-level nested list: [bulletlist] "contains" [dashlist] which
"contains" [sqbulletlist]. In structured FrameMaker you could use a
generic element [list] and have format rules in the EDD determine that a
"second level" list contained within a list would be tagged with
paragraph [dashlist] while a "third level" list contained within a list
contained within a list would be tagged with paragraph [sqbulletlist].
In the structured editor, if you were to select a 3rd level nested
[list] element and dynamically drag it to the 2nd level, it will
automatically reformat and be tagged with [dashlist] instead of
[sqbulletlist].

The key benefit is that users have fewer tags to deal with. In an actual
customer example, we had a client who was using over 130 paragraph tags
(including paragraph variants like [BulletListLast], [DashListLast],
[WhateveListLast].) In most of these cases, such paragraphs were
identical to normal list paragraphs, but had extra space below paragraph
to ensure that the last item in the list did not "slam" into the next
paragraph. We developed a structured FrameMaker application for this
client with format rules in the EDD which ensured that the last
[ListItem] element contained in a [List] element has extra space below
it. As a result, our client moved from using over 130 PARAGRAPH tags to
about 40 frequently used ELEMENT tags. Our client observed that it
became easier for new staff to master rather complex document template
rules. NOTE: this client had about 5 tech writers working on very high
volume documentation with consistent formatting and structure. Average
FrameMaker books were about 400pp long.

Another benefit from the transition to structure was that the tech
writers produced more consistent document structure. Due to the lack of
random character level format overrides, there was less "touch up" to
formatting in post-translation documents, which reduced billable time on
translation projects. Format proofing time was greatly reduced, which
was magnified by the 11 languages XML extracted from FrameMaker was
translated into.

Structured FrameMaker *does* require a lot of work up front,
establishing the EDD if you have complex formatting, but it is well
worth the effort and you will gain a return on investment fairly
quickly. I hope that this helps.


    >MATT TODD <mtodd at arielcorp.com> wrote:
    >[snip]
    >
    >So tell me...why structure documentation? I don't know enough to
answer
    >that question, and neither do my bosses. What's so great about it?
What
    >capabilities does it offer that demand its use? Right now, I'm just
    >doing what I'm told, but it's always nice to found actions on solid
    >reason.
    >
    >Matt


Maxwell Hoffmann
Manager of Consulting & Training Solutions
ENLASO Corporation
T: 805 494 9571 * F: 805 435 1920
E: mhoffmann at translate.com 
ENLASO Corporation provides quality enterprise language solutions and
exceeds client expectations through continuing research, development,
and implementation of effective localization processes and technologies.

Visit: www.translate.com for more information or to subscribe to our
complimentary localization newsletter.