From: sstark@Ingres.COM (Scott Stark)
Newsgroups: comp.text.frame
Subject: Framemaker gripes (long article)
Date: 9 Apr 92 22:12:23 GMT
Reply-To: sstark@Ingres.COM (Scott Stark)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501


     The following is an opinionated listing of various problems, gripes
     and inadequacies discovered using Framemaker 3.0 for the Macintosh. 
     As an introductory caveat, the users are a part of a technical
     communications department that is in the process of converting its
     entire doc set of 60+ technical manuals from Ventura Publisher on the
     PC to Framemaker on the Mac.  Comparisons between the two programs are
     inevitable, and the problems encountered with Frame are colored by a
     familiarity with functions that Ventura can perform and Frame should
     be able to perform.  There is no attempt here to list the glowing
     advantages of Frame over Ventura.  The general feeling by myself and
     others in our department is that while Frame offers some distinct
     advantages, it is a younger program and has major weaknesses in many
     areas.

     The bulk of our problems surfaced when we tried to attach tables of
     contents to every chapter, something which is next-to-impossible to do
     in Frame.  Other problems arose as we tried to adapt Frame to our
     desired format, which I think is fairly common and should be fairly
     simple:  our average publication is a technical manual of 10 to 30
     chapters, plus a master TOC and index.  All chapters begin with page 1
     (chapter 3, e.g., begins with page 3-1).  All page numbers, figure
     captions, TOC/index references and other references use the page
     numbering convention of chapter#-page# or chapter#-figure#.  All
     chapters begin on the right-hand page, and the first text also begins
     on the right page, sometimes requiring a blank page after the TOC and
     at the end of the chapter.  Blank pages have footers, but no headers
     (most other pages have headers).

     1.   Book building and TOC/Index generation.  This process is highest
          on my list of gripes.  This is probably the most complicated,
          user-unfriendly process I have encountered in any software,
          requiring eye-blurring visual coordination and enough mouse
          movements to give carpal tunnel syndrome to Gumby.  Specific
          gripes include:

          a.   Adding chapters to a book.  Only one chapter can be added at
               a time, requiring you to pull down "Add File" from the File
               menu, scroll through a list of files to add, and select both
               its name and position in the book, at which point you are
               dumped back to the edit mode.  Some of our manuals have as
               many as 20 or 30 chapters, with a TOC for each one,
               requiring the user to go through this laborious process as
               many as 60 times.  It would be helpful to have a
               "Move/Include/Don't Include" function here similar to
               selecting tags for TOCs.  The only faster way to select a
               group of files for a book is to select All, which presents
               its own set of problems:

          b.   Rearranging files in a book.  Even if you have been smart
               enough beforehand to keep only those files in your working
               folder that will appear in the book, if you select All under
               Add File, the files are dumped into the book in no
               particular order.  Deleting chapters from a book is fairly
               simple, but moving them requires highlighting one chapter
               and clicking as many times as necessary on the Move Up or
               Move Down buttons until it is in the exact position.  With
               50 or 60 files in a book this quickly becomes a nightmare. 
               You can't even hold down the Up and Down buttons to repeat
               the movement -- you must click once for each position
               change.  Ideally, I would like to see a resizable window so
               I could see the whole list at once, and be able to grab and
               drag the files to the correct position.  Repeatable Up and
               Down buttons would also be helpful for those still wishing
               to use them.


          c.   Set up file.  Once you have gotten all of the chapters and
               chapter TOCs into the book in the proper order, you must
               click on Set Up File under the File menu for each and every
               one, adding prefixes, changing the first page to Start on
               Right, and changing Page and Paragraph numbering to restart
               where necessary.  This is another long and nightmarish
               process, especially when working with 2 or 3 types of files
               (TOCs, chapters, appendixes) which require different
               settings -- it's easy to lose track of where you are and put
               in wrong information.  It would be helpful, since many
               chapters require the same settings, to be able to apply the
               same setup features to a number of chapters at once, or to
               be able to set a different default group of settings.  It
               would also be helpful to avoid having to use prefixes at all
               (see below).

          d.   Prefixes.  In an automated world, it seems quite backward to
               have to type in a numbered prefix for each chapter.  Frame
               allows you to define variables within each chapter for the
               chapter number, and this number will change automatically if
               another chapter is added or deleted before it.  Why can't
               Frame pull that variable and use it as a prefix?  If the
               chapter number does change for some reason, you won't then
               have to go into Setup in each file and retype a new prefix.

          [We have found a workaround for much of a-d above:  with the help
          of someone in our department who has some programming background,
          we have developed a simple program that generates MIF files using
          a text editor on the PC side.  With MIF you can specify all of
          the files you want in a book in the correct order, with the
          correct setup options and prefixes for each, and all of the tags
          you want to appear in the TOC.  MIF files are fairly simple and
          easily copied, and Frame reads them beautifully as book files.]

          e.   Table of Contents and Index generation.  Another cumbersome
               process requiring as many as 10 or 15 steps.  Every time you
               create a new TOC, you must select/deselect the same tags to
               include -- Frame won't remember what you selected last time. 
               You must also set up the page numbering, startup side, etc.
               -- there is no way to set the default.  And you shouldn't
               have to generate the TOC twice -- generate once, open
               template, use formats from the template, then generate
               again.  On a large book, generating a TOC can take 20
               minutes or more each time on a fast machine.

               (It would be helpful, incidentally, to be able to specify
               the name of the TOC/index when first generating it, so you
               could direct the output to a file that already exists,
               rather than guessing what it would be.  See note following.)

               There is also no way to select unusual tags to include in a
               TOC unless the chapter containing those tags is active, even
               if that chapter is included in the book.

          [Two workarounds we have discovered here to circumvent Frame's
          clumsiness:  again, specifying the required tags in the MIF file
          lets you avoid having to select them manually; and in the MIF
          file you can also specify the name of the TOC.  If you copy an
          already-existing TOC (and/or Index) and give it that name (or if
          you're not using MIF, give it the name you know Frame will create
          when it generates the TOC (such as "Bookname TOC")), Frame will
          simply dump the new data into that TOC and you won't have to Use
          Formats From or regenerate.]

     2.   Building an individual chapter.  As long as a chapter contains
          only one file, with no TOC, building an individual chapter is
          fairly simple.  But as mentioned above, attaching a TOC to each
          chapter opens up a Pandora's Box of problems, and other problems
          arise if you need to break up a chapter into subfiles.

          a.   Chapter TOCs.  While Frame allows you to generate TOCs from
               within a chapter, it's pretty clear the developers never
               expected anybody to do it.  To get the chapter#-page# to
               appear by each TOC entry, we tried putting a <$paranum>
               variable on the reference page before the <$pagenumber>
               variable, the <$paranum> pulling an invisible automatic
               number we had to create for each tag that the TOC pulled. 
               This actually worked, until we ran the Book TOC, at which
               point Frame turned all of the chapter numbers to zero. 
               After much discussion with Frame tech support, we were told
               to make a separate book for each chapter, including only one
               TOC and chapter file in each, and, again, to type in
               manually prefixes for each (see gripes 1.c through 1.e
               above).  This not only more than doubled the already
               cumbersome book building process and created more files that
               we don't want included in our master book, if the chapter
               numbers should change for any reason, that is one more place
               we'll have to remember to manually change the chapter
               number.

               We also discovered that when this chapter TOC is generated,
               the chapter number variable is initialized.  Chapter 7, for
               example, becomes chapter 1.  The only way to get it back to
               7 is to regenerate the book TOC.  This means every time the
               chapter TOC is rerun, we will also have to rerun the book
               TOC, a process which can take 20 minutes or more.  The only
               workaround for this problem is to give up on Frame variables
               altogether, and type the chapter number in manually; but if
               the chapter number changes somewhere down the line, this
               would require us to manually change the number in the
               chapter number tag, the chapter TOC setup file, the book TOC
               setup file, and probably other places as well (would that
               number be pulled into footers, frame captions, table
               headings, cross references, etc.?) for that chapter and all
               subsequent chapters.

          b.   Chapter titles, numbers, footers.  There is a strong
               disadvantage to Frame's requirement that the TOC be a
               separate file from the text file.  In order for the title
               and number to appear in the footer or header of every page,
               it must pull them from a tag within the chapter.  But the
               chapter title and number appear at the beginning of the
               chapter, which is, you guessed it, on the TOC page.  Since
               this is a separate file, the chapter file footers can't make
               reference to them (except by using cross-references, but you
               can't make reproducible templates with cross-references in
               them -- they'd all reference the same file).  And you don't
               want the title and chapter number to appear again on the
               first text page.

               Our solution was rather complicated -- we created a second
               frame on the first text page in an area above the text
               column, and tagged the chapter number and title paragraphs
               to print in a color we'll have to turn off when printing. 
               This frame will unfortunately cover up any header that runs
               into it, and we had to readjust our first-level heading tags
               so that the first one would stay on the same page (by
               telling the tag to start "top of column" rather than "top of
               page" -- fortunately we only have one column in our
               chapters).  Developing this somewhat clunky system took a
               lot of time and trial and error, and was much more
               complicated than I feel it should have been.

               [Incidentally, Ventura allows you to put the TOC in the same
               chapter as the text, in a separate flow that is
               automatically updated whenever the TOC is regenerated.

          c.   Multi-file chapters.  Frame tech support recommends not
               having chapters that are broken up into separate files. 
               However, large chapters -- 200+ pages -- are very slow to
               work with, and Frame does have memory limitations.  But to
               break up chapters into 2 or more files requires that each
               subchapter have its own chapter title and number frame, as
               described in b above; otherwise the footers will not be able
               to reference this information.  Since the page containing
               this extra frame must be a "first page" master page, it must
               necessarily be a left or right page, which may be incorrect
               depending on the left or right position of the last page of
               the previous chapter.  Also, when you generate the chapter
               and book TOCs, the chapter title and number will be pulled
               from each subchapter, and therefore will be repeated for
               each.

          d.   Blank page no header.  In our publications, blank pages --
               such as an extra left page at the end of a chapter -- have
               the headers turned off.  This is easy enough to do by
               applying a no-header master page; but if the text in the
               chapter expands or contracts, text may eventually appear on
               that page, at which point it should have a header.  It also
               seems possible that if enough text is added at the end of a
               chapter, that no-header page may end up somewhere in the
               middle of the chapter.

     3.   Formatting.  In general, the "Use Formats From" is a burdensome
          extra step, and can create some problems.  [Ventura uses a single
          style sheet which can be used by any number of chapters.  When
          the style sheet is changed, it is changed for all chapters that
          use it automatically.]

          a.   In Frame you have to keep a master template with the proper
               formats and remember to apply it to every chapter.  If you
               make a change to your master style sheet, such as changing a
               typeface or something as simple as changing an indent, you
               would have to apply the new formats to every chapter of
               every book, which in our case would be hundreds of chapters.

               [Ventura allows you to replace the old style sheet with the
               new one, and all chapter would then automatically access
               that new style sheet.]

               If page layouts are changed, this would also require
               manually changing any header/footer text in the master FOR
               EACH BOOK before applying formats, since the footer contains
               information specific to that book (such as the book's
               title).  This would multiply the format application process
               by the number of books involved and more.

               Further, in setting up books, we have found it necessary to
               use as many as 8 different templates:  one for chapters, and
               different ones for appendixes, prefaces, title pages, book
               TOCs, chapter TOCs, indexes, glossaries, etc.  Applying
               separate formats to each type of chapter to 60+ manuals
               elevates this already cumbersome process to nightmarish
               proportions.  And since Frame is new to us, once we start
               working with it on a day-to-day basis, we may need to make
               further changes to the templates, requiring us to repeat the
               process any number of times.

          b.   If you have made any changes to a specific paragraph without
               creating a new tag, applying formats wipes out your changes.

          c.   It's a minor annoyance that you must have the template file
               open to use the formats from it.  It would be nice to be
               able to use the formats from any file on the disk without
               having to open it.

          d.   There is no way to tell which format has been used in a
               file.  You run the risk of later applying the wrong format
               to a file.  [Ventura displays the name of the style sheet
               used in the chapter.]

          e.   There is no way to change the page size in a file, except by
               copying the text into a newly created document of the right
               size; doing this is not only cumbersome, but you lose all
               page formats in the process.  If you then apply the page
               formats from the old document, your new file reverts to the
               old page size.

          f.   There is no way to delete unnecessary tags en masse from
               several chapters at once.  Applying formats to a chapter
               only adds new tags to those already there.

          g.   Page layout and header/footer information should be two
               separate selections on the Use Formats From menu.

     4.   Word Processing.  Frame's word processing capability is a strong
          selling point; however, there are a few problems.

          a.   Spell Checker.  The Spelling Checker is pretty good, but it
               would be useful to have a "skip once" as well as "allow in
               document" button.  Also, it should correct every instance of
               a misspelled word.

          b.   Find/Replace.  When using Find, Frame searches through the
               entire document and then starts again at the top without
               telling you it's done so.  Unless you're watching the page
               numbers below, you might not realize that you've already
               found the string or code you're searching once before.  It
               would be helpful if Frame told you when it had reached the
               end of the document and asked you if you wanted to continue
               from the top, and then shut down when it reached the point
               where you began the Find.  I can't think of any reason why
               you'd want to find the same string twice.

          c.   "No insertion point."  This annoying message appears if you
               choose Find and haven't clicked on the text in the active
               file.  I can't think of any reason why you'd want to search
               for something without first inserting the cursor.  Frame
               should assume you want to search the active window without
               requiring you to click on the text.

          d.   Change & Find.  Going through a document and selectively
               changing found text requires you to move the mouse cursor
               back and forth between the Change & Find buttons and the
               Find button (if you elect not to change).  This makes the
               process tedious.  Most word processors allow you to select Y
               or N from the keyboard.

          e.   Block functions.  Block functions are generally excellent,
               but it would be useful to be able to anchor the cursor,
               search for a character string, and block from your anchored
               position to the found string.  Any word processor can do
               this.

          f.   You cannot select alternate paragraphs.  This would be
               useful when, say, every other paragraph required an
               automatic number.

          g.   Page breaks.  There doesn't seem to be any way to force a
               page break, except to make a blank paragraph with negative
               leading; but the value necessary for this leading will vary
               depending on the size of the type in the following
               paragraph.  If you tell the next paragraph to start "top of
               page" in the paragraph format menu, applying formats to the
               chapter will wipe out that change.  Perhaps a "bottom of
               page" or "page break after" option would be useful here.

          h.   Side-by-side text.  There is no way to make text appear side
               by side in a single column, without either creating a table,
               or creating an anchored text frame, neither of which is tag-
               dependent; both require extra steps.  [Ventura allows you to
               start a second paragraph on the same line as the first.]

          i.   Smart quotes.  This is a useful function, but it is
               document-specific rather than tag specific.  In some of our
               paragraph tags we do want smart quotes, and in some we
               don't.  There is no way to make them tag-specific.

          j.   It would be useful to be able to open windows for different
               parts of the same document simultaneously, allowing you to
               move/copy text easily within a chapter.

          k.   Copying to the clipboard doesn't always work, especially
               after first starting Frame.

          l.   Hyphenation.  When Frame doesn't recognize a word, it will
               hyphenate it arbitrarily, e.g. PROGRAM/ESQL might hyphenate
               PROGRAM/E-
               SQL.

          m.   Variables -- the <$paranum>-type variables are useful, but
               they are rather cryptic -- you practically have to be a
               programmer to use them.  It would also be nice to be able to
               use them anywhere -- in paragraph tags, on reference pages,
               etc.

     5.   File management.

          a.   Copying a book.  There is no way to copy or move all of the
               files in a book to another folder or diskette without losing
               the "pointers" to files/graphics imported by reference,
               unless it's to another disk with the exact same path struc-
               ture.  This is especially a problem if you wish to move or
               copy a book to a new folder on the same disk.  There is no
               way to copy a book to diskette if the book is bigger than
               one diskette, other than manually moving individual files
               over using the Mac Finder.  References to import-by-
               reference files/graphics are lost.  [Ventura has a COPY ALL
               command which copies the entire publication to diskette,
               prompting you to replace diskettes when full, and changing
               all of the reference pointers -- a very useful function.]

          b.   There is no list of graphics files that are referenced by a
               chapter, or where they are located.  You must click on each
               frame and select Properties to display this information.  If
               graphics were imported from several different
               sources/folders, they might be overlooked when copying the
               book to another folder or disk.  You might also
               inadvertently copy graphics files that were unnecessary,
               since there is no way of knowing which were used.

     6.   Tables.

          a.   When converting text to tables, and also when applying
               formats to tables, any character formatting in the first
               column is lost.

          b.   There is no way to make a table format with customized
               attributes, such as an invisible column or straddled
               columns.

          c.   Minor custom changes made to a table format, such as
               resizing the columns, will only affect subsequent tables
               created using that format.  Applying the new format to
               previously created tables using the same format name are not
               changed.

     7.   General usability.  I have been accused of being a PC bigot, but
          I believe that for many functions it is faster, easier, and more
          efficient to enter commands from the keyboard than to use the
          mouse.  The keyboard requires less eye strain and hand movement. 
          Simply typing "Y" to a prompt is certainly easier than locating
          the Yes button, locating the pointer, moving it to the button and
          clicking, and you don't even have to look at the screen to do so. 
          I would like to have the option to use the keyboard whenever
          possible.  This would include answering yes/no prompts as well as
          selecting files, tags, format-from files, etc. from scrolling and
          pull-down lists.  (You can, for example, select a file name from
          the Open File dialogue box, but only if you type very quickly and
          accurately.)  Some specific things:

          a.   When closing a file, you can press "Y" to say yes, "N" to
               say no to save the file.  But when you select Save As and
               the file name already exists, you should also be able to
               press "R" to replace.

          b.   Dialogue boxes pop up in different places around the screen,
               requiring you to keep moving the mouse around.  Each "OK"
               button should appear in the same position for each box.  An
               example is the series of dialogue boxes that appear when
               generating a TOC.

          c.   It would be useful to be able to select items from the
               keyboard from pull-down lists, such as when applying master
               pages or using formats from a list of files.

          d.   It would be useful to have the option to use "drop-down"
               menus as well as "pull-down" menus -- menus that pop up when
               the pointer moves over the selection, without pressing the
               mouse button.

	- Scott Stark
	  ASK/Ingres Tech Comm
	  4/9/92