Scriptorium Publishing

content strategy consulting

FrameMaker 10 review

July 30, 2012: We have posted a review of FrameMaker 11.

Here is our initial impression of FrameMaker 10.

I’ve grouped the new FrameMaker 10 features into a couple of categories: overdue but welcome, minor enhancements, important new functionality (for unstructured and structured FrameMaker), and “huh?”.

I’ve also provided a handy FrameMaker 11 to-do list for Adobe.

Note that my categories here are based on the importance of the features to the end users and not on the engineering difficulty.

Overdue but welcome

In this category, you’ll find features that are welcome additions. These include the following:

  • Real-time spell-checker with the expected squiggles under misspelled words
  • Drag and drop text
  • Ability to set background color for text (but still no box around a paragraph)
  • Set poster for multimedia content (this was broken in FrameMaker 9)
  • Improvements to PDF comment import (ditto)

These are all nice, but given this is version 10, a bit late to the party.

Minor enhancements

These are nice-to-haves:

  • Improved tag view—You can now collapse and expand tags in Tag view. This makes the Tag view much more useful. The collapse/expand settings are also applied to the Structure View.

Tag View now lets you collapse and expand elements.

When you collapse element display in the Tag View, those elements are also collapsed in the Structure View

  • Repeat last operation—Similar to Transform Again in Illustrator. Lets you repeat the previous command.
  • Table Catalog (not Table Designer, which is already there)—Gives you a palette, similar to Paragraph and Character Catalog palettes, from which to select table formats.
  • Extended rich media support—A long list of audio and video formats that can be imported.

I like these features, but they are minor improvements.

Important new functionality for unstructured FrameMaker

Here are the most important changes for unstructured FrameMaker:

Finding overrides

FrameMaker authors know that managing their template and avoiding style creep is important. FrameMaker 10 provides new support to help manage this process. The Find/Change dialog box has new support for finding (and removing) overrides. Also, the various catalogs let you control which formats are shown, so you can filter to display only unused formats and then delete them. These features will make template designers and template managers happy.

The Find/Change dialog box now provides an option to search for Paragraph Format Overrides and remove them.

Track Changes improvements

You can now track changes at the book level, and you can set the colors for the changes you are tracking.

Improvements for conditional text expressions

If you use complex conditions, you are going to be much happier in FrameMaker 10. In this version, Adobe has added the ability to save your conditional expressions and to copy them from one document to another via Import Formats. This was a big gap in the user experience in version 9. However, you still cannot use parentheses in your so-called Boolean expressions.

A similar feature is available for Filter by Attribute (which is for filtering in structured documents). The Import Formats dialog box contains a new setting that lets you copy these items from one document to another. Also, the expressions and settings are saved in the XML file as processing instructions.

CMS connectors

FrameMaker 10 will let you work directly with files in two CMSs. Unfortunately, those two CMSs are Documentum and Sharepoint. The vast majority of our customers implement a CMS for structured content, and these two CMSs are particularly unsuitable for DITA. We can only hope that we will see connectors for other CMSs shortly.


Until now, scripting FrameMaker required the acquisition of a third-party tool, FrameScript. In version 10, FrameMaker includes ExtendScript, which is the standard used across many other Adobe applications. Early rumors are that ExtendScript is much more difficult to use than FrameScript. The addition of ExtendScript will be helpful to system integrators like us, though. In the past, we’ve had to ask our customers to license FrameScript, and sometimes the requirement for an additional piece of software has been a problem. Now, we can build scripts in the core product.

Important new functionality for structured FrameMaker

New features on the structured side include the following:

DITA 1.2 support

FrameMaker 10 includes support for DITA 1.2 features, such as keyrefs. If you are planning to author DITA 1.2 content, this is critical.

DITA specialization support

FrameMaker now provides support to convert a specialized DTD into the necessary files to support the specialization in FrameMaker.

I don’t quite understand the dialog box, so I decided to consult the FrameMaker 10 help. My first search resulted in FrameMaker 9 community content, so I checked the Adobe reference only option and searched again.

A search in the help returns no results for DITA specialization.

Hmmm. A brief survey of the table of contents located this:

The search failed, but the information is in the table of contents.

I expect better from a $1000 product that is marketed to technical writers. Actually, I expect better from $50 shareware.

New Attributes Editor

Editing attribute values is much improved with the new Attributes Editor. You can edit several attributes, and you can display only the attributes that are required or that have a value. This is helpful with DITA, which has a lot of attributes.

The new attributes editor lets you modify multiple=

Structured Application Creation Wizard

I am puzzled by the inclusion of this feature, and more puzzled by how Adobe is positioning it:

Benefit from a basic infrastructure for working with structured Adobe® FrameMaker®. With this highly intuitive, UI-based tool, users can start working with structured FrameMaker even if they don’t have any prior knowledge or training. (

Let’s take this point by point. The “highly intuitive, UI-based tool” is a dialog box. The dialog box makes it easier to configure the infamous file. Unfortunately, it does nothing to address the underlying design problems that makes necessary in the first place.

A bit of history is in order here. FrameMaker is unusual in the XML/structured authoring tool world because it provides for authoring and publishing in a single application. It gives you a WYSIWYG display of your XML content and makes excellent PDF output from XML. (“Excellent PDF” from DITA is much harder to achieve than you might think.)

To provide publishing support, FrameMaker must take XML elements and attributes and turn them into FrameMaker objects. For example, a <p> element in DITA needs to become a FrameMaker paragraph and have a paragraph tag (or paragraph formatting) assigned to it. A <b> element needs to become inline text with a character tag. This mapping is done in a variety of configuration files:

  • Element definition document (EDD) describes the structure (usually derived from a DTD) and the formatting (often referencing a formatting template)
  • Template file has the formatting definitions, including paragraph, character, and table tags, along with master pages and other constructs
  • Read/write rules manage some of the more complex mappings, such as index elements

The structured application definition file lists the various configuration files for a given structure type. And the Structured Application Designer lets you more easily specify the files—instead of having to add them to the file by hand, as before.

Do you see the problem yet? I see a bunch:

  1. The file is a total kludge. It’s been around since the earliest versions of structured FrameMaker (aka FrameBuilder), but it is nonetheless a kludge.
  2. Setting up the structured application is a one-time task and is typically done by one person in an organization. That person can then distribute the configuration files and the modified file to all authors within an organization.
  3. The challenging part of the structured application development is creating the various configuration files. Once those exist, actually referencing them in is the least of your problems.
  4. Claiming that the Structured Application “wizard” makes it possible for people to work in structured FrameMaker without training is like saying that because the Boeing 777 has an autopilot, anyone can fly it.

Why, then, is Adobe wasting precious development time on providing an interface for something that extreme FrameMaker experts use once a year? I can only speculate that they are being criticized for an arcane configuration process, so they provided a wizard. Unfortunately, the wizard does nothing to address the actual problem—the required configuration files.

Huh? aka XML code view

What, you say? There’s an XML code view?? Wow. Why didn’t you lead with this?!

“View in Notepad” is exactly that. VIEW. As in, look at but don’t change.

Things you can’t do with View in Notepad:

  • Edit the XML file
  • See changes that you have not yet saved

This pretty well demonstrates the problem with the entire structured authoring experience in FrameMaker. The information displayed in FrameMaker is a “rendered” version of the underlying XML file. When you “View in Notepad,” you are looking at the underlying, UNrendered XML file. Furthermore, by default you are not looking at a text version of your current document but rather a text version of your last-saved document.

Here is what you need to do make this feature semi-usable:

  1. Change the default text editor. This setting resides not in maker.ini, but in a new, single-purpose TextEditorPlugin.ini file, found on Windows under %APPDATA%AdobeFrameMaker10. Open up TextEditorPlugin.ini and you’ll see this:
  2. [TextEditor]

    I changed mine to this:
    TextEditorName=C:Program FilesTextPadTextPad.exe

  3. Close and restart FrameMaker.
  4. Now, you’ll at least see your preferred text editor. Remember that the “View in text editor” feature is exactly that. View. If you attempt to edit the text file that’s displayed, you’ll get an error when you attempt to save. You can, of course, close the file in FrameMaker and then make changes in the text editor.

UPDATE (January 20, 2011): See my comment #17 below for some additional clarification on this.

The implementation of this “feature” shows a general lack of understanding of the actual users and their actual requirements. When we clamor for “XML code view,” what we actually want is the ability to edit the XML files directly and then continue working in FrameMaker. But the developers chose to implement something that meets the letter of the requirement (XML code view) but doesn’t provide useful functionality. The Structured Application Creation “Wizard” has a similar issue—it provides a graphical interface for modifying the file, but does nothing to address the deficiencies of the concept.

Helpful FrameMaker 11 to-do list

Here is a helpful to-do list for FrameMaker 11. These are basic problems that were not addressed in version 10 (or 9 or 8…):

  • Fix CMYK printing issues
  • Provide support for boxes around paragraphs without using tables
  • Provide ability to print contents of Structure View
  • Show all text in Structure View instead of cutting it off
  • Support proper Booleans with parentheses for conditional expressions
  • Make Show Element Context window resizable. (In v9 and previous, it was resizable, but making the dialog box bigger did not cause the text inside to reflow. Version 10 “corrects” this by removing the ability to resize. Unfortunately, reading lengthy context rules can be quite challenging.)
  • Use standards-based files for configuration of structured authoring (DTD or schema rather than EDD)
  • Editable XML code view (I’d settle for oXygen bundled with FrameMaker)

Pricing policy

There’s going to be some screaming about this one. You qualify for upgrade pricing if you have a license for FrameMaker 8 or 9. Those of you with FrameMaker 7 licenses are out of luck and must pay full price for FrameMaker 10. You can, however, get a discount based on your FrameMaker 7 licenses if you license the new Technical Communication Suite 3, which includes FrameMaker 10.
Detailed pricing information is available at Adobe’s site on the FrameMaker product page. It appears that the upgrade from FrameMaker 9 (in the U.S.) is $399 and a full license is $999. However, there’s a price configuration tool that you have to go through to figure out your particular price. Good luck.

Should you upgrade?

If you need the DITA 1.2 support, yes. If you need the CMS connectors to Documentum and Sharepoint, yes. If you’re still on FrameMaker 7.2, you’ve been handed an opportunity to reevaluate your toolsets because this is going to be one expensive new license.

If you’re in FrameMaker 8 or 9, you’ll have to see if there’s a compelling new feature here.

All in all, I think this release is disappointing. The FrameMaker user community deserves better.

Author: Sarah O'Keefe

Content strategy consultant and founder of Scriptorium Publishing. Bilingual English-German, voracious reader, water sports, knitting, and college basketball (go Blue Devils!). Aversions to raw tomatoes, eggplant, and checked baggage.


  1. Sarah, in general I am with you, especially regarding the StructApp “Wizard” (we better keep it quoted…). But the improved tag view IMO is more than just a minor enhancement. Because it also allows you to drag and drop elements like in the Structure View, it has the potential to replace the Structure View window, freeing screen estate. I have some colleagues coming from XML editors who usually work in tag view, but currently still need the Structure View.

  2. @Michael, I agree that Tag View has potential. Not sure about where attributes would go, though. I suppose you could just use the Attributes pod-thing.

    I meant to include your discussion of Adobe’s new focus on rich media and social media, where you said:

    “Diese Überlegungen ignorieren einige Rahmenbedingungen, die mir in Industrieunternehmen regelmäßig begegnen: Es gibt keine Personal-Ressourcen, um weitere Medien zu erstellen; die Mehrzahl der Dokumente wird von den Unternehmen als nicht-öffentlich eingestuft; eine Verbreitung über das öffentliche Web scheint ausgeschlossen.”

    My translation for the non-German-speakers among us: “These calculations ignore some constraints that I see regularly in corporations: there are no resources available to create additional media, the majority of documents are categorized as proprietary, and distribution via the public web is out of the question.”

    This is a very good point. More good points in the rest of the review ( and in the comments, but it is in German.

  3. Hi Sarah;

    Re: the structured app wizard, you commented that:

    >I can only speculate that they are being criticized
    >for an arcane configuration process, so they
    >provided a wizard.

    Yup. That’s about it. I can confirm that several folks mentioned the arcane structured config process directly to Adobe since at least the Frame 8 Beta, if not sooner.

    >Unfortunately, the wizard does nothing to address
    >the actual problem—the required configuration files.

    Errrr. Adding a wizard was not in the list of suggestions. The flip side is that it seems like Adobe is finally getting A Round Tuit. So perhaps progress is being made.

  4. Hi Sarah,

    Sadly, I can’t really disagree with much of anything you said. This release has been pretty lack luster.

    One thing you didn’t mention is that they made HUGE improvements in the integration between Robohelp and FrameMaker. You can actually generate a decent a help system by linking FM books into Robohelp. Now admittedly this was merely a fix for the horrifying kludge they made of the integration process in previous releases (how in the world do you manage to mess up how numbers indent or make it impossible to map to an actual HTML list and still allow the product to be released, I have no idea). Of course, nothing beats mif2go.

    While it remains to be seen, their multimedia support for embedding video in FrameMaker files also looked quite impressive.

    That being said, why oh why don’t we have the following:
    1) robust support for source control. I have managed to subversion framemaker files but it was by no means an easy process.
    2) adding grep support for find and replace
    3) yes i can add formats very easily but why oh why don’t you give us the ability to REMOVE formats or even better remove formatting across books! It would make template maintenance way easier. As it is, removing a single paragraph format from my documentation takes hours.
    4) make hot keys cusotmizable!! you can do that in Robohelp why not framemaker?

  5. For me, the addition of the structured application “wizard” ranks as the most puzzling feature Adobe has added to the structured interface–and I’ve been using the structured version since it was called FrameBuilder in the mid 90s.

    Instead of adding “surface-scratchy” features such as the wizard, I wish Adobe would take the time to get a better grasp of what technical communicators are *really* doing these days–and then figure out how FrameMaker can help us do those things as efficiently as possible.

    For example, many companies adopt DITA to reduce localization costs. While FrameMaker 10 does offer DITA support, the DITA implementation is localization unfriendly (as is the implementation in FrameMaker 9).

    Case in point: the labels for the various note types–Note, Caution, etc.–are derived from the value of note element’s type attribute. On the surface, that sounds like a great idea: the labels are automatically created! However, the downside of that implementation is that it won’t work in non-English content. By extrapolation, should I then add a new value for the type attribute to create the label “Attention” for caution admonishments in French content? That solution is a nonstarter–I shouldn’t have to tinker with DITA structure to generate formatting. Instead, the FrameMaker implementation could, for example, harness the xml:lang attribute to apply the correct labels.

    Adobe’s DITA implementation decision on the note types may seem minor at first, but it snowballs into a mess quickly for any company that has content in multiple languages. I absolutely would not expect Adobe to accommodate every language possibility in the DITA implementation. However, I think it is more than reasonable to expect the implementation to include one more than one language so structure application developers could then replicate changes (preferably in an modular way) to support more languages.

    I would gladly give the structured application wizard (and *everything* related to RoboHelp) back to Adobe in exchange for some multi-language support in the DITA implementation.

  6. Maybe I’m doing it wrong, but when is it important to use boxes around paragraphs? It seems such a small thing to be featured so prominently in a review.

  7. @Evelyn: Boxes are a small thing, but I need them more often than I need background text. A lot of people use boxes to set up warnings or sidebars, and the workaround with tables is annoying in unstructured FrameMaker and problematic in structured FrameMaker.

  8. What I like is the feature of predefining attribute values. Although implementation is a bit unclear – you have to create a ‘Config File’ and add that to a structured app definition or place it in a folder, plus it’s only attribute name driven, not element. But once set it gives the end user a choice list of to use attribute values for a certain attribute.


  9. Regarding “Should you upgrade? If you need the DITA 1.2 support, yes.”, I must respectfully disagree. At its best, Frame’s native DITA support is still severely deficient when compared to that in DITA-FMx, Scott Prentice’s $235 product. For DITA, I’d stick with your current version of Frame, even 7.2, and go with the Leximation add-on at, which will support 1.2 shortly. It’s the only sensible way to work with DITA in Frame.

    I have to agree with your final conclusion; the community *does* deserve better. Much better. But don’t expect it to come from Adobe.

  10. I’m not sure I understand your problems with the FrameMaker configuration of a struct app. Configuration is configuration, and it always includes a number of files. So how is a kludge? It’s a file in the Maker format that captures config information — nothing more or less. Would it be less of a kludge if it was in XML? At least doing it in .fm gives you variables, WYSIWYG comfort, and the full FM struct editing tool set.

    You say app definition should be done with standards files — DTD or schema instead of an EDD. I think that misses the point. To do what an EDD does, you’d need FOSI or maybe XSLT. But these aren’t easy to use… an EDD is much easier because the amount of raw syntax you need to know is minimal, and the rest is organized for you.

    So I’m not clear on either the real nature of your complaint, nor what you’d replace current configuration with. Can you clarify?

    That said, I agree that a struct apps wizard is goofy. The effort probably wasn’t all that great, but it’s effort that could have been spent elsewhere.

    One interesting point is that Adobe seems to be ticking off existing plug-ins one by one. In this release they challenge FrameScript business, and they make my freeware PgfWhopper obsolete. Does this indicate a trend?

    For FM 11 feature wishes, please add:
    * Updated FDK documentation
    * Full window control via FDK
    * Notification before and after creating an ID val (probably 2 hours of development work that would do wonders for integrating Maker with CMS)

  11. Hi Sarah

    Thanks for this review. I had a peek at the beta version of FM10, but was distinctly unimpressed and did not participate in the beta evaluation. However, I followed the discussions about it as they progressed, but came away disillusioned. For $1000 software I expect a lot more than this, as well as a commitment to actually fix problems instead of just saying that “we’ve made a note of them.” It borders on the dishonest.

    I’ve been creating DITA content in FrameMaker for several years, but now find myself looking around for other tools. Improvements in other DITA tools will relegate my FM9 to the status of PDF generator only.


  12. @Chris: My complaint with is mainly the duplication of effort between the EDD and DTD. As a result, you have two copies of the structure definitions. In DITA, the lack of support in the EDD for parameter entities is particularly annoying.

    Also, actually modifying the EDD to add formatting information is not exactly fun. I’d like to see an approach that gets element definitions from a DTD/schema and then provides a GUI for assigning formatting components to the various element contexts.

    I could live without read/write rules. If you’re going to make a wizard, how about a wizard for read/write rules??

    Finally, there’s a pretty significant design problem with the whole thing because you can only have one template per structured application instance. That means you cannot have, for example, two different page sizes (US letter and A4) that use the same structured application instance, even if the structure is entirely the same. There’s a similar problem with multiple languages. The configuration needs to be capable of choosing a template based on an attribute (xml:lang).

  13. @Sarah:

    >My complaint with is mainly the duplication of effort >between the EDD and DTD.

    Yup. Plus you have to set up the rules file – possibly more duplication – and if you’re porting normal Frame files, then you must set up the porting table – which for some reason looks strangely like the DTD.

    And yup. These items were pointed out to Adobe just after Frame 8 Beta.

  14. I’ve been using FrameMaker for 10 years, and I was happy through 7.2. Now I find more to dislike with each new release. The changes aren’t making the product better for me. They just make it harder to use and more prone to crashing. Based on what I’m reading here, this release doesn’t promise to be bucking that trend.

    I agree so much with Alan Pringle’s previous comment:

    “Instead of adding ‘surface-scratchy’ features such as the wizard, I wish Adobe would take the time to get a better grasp of what technical communicators are *really* doing these days–and then figure out how FrameMaker can help us do those things as efficiently as possible.”

    Who made the original FrameMaker? In those days, giants walked the earth.

  15. It seems Thomas Aldous has an answer to the editing XML in Notepad issue.

  16. When I read the marketing for FrameMaker I always get the impression that maybe I’m not using the right tool (Q) to generate my browser-based help, and I should switch to their Tech Comm Suite with Robohelp. What’s your opionion about this Sarah (und Michael)?

  17. @Mark: I took a look at Tom’s (lengthy) video. It solves one problem, but introduces others.

    Tom correctly points out that you can avoid the sharing violation I mentioned above by disabling FrameMaker’s network file locking. When you open the XML file in your XML editor, you will then be able to make changes to the file and even save them.


    1. File locking is there for a reason. If you disable it and another user opens the same file you are working on, you are going to have versioning problems.

    2. In order to get the text editor changes to show up in FrameMaker, you must close and reopen the file in FrameMaker (or use the Revert command). How easy would it be to forget to do this? If you forget, you have a copy of the file open in your XML editor and another copy open in FrameMaker. I don’t know about you, but I expect that I would forget about 90% of the time, so I’d end up with changes made in both places and a total versioning mess.

    I think if you’re going to use this feature, what you need to do instead is leave the network file locking ON. Then, whenever you want to edit in an XML editor, you should close the FrameMaker version before you make any changes in the XML editor. Of course, this leads to an awkward workflow. Either:

    1. View in text editor, which launches text editor and opens the file.
    2. Switch back to FrameMaker and close the file.
    3. Switch back to text editor and make your changes.
    4. Save and close in text editor.
    5. Open in FrameMaker.


    1. Close file in FrameMaker.
    2. Open file in text editor
    3. Make your changes.
    4. Save and close in text editor
    5. Open in FrameMaker.

    I stand by my opinion that this feature, as implemented, is unusable.

    One improvement would be to set up the feature so that when you select View in Text Editor, FrameMaker automatically saves and closes the file before launching it in the text editor.

  18. @Ray: We have used WebWorks Publisher, ePublisher Pro, and MIF2Go. TCS 3/RoboHelp may be a reasonable new entrant in this space, but we are increasingly moved toward XML/XSL for these problems, which eliminates a proprietary tool from the system.

    I have not looked closely at the new RoboHelp.

  19. Apropos comment #15
    @Mark: That video repeats what Sarah’s already stated in this post: Change the default text editor.
    Additional point in the video: Turn off network locking.
    If I understood the video right, I am still editing in the non-FM editor, not *inside* FM. Which is exactly what Sarah has said in her post – FM does not have native XML editing capability.

  20. If/when FM supports boxes around text, will it also support rounded corners? 😉

    • I have a question related to network locking actually. Looking through SDK and ESTK documentation I was not able to find anything about doing it – locking – through a script. Does anyone know how to do that?

      Thanks in advance.


  21. One thing that surprises me about invoking an external text editor for the “View in Notepad” is that FrameMaker itself can act as a perfectly good text editor. From a File Open dialog, you can select a text file, then hold the SHIFT key down when clicking the Open button. FrameMaker prompts you how to treat each line and allows you to check the encoding (which defaults to ANSI, but that’s another story). Click Read and you’re editing a text file in FrameMaker. When you save, just make sure you save as text.

    With a selective, temporary disabling of some FrameMaker features, it would have made a great deal of sense to use FrameMaker to view (and even edit) the XML code directly in FrameMaker.

    This is another example of poorly implemented new features in FrameMaker (a trend since FrameMaker 7.2). I get the feeling that the current FrameMaker developers are not FrameMaker experts. They seem to be unaware of the capabilities of the program or how it is used.

  22. Sarah,

    Hope this is the right place to ask, but do you know what the backward compatibiltiy of FM 10 is? Are we still having to convert .mif from older versions?



  23. Hi Joy,

    I have not tested the backward compatibility, but based on the history, I do expect that you would have to save to MIF from FM 10 if you want to open the file in FM 9 or earlier.

  24. Sarah, your review and the additional feedbacks are one of the most impressives reviews I have read the last months.

    Related to the non-structured FM features I must add another disappointment: The long list of supported video import formats disguises the enormous lack of functionality.

    The number “10” in the current FM version was a unique opportunity to lift DTP functionality into the 21th century, covering full multi media support. This functionality would have to include video previews in FrameMaker, settings for skins and hyperlink settings to certain key frames and so on. FrameMaker 10 does not include these features, it does not even import MP4 files. The current FM import functionality is restricted to a meaningless dpi-settings dialog.

    So the digital publishing hype (from my point of view these use cases are very important for technical documentation also) is with InDesign only – another historical bad planning for FrameMaker I fear.

    But despite all this criticism, also in 2011 FrameMaker remains by far the best of all tools that combines the two worlds DTP and XML.


  25. When you mention the PDF output for DITA is superior, does it include a TOC and Index? For example, say I customized my DITAOT which I use to create HTML Help, and want to import my dita maps into Frame to create PDFs, is that possible?

  26. Hi Sarah, Others,

    I hope the following will you understand the DITA Specialization Integration with FrameMaker 10.


  27. @Kathleen, yes, you can create TOC and index for the PDF output. But that’s not really what separates the FM implementation from the OT. It’s more the ease of making the text look better.

    @Gyanesh, thank you for the link.

  28. Sarah, I appreciate your thorough review, as always.

    I get the impression that Adobe is more focused on selling the TC Suite these days. They don’t seem to realize that those of us who sometimes still use unstructured Frame prefer authoring in Frame and using a converter like Mif2Go. That combination works well, and RoboHelp is overkill.

    But what they REALLY don’t seem to get is that many of us also want to use FM for structured authoring, independent of the TC Suite. There’s certainly enough of a audience to warrant a more evolved XML workflow.


  29. I am currently using FrameMaker 7.2 and have recently acquired FM 10. My documents are regular journal articles. Can documents produced in 10 be used in 7.2?

  30. I am not a super-user so maybe my comments are naive but I recently setup DITA files in FM with DITA FMx to perform according to our styles, sent them out to be translated and then created html and Frame books from them. I am now testing FM TC3 and am totally flummoxed by the DITA files, multiple EDDs, multiple templates and the structapps. I can only find 3 .xsl files so I don’t know where to fix some of the formatting problems.

    My boss wants the push button conversions that Tom Aldous speaks of and he wants the level of formatting control we had achieved in FM 9. I am unable to deliver either one of them.

  31. Additional item that needs to be added to Framemaker Structured apps is the ability to have more than one size paper in a file. If this is already possible, please let me know how to do it. I’ve tried everything I can think of.
    Thank you

  32. @Suryanarayana, no, you cannot use the files you created in FM10 in FM7.2. You should, however, be able, to upgrade the documents from 7.2 to FM10.

  33. Our company uses FrameMaker 7.1 on a steroidal mixture of plugins, Autohotkey scripts, and a home-made toolbar. After trying a demo of FrameMaker 10, we decided not to purchase it. In fact, we were rather shocked at how poorly it was designed.

    Here is a list of the grievances that changed our minds:

    Thanks to the new interface, there is no colored title bar at the top of the screen (you know, the bar that sort of greys out when the window is inactive?). Since the bar won’t change color to reflect whether or not the window is active (it’s unvarying silver), you can never tell if the FrameMaker window is active or not. Okay, you can look at whether or not the little red X button in the corner is red or grey, but this just doesn’t cut it. When you want to activate the FrameMaker window, you reach automatically for the title bar to click it, only to discover that the title bar is filled up with buttons that will do things if you click on them. So then you divert at the last second and click somewhere in the middle of the document instead. We all learned not to do this early on because if you click in the middle of any open program window you’ll probably hit some important button. But with effort and diligence you will unlearn years of experience.

    If you make the FrameMaker window halfsize and then try to resize it by dragging the edges of the windows, you’ll find that you can resize the left, right and bottom edges, but NOT the top edge. It is astounding that any modern program produced by a major company could lack such basic functionality. And of course, because the title bar is gone, the address display (which used to show the location of the FrameMaker file you were working on) is also gone. The file address now displays as a tooltip that pops up when you hover your mouse over a tab, conveniently blocking the bottom row of most-used editing buttons for 3-4 seconds. The address tooltips will also pop up on top of open menus, hiding the option you are looking for and generally making a nuisance of themselves. The small, closely spaced “File” “Edit” “Format” “View” options that took up so little space in FrameMaker 7.1 are now displayed in a larger font and at more widely spaced intervals so that menus which used to take up half of my header bar now take up two thirds of it. If you work in structured mode and have plugins installed which add extra menu items to the header bar (I have two), you will discover that the FrameMaker window becomes hard to grab and drag if you shrink it down so that it occupies, say, the left half of your monitor. This is because with two extra menus there is only about one square centimeter of free space to click on if you wish to drag said window around the screen; the rest of the grabbable surface is taken up by workspace rearrangement buttons and the new grande-sized menus. The new “header bar” isn’t just broad either–it’s tall, nearly twice as tall as the old bar that held the “File, Edit, etc.” buttons. So apparently Adobe got rid of the title bar just so that they could add extra padding to the “header bar” and give you more space to click on the File button. (On a side note, my own private gripe with the new header bar is that the unique “close, restore down, minimize” buttons in the upper right hand corner of the screen interfere with my 3rd party double monitor software, which normally adds two window management buttons to “move window to other screen” and “maximize window across both desktops.” The multimonitor buttons cover up the aesthetically pleasing but nonstandard FrameMaker buttons so that I can no longer minimize FrameMaker normally.)

    The FrameMaker 10 interface is colored a grim battleship grey. It is ugly, unfriendly, and wears on the eyes…not unlike the interior of a submarine, except that they started adding color to submarine interiors because they discovered that it wore people’s eyes out and demoralized them. Someday we will be able to tell our children that all we had was black and white FrameMaker. In the meantime, it is now harder to tell buttons apart and instant recognition may take awhile to develop. Happy hunting?

    There is a ghastly waste of space everywhere. Nearly an inch of seldom-used buttons has been added to the bottom of the paragraph catalogue. This should have been compressed into a one-button “Options” menu. The paragraph designer is fatter and taller than its predecessor, and most of that space is blank. Below each set of paragraph controls there is .5 to 1 inches of nothing. Why the extra padding? Because paragraph designer now must be the same size as the character designer and table designer, since it is supposed to share a common window with them. (Problem: I use the paragraph designer every few minutes, table designer every few hours, and character designer every few days. So in essence the functionality of the most important piece of the system has been sacrificed to accomodate the least important part of it.) You can of course remove paragraph designer from its fellow designers and make it is own separate window again, but this won’t get rid of the extra unused space at the bottom and no, you can’t resize it. The graphics toolbar too is chubbier for no apparent reason. The Find/Change dialogue box is twice as big as it used to be and the only added functionality is one circular fill-in bubble and word “Map.” The Marker dialogue is one third again larger. Now we see why FrameMaker needs a “ui visibility” button that toggles on and off the docked user interface so that you can catch a glimpse of the document or actually do some (gasp) typing. There should probably be a tooltip on the “ui visibility” button to advise the user to turn off the UI if they begin to experience the sensation that the walls are closing in on them.

    Where FrameMaker is not too fat, it’s too lean. In several high traffic clicking areas the clickable space has been skimped, making it hard and slow to click on the thing you want. If you have to use fine motor control to click a button, then it’s too small to be convenient/fast and will be avoided by the user unless necessity compels. And unfortunately, FrameMaker 10 does compel. Paragraph designer no longer has nice, big, easy-to-click tabs. They’ve been replaced by tiny, hard to click buttons that float in an ocean of unused screen space. (On a side note, there is also a slight loadup lag when you click each button. The Basic and Font buttons are slowest to load, but the hang is there for all of them. Apparently FrameMaker 7.1 = broadband and FrameMaker 10 = dialup.) The document browsing tabs, a truly heavenly feature, are too thin, and their “close” buttons are way too small. The tabs should have the exact same size, style and features as those in Firefox or that other big-name commercial product everybody used to use before the designers got complacent and lost their market share, Internet Explorer. The title bar for undocked palettes is also too thin, particularly for undocked palettes that have been collapsed down to icon size. It is almost impossible to grab the title bar on such collapsed icons without activating the “expand” button. Fortunately, the double dotted line intended for moving icons around in toolbars is grabbable and provides an effective substitute.

    The document browsing tabs are missing basic functionality. For example, when you have ten tabs open, they should squeeze down to a smaller size and no longer display the entire title of the document. As it is, you can’t even access the tabs that have flowed off the left or right sides of the screen unless you use the dropdown box provided at right. I expect at least as much functionality as I can get from an internet browser.

    When you hover over the icons they will switch to colorful versions of themselves…except for the Table Catalogue button, which strangely turns into a colorful version of the Table Designer. (Oh, and there’s no improved table navigation in FM 10 either.) The marker box’s “Edit Marker” button always looks greyed out and inaccessible, even when it isn’t.

    Sometimes you can’t scroll in the frames; for example, the marker and variable lists occasionally will not allow you to browse through them with the scroll wheel. The scroll wheel, while a little better supported than it used to be, still does not honor the properties set for it in the Control Panel–which is to say that for every flick of the scroll wheel, FrameMaker will only shift the document up/down by one line of text. This is an extremely slow rate when you consider that three lines per scroll is the normal speed.

    When you click to place your cursor in the document, the normal text selection cursor turns into an arrow, of all things. (Anomalously, you can still select with it.) It will remain that way until you move the mouse left or right, at which point it will turn back into a text selection cursor. But even if you scroll up and down, it will stay an arrow. This behavior makes it inconvenient to select individual letters (say for fixing typos) because the arrow gets in the way and blocks your view of the text. It is also nonstandard behavior for all the text editors I have ever used.

    Try this–open the Find/Replace dialogue. Change the selection box from “To Text:” to “To Character Format.” The character format dialogue box will box up. Choose something. Click okay…and watch the character format dialogue box disappear along with the whole Find/Replace dialogue! You’ll have to open the dialogue up again if you want to search. Basic functionality broken.

    If you have a docked window unfurled and you switch focus to a window outside FrameMaker, the docked window will automatically retract, requiring you to open it again when you return to FrameMaker. If you click in the FrameMaker document (say you want to type) while a docked window is open, the docked window will also automatically retract–a bugger if you still wanted to use it. There should be a “Toggle Persistant” checkbox that lets you decide if you want the window to remain open until you close it manually OR to close it automatically after each use.

    FrameMaker is a great program, but flaws are carefully being added to it. The reason for this is that the designers do not ever use FrameMaker themselves. The only way to solve this problem is to uninstall all copies of Word and Wordpad from the computers of everyone involved in the FrameMaker design process, then install copies of FrameMaker 10. Let’s see how long it takes them to see the light and put back BASIC FUNCTIONALITY.

  34. Jennifer, many of the issues you describe are symptomatic of current software development trends, trends that include:

    – A movement to black and dark gray backgrounds for user interfaces. One major problem is that it’s harder to read white text on a black background than it is to read black text on a white background, so to approach the same readability, you have to make the text larger. Either companies don’t do that, making their application harder to use, or they do, wasting precious screen real estate.

    – A movement to abandon the common and familiar OS affordances for proprietary design. Certainly you can bash Microsoft for a myriad of things, but much of how people use day-to-day little things, such as the way they resize widows, have become de facto standards and you mess with them at your peril. I am sure you voice the frustrations of many when affordances either are absent or don’t work as you expect.

    – Software companies aren’t run by software people. bSchool adherents have no clue about the fundamental processes of software development, so they cut what to them seems like fat but in reality eviscerate skillsets critical to software quality.

    – Programmers who think they can design. I don’t think I need to elaborate on this one, but let’s just say that this fallacy leads to UX professionals being considered superfluous.

    – Shorter release cycles. This is adopted to generate more revenue, but it means major features can’t be developed or are released before fully designed (if they are designed at all), developed, and tested. This is related to the provable fallacy that faster to market is preferable to better to market.

    – The web/cloud. Management has the terribly misguided notion that everything is moving to the web/cloud, so everything has to look like it’s on the web. Nothing could be further from the truth. But programming components are being designed to look more web-like and incorporated into desktop programs.

    – A fundamental ignorance of basic UX and usability principles, combined with a failure to understand how people really use the product. For example, when you’re using a mouse, when you want to click on something, you need to have the pointer hit a target. Make the target too small and you increase frustration for users. One of the reasons Apple made it’s menu bar stick to the top of the screen was so users could push their mouse pointer up to the top and it would not overshoot its target. But new technologies such as smartphones and tablets mean that people aren’t using their mouse, but are using fingers, which have a much larger “footprint” on a screen. So targets for tapping in these cases, are being made bigger. Unfortunately, this design pattern is being pushed to desktop applications. Certainly there is a move to touch desktop interfaces, but that’s just not going to happen for a product such as FrameMaker, making screen-real-estate-hogging affordances from the touch world are wasted here.

    – Broken basic functionality is usually a result of someone, usually in management, having an idea of a “cool” feature. they decide to implement it without finding out if their users really need it. (That said, I’m sure Adobe gets plenty of feedback, and they presumably prioritize somewhat based on that feedback.) But is Adobe really suggesting that drag-and-drop text and inline spell checking was such a low priority that it took until version 10 to make an appearance? If anything, that’s basic functionality. That these basic things took so long to appear indicates an enamoration with flash over substance. (Say what you want, Adobe, this is the actual evidence, and I believe actions do in fact speak louder than words.)

  35. I, also, really dislike most of the new FrameMaker interface. I can’t explain it better than Jennifer_P’s magnum opus.

    In addition to this, I recently installed the trial version of FrameMaker 10 and it uninstalled my existing Acrobat version 6 (which although ancient still did everything I needed). It removed the Acrobat program files and everything, without mentioning it (that I noticed).

    But I bought FrameMaker 10 anyway at full price because my existing versions were Fm 7.2. Needed it for a client, no other reason – 7.2 still did what I needed, and had a mostly better interface.

  36. Thanks for the analysis Chuck; that explains a lot, unfortunately. And Adobe’s actions do indeed speak louder than their words. -_-

    @Mark — 7.2 is the version I bought for myself a couple months ago. :) I’m pretty happy with it, except for all the popup messages. But I suppress them with ClickOff (freeware program).

  37. How does on insert special characters such as emperson or anpeson.
    We are using framemaker 10.


  38. @Pete, there are a couple of ways to insert special characters. The old-school way is to use arcane keyboard shortcuts, like Ctrl+Q Shift+Q for an em dash. There’s a list here:

    You can also use the Windows character map. And FrameMaker 10 has a drop-down list of special characters that you can insert from.

  39. Thanks Sarah, I found the special characters in the pull down toolbar >file>Utilities>Character palette which is what I was looking for.

  40. Sarah, I’ll add my thanks for your review: I’ve been working with FM10 for several months, but learned of some features that I hadn’t yet noticed.

    I can suggest one big reason that folks might want to consider moving from FM9 to FM10 though: Under Windows 7, FM9 leaks — no, make that “hemorrhages” — GDI objects. (Mostly when you open a file.) When the GDI-object usage reaches 10,000, the user interface stops responding. Good luck getting those edits back!

    Under normal usage we’ve seen this happen within the span of a working day. If one is foolish enough to leave the Windows 7 Task Manager open in order to monitor FM9’s GDI-object consumption, the usage skyrockets for some reason and the UI stops responding within about an hour. I was not able to find a fix for this, and ended up writing an FDK plugin that monitors GDI-object usage and warns the user when the limit is near.

    We’re still evaluating FM10, but at least the GDI leak seems to be fixed.

  41. Hi Sarah, and Happy New Year! A year has passed since you published this review. I’m curious as to whether Adobe has resolved any of the issues or if they have tweaked some of the “feature enhancements” since you wrote this review last year.

    Eddie V.

  42. @Eddie: There are some updates. Adobe released a patch that fixes CMYK issues. I haven’t tested it, but I also haven’t heard any screaming from others, so I’m optimistic. Regarding CMS connectors, several of the CMS vendors have produced connectors on their side that link to FrameMaker.

  43. Dear Sarah,

    After a lot of research, I came across your forum and turning to you for a critical error that I am facing with respect to FM10 and RH9 integration for generating Online Help. I have an FM chapter that has for example, 5 Headings (1 h1, and four h2s). I have made changes in the HTML Setup dialog box, where you select the check box that says ‘Start a new, linked, Web page’. However, when I import this chapter into Robohelp, I am not able to view only one HTML, vis-a-vis 5 HTMLs. I have tried to tweak the HTML table in the Reference page, but unable to achieve the desired results. I have a User Guide source in FM which is about 600 pages, and trying to break it into separate HTMLs manually would be defeating the ‘single-sourcing’ concept. I would really appreciate if you could find a resolution to this problem. Thanks.

    • Hi Nandini,
      When you say that you are using the HTML Setup dialog box and the Reference pages, are you referring to settings in FrameMaker? Those will not affect results when you go to RoboHelp. You need to configure the RoboHelp import to split your files.

    • Hi Nandini,

      Sarah asked me to take a look at this for you…

      I believe you are attempting to control your RoboHelp linking by adjusting your FrameMaker reference pages. These reference pages are only for exporting HTML directly from FrameMaker, and are not used by RoboHelp in any way.

      Check your settings in RoboHelp under
      File > Project Settings > Import > FrameMaker >Edit

      In there you’ll find the option to map your Heading 1 and Heading 2 formats to the CSS in your robohelp project. You’ll also find the option to create a new topic each time that style is found in the document. The option is Pagination (Start new topic based on this style) or something like that. If you don’t have the extra label after pagination, you’ll want to download the RH 9.0.2 patch, as it makes this whole process much smoother.

      Feel free to comment here, but you might also want to visit the RoboHelp FrameMaker integration forums at

      -Matt Sullivan

  44. Correction:

    However, when I import this chapter into Robohelp, I am able to view only one HTML, vis-a-vis 5 HTMLs.


  45. Dear Matt and Sarah,

    I just tried this option and yippie!!! It worked! I cannot thank you enough.
    I just have another question for you though…When I save the Frame source file with the conditional text set to ‘Help-only’, and then import the same into RoboHelp, I can also see the ‘Print-only’ text being imported, and it shows up even in the chm/WebHelp. Does that mean that I have to reapply the conditional text again in RH? Or is there a workaround?

    Waiting to hear back from you…thanks.

  46. Dear Matt and Sarah,

    I figured out how to reinforce the conditional text setting in the same dialog box in RH 9 where you fix the pagination. I am able to see only the ‘Help-only’ conditional text now.

    However, I’ve a new problem – I’m unable to link the Frame files in Robohelp, as I don’t see any of the source FM files in the Project Manager pod either when I select the book or expand the book that I’ve imported. I can only see the html topics in the Project Files folder even when I toggle the view. If I right-click the book, and then select Link, the Framemaker document option is disabled. Where could I have gone wrong? Please help. Thanks.

    • Hi Pamela.Yes, where tech comm has actually aptdoed the Web as a medium rather than just a delivery vehicle, it has done so with Wikis. Wikis are a natural Every Page is Page One media, so I am very encouraged to see the spread of Wikis in tech comm.Of course, being a structured text guy, what I really want see is the adoption of structured text in generating EPPO content. Right now, it is really the empty quadrant. We have structured and unstructured authoring of books, and unstructured authoring of EPPO topics (on wikis), but the structured/EPPO quadrant is pretty sparcely populated right now. Need to change that.