Replied: Tue, 04 Dec 90 23:56:33 EST Replied: Timothy.Freeman@PROOF.ERGO.CS.CMU.EDU To: bovik@CS.CMU.EDU Subject: [Barbara Zayas: Re: FrameMaker? ] Date: Tue, 04 Dec 90 15:15:55 EST From: Timothy.Freeman@PROOF.ERGO.CS.CMU.EDU ------- Forwarded Message Subject: Re: FrameMaker? Date: Tue, 04 Dec 90 13:34:24 EST From: Barbara Zayas Timothy: I saw your note about FrameMaker. I've been working with it now since June. Though I've had no real use for using the mathematics, I thought I'd send you a message anyway telling you of my experiences. This is a bit lengthy, so read what you want, disregard the rest. First, I don't think that there is a bibliography formatting procedure. I've been using the system since June (1990). In that time, we've upgraded to 2.1 and I'm running FM under SunView on a Sun 360. I learned the system pretty much on my own, using the hardcopy tutorial (and asking questions of our local FM guru). Basically, I like the system. As far as WYSIWYGs go, it's fairly powerful and doesn't appear to be too intimadating for the naive user. If choosing between FM and Interleaf, I'd vote (big) for FM. Frame was careful to consider some of the problems that Interleaf users had (such as that with the multi step-through menus) when they designed FM. However, while FM is a pretty tight system, there are some problems and leaks here and there; I'll outline those, as well as highlight some of its strengths. First of all, the documentation is assembled well. It's concise, well-written, and fairly thorough. Unlike some ordeals with Interleaf, I can usually find an answer to my FM question within the manuals and without investing too much time in the process. Very often, within Interleaf I'd spend time troubleshooting some problem and most times I'd stop the hunt without having found the solution to that problem. This often left me with an incomplete feeling of "Well, maybe I just didn't proble too carefully..." and sometimes, I'd resume the hunt unsucessfully. FM is organized well enough such that even if there is no immediate solution to a problem, it will usually be obvious from having read the documentation that is not a feature within FM. In other words, the documentation is clear enough that you are left with a good grasp of its capabilities and limitations. With Interleaf, the documentation was less thorough so, often, the user would be in the dark about whether or not it was their *search* for the solution that was flawed or whether it was an oversight or deficiency in the system's design. The FM hardcopy tutorial is geared toward users with no prior WYSIWYG experience. Some of the material can be skipped quite easily and without difficulty. As far as tutorials goes, this one is pretty neat and efficient. I found that I was able to get into some of the more difficult aspects of FM relatively easily after having completed the tutorial. I'll talk about some of the obvious plusses with FM. The system is relatively easy to use, things seem obvious to the user. (Then again, I've used several WYSIWYGs before, so my ease with the system can doubtless be attributed in part.) As best as I can tell, though, this system doesn't really hide any of the _basic_ components from the user. As with many WYSIWYG systems, the burden of responsibility for design/layout/completion is placed solely on the user; therefore, it can sometimes be a bit frustrating when a naiver user is trying to customize documents. However, as far as the "standardness" of FM, it's solid. In other words, for the basic, everyday user who will want to, say, use a predefined template, the system is not too hairy. To a designer, however, it becomes a little more complex (but certainly still doable). Given what I said about the burden of responsibility being placed on the user, designing templates and corresponding numbering schemes might be a bit hairy given that relatively nothing exists as a default (design-wise). In general, though, I've found that FM is much much easier to customize than was/is Interleaf. FrameMaker's bookmaking feature is a big plus. It handles bookmaking in a way that's not too intimidating. A definite win for FM is in how it allows the user to update other sources based on one central source. For instance, if the user has seven different documents, all with shared component names, and that user also has a "master" document which contains those same component names but with different definitions for those component names, it's easy to update the definitions in those seven documents using that master file. This goes for page layout, variable definitions, cross referencing, reference pages - -- pretty much everything. It might seem petty to talk about something as relatively low-level as spell checker, but FMs checker is wonderful. It goes several levels beyond what it needs to, checking for repeated words, extra spaces, and "straight" quotes. There's an entire menu of options so that the user can pretty much customize the checker for that particular document. Suffice it to say that this is without a doubt the best spelling program that I've used to date. The FM spell checker can even be adapted to handle documents written in foreign languages (however, you can only use one language per document). Also, you can have a corporation-specific dictionary (so that you can enter into it the names of programs or employees so that the user doesn't have to go through the tedious chore of customizing his/her personal dictionary). Oh, and Frame obviously has a sense of humor because if the spell checker catches the word "Interleaf" in your document, it flags it and under the "options" menu, it selects as its primary choice for replacement the word "FrameMaker." The search feature is also pretty useful. You can use it to search for occurences of paragraph components as well as character components and character formatting. FM takes this search one step further and allows you to search for formatting of one type and to change it to another. As far as I knew, this was not a feature in Interleaf. Additionally, there appear to be other features within the search mechanism -- however, I've not yet explored them. Cross references are done easily within FM, but there are problems, which I'll outline in a bit. For general cross-referencing, the user simply calls up the "cross reference" menu and it's an obvious process from there. In fact, I didn't read the documentation on basic cross referencing (or many other features within FM); rather, I just stepped through it within a practice session. Most of the basic components within FM are that easy to grasp. It would seem that Frame paid close attention to the little details of the system, providing as many means as possible in allowing the user free reign over the system. Again, as I said earlier, this can be a bit of a problem for a naive user -- the type of user who simply wants to sit down and produce something quickly. For corporation-wide use of FM, it's best, I believe, to have clearly defined templates for such users to take advantage of. There are obviously other plusses to the system, like the fact that you needn't step through 5 or 6 menus to achieve a desired affect. Also, you can open several menus simultaneously. With Interleaf, if you were viewing the properties window of a particular paragraph, you weren't free to work outside of that props window. Within FM, you can have the FM equivalent to the props window as well as the window for character formatting and paragraph choice windows (and any other window that you can get your hands on or have enough screen space for) open simultaneously. Well, actually, screen space has little to do with it since you can have open windows and since you can stack and/or iconify them. This is a MAJOR plus. Major. On the down side of this, though: when you close the central file, those corresponding component windows stay displayed. This is both a feature and a misfeature. If you wish to close one document and open another, only the central window to that document is closed so that when you open another file, the component formatting windows stay in tact. That's the plus. The fallback is when you decide that you want all FM formatting windows closed, there is no way to do it in one sweep. So, imagine that you've got the paragraph components choice window opened, along with the graphics window, the search window, the paragraph formatting window, and the character formats window (that's not an uncommon scenario for me), if you wish to close them, you must do so within each window, one window at a time. Also, on a window-related issue, often, FM gives you "warning" messages before executing a particular activity. For instance, if you wish to change all occurences of something, a warning window will appear, informing you if the change cannot be undone. When these warning windows appear, you cannot type in any other FM windows until you've satisfied that warning window. The same holds true for the "open" (new file) window. If you've called up this window, you cannot do any other FM tasking until you've closed that window. Also, while the system is updating a file (and this can be a lengthy process if you're working in a book), the user is not free to do anything else FM-wise. That's a lose, in my opinion. I'll list some of the FM weaknesses and problem areas. The first that comes to mind is the problem that one will likely have with cross referencing. Let's assume that you wish to pull the number from a Figure, Figure 2-1, let's say. The caption for Figure 2-1 looks like this: Figure 2-1: Prototyper for Command Widgets That caption numbering is generated such that the "colon" (:) remains part of the numbering. So, assume that inside of your text, you wish to refer to Figure 2-1 as such: This is illustrated in more detail within Figure 2-1. if you use the cross referencing feature in FM, you'll get the following: This is illustrated in more detail within Figure 2-1:. THis happens because the cross referencing function simply looks for the figure, goes into its autonumbering definition and copies it, verbatim. So, if you've got punctuation within that Figure numbering, it will be pulled into the text. That is a major problem, and it's one that FM has not addressed of yet. A common solution is to simply define the Figure numbering system to have no punctuation and to include the punctuation within the caption text itself so that the figure numbering looked like this: Figure 2-1 rather than: Figure 2-1: and so that the caption text looked like this: : Prototyper for Command Widgets rather than this: Prototyper for Command Widgets The problem that I discovered, when using this solution, is that when you create the list of figures, the colons will appear inappropriately. To wit, the table of figures will appear as such: Figure 2-1 : Prototyper for Command Widgets , which is not good. This is a terrible oversight on FMs part and, as I said, I have no clear indication from them as to whether or not this will be fixed within any short period of time. There are also problems with the autonumbering when you have a numbered caption within a figure. However, I've not encountered this problem yet. There are fixes, but they're not intuitive, I believe. I have found that generating a table of contents (TOC) and/or a list of figures (LOF) is not intuitive, in the least. Well, actually GENERATING the TOC and LOF is easily done, but formatting them is another issue. The drivers for the formatting are contained on the document's reference pages and that, in itself, is not too easy to discover. Additionally, FM defaults to a formatless environment for both a TOC and the LOF. To customize the formats is NOT an easy chore. In fact, though I've done it several times, I'm still unclear as to exactly how I achieved the results. Sounds funny, I know. In Interleaf, there was a way to "purge all unused components." There is no real way to do that in FM. So, for example, imagine that you are creating a bookfile that consists of 10 chapters, each chapter existing within a file of its own. Imagine that a different author compiled each chapter and that there was SOME consideration given to consistency of component names, but not a whole lot. If you customize ONE file and then apply its components to the rest, you've solved many of your problems. However, for those authors who chose to use *unique* naming conventions, there is no way, other than broswing through the paragraph choice menu, of knowing which components he/she has defined on his/her own. What results from this, is the confidence that you've updated the files, but the wariness of whether the files are actually correct due to the fact that some components were misnamed. In Interleaf, this was easier to do, though it was by far not a perfected routine. I've had to battle with this more in FM than I've had to with any other WYSIWYG system. FM should be able to tell you which components were altered following an update, so that you have some sort of clue for potential problem areas. There are some other, more minor problems that I've come across in using FM. First, its graphics package seems inferior to that of Interleaf. I found, overall, that I learned about Interleaf's graphics much more quickly than I did FM's. Again, this is likely because the burden of design is on the user, whereas with Interleaf, it was less so, or appeared to be less so. However, I still do not feel comfortable with the graphics features in FM. It's very difficult to position anchored frames precisely in FM and it seems difficult to alter the files once they exist. For instance, the choices for positioning are "below current line" "at top of column" and "at bottom of column". If you choose, for instance, "below current line" it shoves that anchored frame RIGHT AFTER that current line and the ONLY way to get some space between that line and the graphic is to add text to the graphic itself. Increasing the top margin on the caption or following paragraph doesn't work; nor does adding space to the above paragraph's bottom margin. Also, as I said, the graphics package just does not seem to be that obvious or easily driven. Many of my problems with the graphics, though, might be attributed to ignorance -- I've not taken too much time to delve too deeply into the documentation. I did the same for Interleaf, though, and found that I could work within it more easily. So, to compare the two based on my own experiences (since both had relatively equal amounts of time investment from me), I'd go with Interleaf's graphics. Oftentimes, something obviously isn't "right" but finding the cause of the problem might be a bit tricky. Some of the solutions that we've come across have been buried several menus deep. Sometimes, the solutions just aren't obvious. I've had numerous problems with FM freezing on me. For absolutely no reason, FM will render itself parazlyzed with the only recovery being a kill to the maker process (at the Unix level). This jeopardizes the work that you've completed and it is unclear to me, often, which work has been saved and which hasn't. While I have the autosave feature set to jump in at intervals of 5 minutes, I've often lost MUCH more than 5 minutes worth of work due to those system freezes. Now, in defense of FM, I have to say that we've been unable to pinpoint the cause of this problem and it seems to happen to me and inconsistently. I've never experienced that problem with any of the other WYSIWYG systems that I've used on my SUN. Recovering from a crash is not an obvious procedure. The documentation is relatively unclear as to exactly how to procede in a crash situation. As for dealings with Frame central, I can't really comment. All of the communications between my organization and Frame are done via a core group of people within our Facilities division. Anyway, I'm certain that I'm neglecting to mention some things about FM. Overall, my impression of FM is that it's a good system, one that's relatively bug-free and easily-driven. It's easily-learned for the naive users (providing that that user isn't expected to do too much customization). It's customizable enough that a veteran WYSIWYG user will find it fun and even a little challenging. For me, it's a good system; I've enjoyed using it. Though there are some problems with it, it's definitely the best system that I've worked with. ------- End of Forwarded Message