Why bother using the book construct?

Dave,
Sorry to be confusing, I've "Moved up The Ladder" and don't normally do the inputting any more so I guess I'm a little rusty on the file names. Thanks for clearing it up for me.

There are two third party tools (from well-known vendors) available for outlining in unstructured FM:

Sandybrook has Enhance: http://www.sandybrook.com/index.htm

Silicon Prairie has Outline tool:

http://www.siliconprairiesoftware.com/Products.html

Hi, Dave:

Have you tried using conditions to simulate an outline? You can apply a condition to all instances of a given paragraph tag by using Edit > Copy Special > Conditional Text Settings to copy an instance of a condition tag, then use Find/Replace to find, say, all Heading1 paragraphs and replace all with the Replace by Pasting option.

If you apply a "bodyText" condition to all paragraphs in a document, then apply the conditions to the headings, you can hide the body content and selectively show/hide the different headings.

Yes, it's extra work, but it might serve your purpose.

Another approach that may work is to create hyperlinked tables of content from the headings for each file, and/or for the book, tile the TOC and document file(s) and use the FM hyperclick (Ctrl+Alt+Click) on a TOC entry to navigate to the source paragraph.

EDIT: The official FM term for a file within a book is "component" file. In my training classes, I emphasize that an FM book file (or book window) is a list of component file names that it manages; the component file names in a book file (or window) are not the component files themselves.
/EDIT

HTH

Regards,

Peter Gold
KnowHow ProServices

To Dave: If we are going to discuss outliner and structured framemaker, the title of this thread is severely misleading, so perhaps a new thread should be started? However, since structured framemaker is not even in this forum (but in a sister forum), I hesitate to start a new thread here...? Maybe the list mom might move this somewhere?

Anyway, to answer you, here is what I can say:

White space: Yes, too much I think, but I set my Structure View to 80%, and I have customized the font in the ini file to use Arial (which is pretty dense). The balloons are not useless, instead they are very informative of the structure, since they are the names of the elements. You can click on the balloons to show or hide their attributes.

Example: In the document I have open right now (a single-file document), the structure view shows all the 7 topmost elements in the document, with "closed" attributes, and that occupies 47 mm on the screen at 89 ppi. Not too bad I think. Each line has a ballon and the first few words of the content regardless whether the content is a heading, a table of contents, or whatever. Pretty useful, isn't it? Much better than the thing in Word! To see the entire content of that element, just click the element in the structure view, which brings that part of the formated document up in the main view.

Changing the hierarchical view is easy: Click on the +/- sign to see more/less. Shift click it to open close all at that level. Normally, you do NOT have everything open; rather, you focus on the structural level you like.

However, expandability/collapsibility could have been made better by Adobe, but you can use a plug-in from West Street Software 'WS Structure Tools plugin' to radically improve the easy and flexibility with which to expand/collapse.

I tried using structured FrameMaker as an outliner, and it failed miserably. It was a while ago, but here's what I remember of it:

The element view has so much white space and/or was taken up by useless balloon graphics that you can only see a very few headings at a time. I want to see 60 lines (60 headings) at once - not 6.

The element view always looks the same - hierarchies within hierarchies within hierarchies in which the actual heading text is difficult or impossible to see or pick out.

The expandability/collapsibility of the headings was severely limited. As I recall you can't even hide normal document text and show just the headings.

Please correct me if I'm wrong - and I really mean that. I'd love to find out that my perceived limitations were only down to "user error".

Don, just to clarify things, I think the way you are using the terms Chapter, Book, and Document is at odds with the way these terms are used in the FM manual. For example, referring to the files in a book as "books" or "book files" is confusing. In the context of FrameMaker, here's how I use these terms:

A manual (which you can hold in your hand) is a book.
A FrameMaker book file is a file with a .book filename extension, and it represents one entire book (one entire manual).

A FrameMaker book file contains a list of the FrameMaker document files that make up the book. A FrameMaker document file has a .fm filename extension, and it can be a single chapter, an appendix, or a generated file such as a table of contents. You can use the same document file (chapter file) in more than one book if you want.

Just a small note to Dave, Philip, and perhaps others:

I have written relatively small manuals, 4 to 25 pages, where the book construct is used to its great advantage. These manuals are then translated into several languages. The usefulness of a book structure has nothing to do with size or length, it is more about "complexity". Whenever anything like a cover page, a TOC, a glossary, a CE declaration etc is used, a book is much better than a monolithic file. (And, of course, if it is really large, you MUST use a book, but you already knew that.) FM is often touted as the tool for "long documents"; I think that description is very misleading, since I think it has nothing to do with length, but rather complexity and reuse.

I also write single-file documents where that is useful. Things that do not have cover pages, perhaps not even a TOC, often no imported graphics. Things like reports or instructions. FM is just as useful for that -- much more useful than e.g Word. So the recommendation is: use books when that is useful, use single-file documents when that is useful.

As for an outliner: For those of us who use Structured FrameMaker, with structured documents, we DO have an outliner! The structure view IS the outliner! And of course one can restructure an entire book (or chapters, or lists, or...) just by rearranging the elements in the structure view! Very convenient!

To cut to the chase on this....

It's less work to use the software the way it was designed (around the book construct) than it is to fight the software to try to make it conform to some other vision....

If you can't, or don't want to, use the book and container paradigm, you probably should find software that works more like you want to work.

Art

One other reason for the book construct is to allow you to use the same book in multiple documents. In a manual, even when constructed in a custom way for specific customers, some chapters (Books) would travel between the documents unchanged. I have over 1500 manuals and use one chapter(book)in every one of them.

If the manual is small, much of the decision comes down to the structure and features of the word processor you are using. Many of the features in FM (like chapter numbering) are book-based, so it is best to use books to leverage those features. In some cases (like applying styles or searching), the book is merely a tool (or a hack, depending on your point of view) to get around the problems of having a document spread over several files.

I dare say that, at least for small manuals, some of the reasons given previously for using separate files would be reversed if Frame had a proper outliner.

Just for comparison, I used to use Word for DOS to write small (150-page) manuals back in ye olde days (here we go). Word had the concept of Divisions (each of which had its own page size/layout and numbering scheme), so you didn't need to use separate files for different layouts. It had a stylesheet that was integrated with an outliner - you don't know what "megalomaniacal" means until you've restructured an entire book just by rearranging the outline. It had a limited cross-reference facility that couldn't link between different files. To leverage all of these capabilities you needed to keep the manual in one file, and you would have been a complete idiot to do otherwise (I know, because I met a few and had to pick up the pieces). That was in ye olde days, when a typical manual was 150 pages.

Nowadays, in a large project or manual a single chapter is likely to be 150 pages, a typical manual over 1000 pages, and part of the manual is likely to be in temporary residence over on the translator's system getting translated and conditionalised into Russian. With such large file sizes and demands for access a single file just isn't feasible, so you might as well do what FM have done and have book tools and numbering schemes that can handle multiple files as a coherent group. For large manuals there's really no other way.

(But I still want an outliner.)