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.