Why bother using the book construct?

[_Philip_Bitar_]

Let's say that I have a book with 50 sections. I can put each section into a separate document file and collect all such document files into a single book. Or else I can put all sections into a single document file.



Assuming that my computer hardware can readily handle the book in a single file, the only advantage that I can see for multiple files is to treat different sections differently. If I wish to treat all sections identically, using multiple files is a huge inconvenience because the tag settings aren't global, across all files and because I don't have immediate access to the entire book for arbitrary operations.



Is there some advantage to using multiple document files that I'm unaware of?

[Art Campbell]

In BookSpeak, a section would mean a section, which normally includes several other files or sections. But I think that you're calling a "section" and meaning a chapter.

If that's the case, the advantages would be:
* Multiple writers can be working simultaneously in different files.
* Chapters can be limited to include specific topics.
* Smaller files are more portable, easier to work on, less draining of computer resources, and easier to manage.
* Discrete files give you the ability to present different material in different ways. For instance, some files/chapters/sections may be 11x17 size drawings, but most of the others can be 8.5x11.

And, why in the world would you have different tag settings in different files, or why would you think they'd differ from file to file, or change if you didn't have access to them? The idea of using a book is to enforce a single set of styles, not to allow weirdness. The book format allows you to enforce a single set of styles effectively in all component files.

Cheers,
Art

[Harald E Brandt]

Also numbering is an important issue with books. Often, the first pages of the book (a manual for instance) is numbered i, ii, iii, iv, etc. In the chapters of the book, it is often desirable to number figures and tables chapter-wise, so that it is easy for the reader to see which chapter a referenced figure belongs to, such as Figure 2-4. This latter behavior CAN be accomplished without building the publication as a book, but it is much easier and more convenient if chapters/frontmatter/appendix are different files. Lastly, the table of contents is easier to manage if it is a separate file.

[R__VanDyke]

A chapter or appendix file can be used in multiple documents.

My most common example is a Glossary of product terms that gets reused in multiple documents. It's much easier to both maintain and reuse that content when it's contained in a discrete chapter file rather than imprisoned within one or more monolithic documents...

Cheers,
RBV

[frmage]

True, tags are not global within a book. But if you keep a separate template document with your tag definitions, you can import the definitions to all files in your book in one operation. With a little bit of discipline in the way you work, this will ensure consistent formatting throughout the book.

As Art said, multiple smaller files are easier to manage.
That's a polite way of saying that your losses will be smaller when (not if) Framemaker crashes...

[Tigdave]

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.)

[_don_bruce_]

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.

[Art Campbell]

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

[Harald E Brandt]

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!

[Tigdave]

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.

[Tigdave]

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".

[Harald E Brandt]

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.

[peter minneapolis]

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

[Guest]

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

[_don_bruce_]

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.