What’s Become of Adobe FrameMaker?

Up until a couple of years ago, most of my customers used Adobe FrameMaker to create their technical documentation. The most common package we sold was Adobe FrameMaker + Quadralay WebWorks, from templates through indexing. The most common conversion we did was MS Word to Adobe FrameMaker. In fact, I’d say that a good 90% of our technical documentation business was FrameMaker-based.

I am sad to report that I have seen a precipitous drop in FrameMaker-based projects over the past few years. I’d estimate that anywhere from 30-40% of our FrameMaker business is gone. Instead, more and more customers are asking us to create content using XML editors, such as Arbortext and XMetaL. In addition to XML editors, many of our customers are now using wikis for content creation, such as Confluence or MediaWiki.

Even more perplexing are the reasons for FrameMaker’s demise in the enterprise. There are two main reasons: customer behavior within the enterprise and Adobe’s own marketing. Let me explain.

Customer Behavior

  • More customers moving willy-nilly to XML
    The thinking here is that moving to XML will – in itself – promote re-use of content (it won’t). I have no problem with XML and XML editors mind you. What I have a problem with is the wholesale move to XML editors without thinking through the ramifications on how you will use, store, and access the chunks of XML content you are creating over time. XML is supposed to make it easier for you to pick up and use chunks of content anywhere and everywhere; which is fine if that is your need. Meanwhile, the law of unintended consequences really does apply.
  • More customers moving to wikis for content creation
    Using Confluence, MediaWiki, or similar tools, wikis can be an excellent way to make the creation of technical content more social, and distribute the task across technical teams. But watch out. The technical content created using a wiki in this manner tends to be wild and wooly, lacking the kind of standardization around terminology that makes it suitable for translation or use by non-technical customers. To make content easy to understand and follow, customers need content that has been edited against a terminology manager and a tight set of standards.

Adobe’s Own (Mis)Marketing

We all are aware of the innovator’s dilemma, a term coined by Clayton M. Christensen, the Harvard Business School Professor in his landmark book. Without getting too academic, the innovator’s dilemma is all about the following:

Christensen argues that disruptive innovations can hurt successful, well managed companies that are responsive to their customers and have excellent research and development. These companies tend to ignore the markets most susceptible to disruptive innovations, because the markets have very tight profit margins and are too small to provide a good growth rate to an established (sizable) firm. Thus disruptive technology provides an example of when the common business-world advice to “focus on the customer” (“stay close to the customer”, “listen to the customer”) can sometimes be strategically counterproductive.

In short, Christensen would have predicted the demise of FrameMaker based on the rise of disruptive technologies such as XML and wikis. Adobe was so busy advancing FrameMaker in little ways that they forgot to look at the big picture; the fact that XML and social media were radically changing the landscape of technical content forever.

Is this what happened to Adobe FrameMaker … really?

Perhaps. But my thinking is that the demise of FrameMaker is both a case of innovator’s dilemma and also a confluence (pun intended) of other factors, including:

  • The return of Apple to the Enterprise
    Adobe made a tragic mistake by discontinuing support for MacOS. To attract and retain the largest audiences possible, authoring tools must be cross-platform.
  • Not supporting standard XML doc types
    Instead of standard DTD files, FrameMaker introduced EDD files – which were similar to DTDs, but not quite the same. This confused customers who were looking to Adobe and FrameMaker to simplify XML for them, not make it more complicated. Also, it allowed competitors to cast doubt on FrameMaker, by insinuating that the type of XML it supported was somehow sub-standard.
  • Insufficient attention to quality control
    Odd-numbered releases of FrameMaker were good. Even-numbered releases (versions 4, 6, and 8)? Not so much. As a result, the FrameMaker community got fragmented, as many would sit back and wait, rather than upgrade to the latest, greatest version. With authoring tools, it is important that everyone use the same version of the technology, as it is not uncommon for multiple people to work on a document in a distributed fashion.
  • Positioning that missed the mark
    Yes, FrameMaker is great for creating technical documents, but that doesn’t also imply that the people who use FrameMaker are particularly technical. Most of the people who depend[ed] on Adobe FrameMaker for their livelihood are writers and editors who just happen to use FrameMaker as their authoring tool of choice. (True confessions – I’m one of those people). Yet every demonstration, every webinar, every marketing piece I have seen related to FrameMaker over the past few years focused on positioning FrameMaker as a complex and technical beast best suited for engineers. Why?

To sum up

Frankly, I am perplexed that FrameMaker is still around, given the problems enumerated above. If there was ever a software step-child, this is it. However, the truth is that there is still a big need for unstructured authoring using the original functionality of Adobe FrameMaker. Many companies don’t need structure and all of the complexity that goes with it. But, Adobe needs to get out there and start making the case for it.

Unstructured packages can live in a structured world, just like cars with standard 5-speed stick shifts can co-exist with fancy, 7-speed, paddle shifter models. Not everyone needs 7 speeds or a paddle. I think that Adobe could win back a good portion of the market if it would only try. Instead, believe it or not, I see customers using MS Word for their unstructured documentation. Word is still an inferior tool to FrameMaker, and Adobe should still be in the lead.

What do you think? Did you use FrameMaker in the past and are you now using a different XML editor or a wiki? Do you think that unstructured authoring still has a place in our technologically structured world? I’d love to hear from you.

Val Swisher

Val Swisher is the CEO of Content Rules. She is a well-known expert in global content strategy, content development, and terminology management. Using her 20 years of experience, Val helps companies solve complex content problems by analyzing their content and how it is created.

When not blogging, Val can be found sitting behind her sewing machine working on her latest quilt. She also makes a mean hummus.

Latest posts by Val Swisher (see all)

Blog · Content Development · November 14, 2011


  • Michael O’Neill

    I’m not surprised you’ve seen such a precipitous decline in Frame +WWeP consulting.  HAT vendors are creating increasingly complex workflows to try to make parity with what comes out of the box with most wikis.  I finally bit the bullet and used WWeP to push all our content to Confluence, then never looked back. 

    • Thanks for the note, Michael. You are not alone. But I am intrigued at your use of WWeP to push content to Confluence. Maybe we can chat about that, so I can get a better understanding of your workflow?

      • Ellen Chiri

        I’m also intrigued by Michael’s use of WWeP –> Confluence. May I join the chat?

        • Ellen – Absolutely. If I have an opportunity to speak with Michael, I will definitely write up my notes. Stay tuned!

          • Michael McGuire

            I’ve been using FM since the 90s (structured and unstructured), but I seem the team I’m working with now moving towards a wiki solution, led, in part, by me. We have reams of content, heavily conditionalized, and I realize the challenge it will be — and we may end up coming back to FM with our tails between our legs — but the lure of open source and collaborative authoring is a siren call we can’t resist. For an expert, FM is a wonderful tool. What you can’t get out of the box, you can usually FrameScript or ExtendScript.

            In the end, we want to shift towards opensource and non-proprietary methods. Maybe it’s the Linux-nerd in me, but I hate being tied to one vendor and one format.

            The wiki solution forces us towards minimalism and a more rigorous topic-based methodology. And it’s open-source and non-proprietary enough of a solution to satisfy the Linux-nerd in me.

          • Hi Michael – I have a number of customers in the same situation. The lure of collaborative authoring is something they cannot resist either. Dealing with legacy content, whether Frame-based, XML-based, or Word-based continues to be an issue. It is really a “then versus now” situation.

            That said, many of these same customers want opensource and non-proprietary solutions. They have been burned by having to stick with a single vendor format. I’ll be ver interested in knowing what your ultimate solution is. Are you going with something opensource like MediaWiki? Or are you considering Confluence? Or another platform. I would love to stay in touch and hear about the solution you ultimately choose and how it works for you. If you can, please email me at vals@contentrules.com if you have the time. Thanks and good luck!

          • Anonymous

            We went as cheap as possible 🙂 FOSwiki is a fork of TWiki, and it’s been working very well for us so far. It does,however, require someone with technical abilities to manage. We’ll no more when the test projects scale up and more people are using it.

            We considered MediaWiki, especially the Semantic add-on, but went with FOSwiki for the built-in structured aspects. We’ve really only scratched the surface of the tool.

          • Shelley

            I have been in IT (since when it was just called Data Processing) probably more years than you have been alive, and NOTHING changes. Since the very first computer was upgraded with a newer model, we have always had to migrate from one environment to another. That is the cost of change.

            It is why we get paid the big bucks… to figure out how to make the change as economically and efficiently as possible with as little pain and disruption as possible. It is our job!!! Get over it!

      • Hi Folks!

        Sorry for the delay. Busy day…  But to get back to the subject, I’d be glad to talk with you.  You can reach me on twitter at @mojoneill and we can take it from there (phone, email, G+ discussion…I’m game for anything). I can also answer questions here, push my thoughts out to a blog article, etc…

        • Michael – I will definitely follow you on twitter. I’m @contentrulesinc, if you’d like to follow me back. Do you have a blog where you can post more about this topic? If not, would you consider writing a guest post on this blog? I think that there a many people who are faced with the same issues that you have and would love to know more about your current solution. Thanks so much for taking the time!

  • I think in part that Adobe’s neglect of FrameMaker goes back to Corel’s failure to keep Ventura viable. Once the last competitor was gone, there was no incentive to invest in FrameMaker, beyond doing just enough to drive the upgrade cycle.

    But I think the cause of the decline you are seeing is not so much XML or wikis per se as the move to topic based writing. Frame’s unique claim in the marketplace was that it could handle large complex technical documents. Fewer and fewer people are writing such documents anymore. Word suffices for those with less ambitious long document needs, and the topic-based authoring splits three ways between HATs, XML, and wikis. Frame simply isn’t a good tool for writing topics.

    XML and wikis represent different reactions to the productivity crisis in pubs. One seeks productivity through automation and the other through crowdsourcing.

    I agree with you that many of those moving to XML and Wikis today are doing so without sufficient thought about or understanding of the content management challenges that they will face down the road as time passes and their content sets grow. What happens when these insufficiently structured and governed systems reach the content management crisis point remains to be seen. A flight back to DTP is not out of the question.

    I’m not so sure that consistency is going to be a decisive issue. The killer issue for pubs today is coverage. Pubs simply don’t cover most of the real world issues that users are trying to solve. If crowdsourcing through wikis addresses coverage, I think the loss of consistency will be tolerated. After all, we tolerate it when we Google for answers to questions not covered by the docs. The web is the ultimate triumph of coverage over consistency.

    • Mark – Thanks for your thoughtful response. Your point about the “productivity crisis” in pubs is interesting and one that I will ponder more. I agree that one is automation-based and the other is crowdsourcing-based. It is an interesting way to position the rise of both technologies and also one of the differences between the two.

      I think that consistency becomes an issue when one of the end goals is translation and localization. Trying to make sense of crowdsourced content from a localization standpoint is … looking for a good analogy here … hrm … is like trying to put a bunch of people from different countries in the same room, all speaking at the same time, and trying to follow along. (Maybe that’s not the best analogy, but I hope you know what I mean!). I spend a lot of time thinking about the promise and the challenges of user-generated content. And while I think it holds a lot of promise, I fear the challenges from a globalization standpoint are going prove daunting.

      • Val – I agree that translation and localization is the place that consistency becomes much more of an issue. Ultimately this may be the sticking point for crowdsourcing approaches — unless they find a way to crowdsource translation and localization.

        • Lots of companies are trying to crowdsource translation – this seems to be all the rage right now. The problem is that source content that is crowdsourced is simply not translatable. Without consistency of text, adherence to basic rules of grammar (not to mention corporate style and branding, but let’s not go there), translation is an extremely difficult, if not completely impossible, task.

          “Back in the day” – which was, like, last year – there was a central clearinghouse for content. It was usually the marketing department or the tech doc department. Someone was in charge. Someone was checking on quality. With crowdsourcing, there is no longer a central point – unless a company has a really good curation process.

          Ultimately, I think that content curation is going to become more and more important as writing becomes dispersed. It is going to be the role of the curator to make sure that content conforms to style, grammar, and terminology. And then it will be translatable. Until then, I am just watching this problem start to unravel the process.

          Thanks again for your thoughts.

          • Derek Read

            I think Simplified Technical English may come into play here and in my opinion would be one of the best solutions to the issue of translation / localization. It is something that many of the larger clients I support use (all of whom have standardized on XML).

            It seems to be more popular in the EU (where they are mandated to do translations in many cases) and it seems that most of the companies producing software to aid with “controlled authoring” and “STE” are based there.

            The main argument for STE is that if your English documentation follows a strict set of guidelines (standardizing both the grammar and limiting the vocabulary) it should be easier to translate. However, there are other benefits, including the understandability of the original English documents themselves, which in turn makes them easier to maintain by multiple authors (if properly trained, though STE tools can also help with that).

            Many XML authoring tools support plug-ins that help with writing STE and there are many systems dedicated to it (from authoring, to content management, to the translation systems themselves).

            However, I don’t think it is just the lack of tools that might be slowing the adoption of STE for crowd-sourced content, it is likely just easier to enforce its usage on small groups (and perhaps more specifically, people you pay). Mandating STE for crowd-sourced content could be done obviously, but I don’t know that the will is there (I have not personally seen any projects like that). Perhaps having tools in place would help to some degree. I’m not aware of any (but maybe someone else will point us at some).

    • I would say the “productivity crisis” in pubs is actually an application intelligence problem. Apps need to be built with the capability to gauge the user’s expertise and thereby offer appropriate assistance as the user’s time-with-product increases. Today’s assistance paradigm requires the (“heroic”) technical writer to anticipate all possible errors that a user can make while using the product. This is absurd and leads to the social media- and wiki-style crowdsourcing of “answers.” TCers will continue to sit behind the 8 ball until apps designers architect a new kind of application intelligence framework or layer that includes a model of user expertise against which the user’s interactions can be compared and by which proper real-time assistance can be offered. Who among the establishment TC glitterati are advocating among the software producers to address this quagmire?

      • Wow, Paul, that’s a pretty tall order. I’m not sure that we have anything approaching an effective algorithm for gauging the user’s exertise. User’s expertise is a pretty complex and individual thing. Even if one had an algorithm, where would the data come from? People are increasingly resistant to the kind of data gathering that websites do to try to predict buying behavior. I’m not sure how popular an app would be that gathered even more data about you.

        As for crowdsourcing, that has been part of human civilization from the beginning. Technical communication as a distict profession is newly hatched chick compared to the old rooster that is crowdsourced technical information. We have a great deal to learn from crowdsourced technical communication, especially about what it means to be task focussed, and about the social life of technical information in a community.

      • Shelley

        My God, I can’t believe I’m hearing this drivel. Every one of us knows how technical documentation and all the tools work. It’s exactly the same as any startup business endeavor. There are capital outlays and expenses. Capital usually involves a one time huge outlay of cash, and expenses cover the ongoing business. In the education of users, it’s called the learning curve and everyday use.

        We don’t need to monitor ongoing usage patterns, we only need to do some front end research to verify how our readers are going to use our tools. The design of our products should allow for some in-depth help for new users, but we don’t need to continually monitor them. After the initial learning curve is over, all users only need to get that deep level of help for seldom used features that they use infrequently and for which they don’t develop deep rooted skills.

        There are User Laboratories for the kind of research into the kinds of behavior we need to consider when developing our products. Those labs do have tools to measure user interactions with the software. I would guess that most of us couldn’t effectively use that type of data or that level of complexity even if it were available. Why don’t we just focus on what we already know.

        Users are beginners for a short period of time. Then need extra help to get over the learning curve. For the lifetime of the documentation, most users will have a well defined skill level. Some will continue to be ignorant of the tools capabilities and continue to struggle. Others will become experts and gurus. As writers, we only need to remember that we need to address both audiences. I personally believe that the long term use of the product has significantly more return on investment than simply getting over the learning curve. You can argue about this all you want, but generally measuring user interaction just ain’t gonna happen. It just isn’t a very efficient use of tool developers time.

        Of course, some tools depend on learning the users behavior. For example screen keyboards that learn new words and phrases frequently used. For these products, learning algorithms are a natural component of the design and make good advertising fodder for the companies that market them. For most to the documentation we produce and the tools we use, this is not true. I think that we buy products from the designers and developers who know our business. We should know our clients business as well, but we do not need to build that level of complexity into our products.

  • Rtillotson

    For small tech writing shops that focus on unstructured formats, FrameMaker will remain the gold standard. Nothing can provide the power and variety of documentation format choices more than Frame. It is the quintesential software for creating all sizes of documentation.

    • I agree 100%. Unfortunately, far too many customers are being led down the XML path for no reason (other than someone told them that is the path they should be on). I have many customers who experience the laws of unintended consequences and end up either multiple XML chunks that all say essentially the same thing, or they never planned on reusing the content in the first place. For these companies, Frame is really the solution. Now, where is Adobe in this conversation? I haven’t seen them say anything about it.

      • Prhmusic

        One of the things we have now is 20 user guides, one for each client, that all document the same system. There is a lot of duplication of content. For example, “Adding a New User” is a procedure that all of these docs have. However, within the procedure, there is (sometimes) client-specific text that has been added. There must be a way to have that procedure and tag the client-specific stuff and then generate 20 different user guides, essentially the same Word docs I have now. On top of that is the challenge of having online Help written in a different tool. Whereas the user guide has numbered procedures, the online Help might have the same content as a paragraph. The online Help displays in an embedded UA pane in the software and was written as a paragraph so the user doesn’t have to scroll a lot (am looking into different ways that the content can be layered).

        Is XML the path I should be on?

        • Derek Read

          XML would help here, and specifically DITA or DocBook have both standardized the concept of “conditional text” (called “profiling” in DocBook) as part of their specifications. Most XML editors that ship with support for DITA or DocBook provide some form of UI specifically designed to help with conditional text (among other reuse strategies such as ‘conref’ in DITA).

          Some unstructured tools also have similar features, and there are plug-ins for Word that do conditional text, but these will be proprietary (ie: designed to work with that specific tool) so that once you set something like that up you
          are probably locking yourself even closer to a particular authoring tool.

          With XML, instead of locking yourself to a particular tool you end up standarizing on a particular markup language (eg: DITA). This gives you far more flexibility to choose from a wide variety of tools that will allow you to edit the same content (ie: don’t like tool A, switch to tool B, or use both at the same time).

          XML is designed to be transformed however, so even then it is arguably easier to switch to a different markup language later on if absolutely necessary.

      • Shelley

        Val, There is no “path” to XML. It is just a single, consistent, and powerful specification of document format… a mark up language for the definition, structure, and storage of documents. So far  in this discussion, we have been talking about apples and oranges. Apples: how documents are structured and stored; and Oranges: the tools that use that structure.

        Think back to the early days of Apple Macintosh when Apple file formats were incompatible with PC files. It made life very difficult for people who worked with both sets of hardware. XML unifies the definition of documents, but it doesn’t actually create them. It’s the tools that use those capabilities that determine how rich the document display can be.

        Just like everybody in the United States drives on the right side of the road because that is our single defined rule, I believe that every documentation product should store its output in XML format because that is the single, consistent document format that exists today — at least for Internet documents. The problem with FrameMaker, and probably the biggest reason for its decline, is that Frame does not use all of XML capabilities and doesn’t integrate other display technology very well in its output documents. It is effective in producing only one kind of document, and that style of documentation is fading.

        As for the discussion of Adobe itself, it appears that FrameMaker is not on their roadmap of  mainline development. Adobe has other products that do address all the concerns mentioned in our discussion. Adobe has chosen to take other paths to attract their market target. Unfortunately, we are the victims of that decision. Whether we like it or not, Frame has only one target audience, professional technical writers, and that market is dwindling.

        For the majority of companies that do not have professional writers, Frame is not an effective or convenient solution. More often than not, the engineers who write the software become the authors who write the documentation. They are the ones who choose the tools they use (or at least recommend the ones they want). The powers that do make the decisions want documentation that makes their products look best, and they choose the tools that make that happen. FrameMaker is “bread and butter;” other products are “prime rib and cherries flambe.”

  • Rachel Bowen

    I’ve been using FrameMaker for I can’t count how many years, and ever since the beginning, I’ve heard of its demise. However, it is still here.
    I have never heard of it referred to as a suitable tool for engineers, most can’t use it.
    I haven’t used the latest version, but want to try it out.
    I like its ability to have a master file which calls in other files. This is more sensible than having to have one huge file, it also makes it possible to re-use information in more than one place and obviates the danger of having out of date information as there is only one file on a topic to keep up to date.

    I don’t know when your original post was written, but it looks as though it was written about 15 years ago when this scare was rife.

    some companies have moved to Word as it takes an experienced user to master FrameMaker. But they do have problems with large files.

    And have YOU used the latest version of Word? It gives me the creeps. I have been an expert user of all the previous versions, but I am not now. I CAN use it, but I don’t like it.
    It goes against all the known facts of how we read, and how we can absorb information. Their designers obviously haven’t had very good training.

    • Rachel – Nope. My post was written last night. I’m not sure what scare you are referring to. Adobe has definitely not announced that FrameMaker is going away. In fact, they just released version 10 and have lots of ideas for future releases. If my post sounds like I am starting a “Frame is going away” rumor, my apologies. That is not my intent at all.

      I have always been a FrameMaker groupie and I still am. Which is why it pains me to see so many of my customers turning away from Frame and going to tools that either do more than they need or less than they need.

      I have used the latest version of Word and I don’t like it any more than you do. Which is why it boggles my mind to have customers who prefer it over FrameMaker. So, my point is, where is Adobe in the conversation? People are moving away from Frame and they are letting it happen. At least, that’s my experience from my customer base.

      Thanks for your comments!

  • Prhmusic

    I am one of those that has been a TWer since 2/10/95 and I have not used Frame. I have always worked for companies that use MS Word as their baseline document creation tool, except for one place that used InDesign just like a word processor (not taking advantage of its capabilities at all). Maybe Adobe should still be in the lead. I’m not sure. Where I am at now, FrameMaker would not be accepted with open arms.

    • Wow, you’ve been a tech writer since 1995 and have never used Frame? Color me surprised! What industry do you work in? I have customers who have tried to use InDesign or even Illustrator (!!) like a word processor. Not a good fit. Interesting to hear that all of your tech writing jobs have been Word-based. Thanks for sharing.

      • Prhmusic

        I’ve worked for companies that have created software for: life insurance, hazardous material management (MSDS), telecommunications (billing system), horse management, medical devices (they’re the ones that misused ID), and now education (software for administering online tests). The life insurance and telecommunications companies software was on the iSeries (AS/400) and at both places, we (I) converted from OfficeVision to MS Word. At the telecommunications company, I had created 100 WinHelp files that had to then be converted to HTML. I’m also in eastern Iowa so I know I’m not in the center of the industry

        • That’s a lot of interesting experience (horse management needs tech writing? who knew?!). 

          • Prhmusic

            They needed online Help for their software. That’s another help system I converted from WinHelp to HTML.

    • Easywriter

      That’s nothing! I’ve been a Tech Author since 1975 and not used Frame! I did once use Interleaf, a similar product to Frame (and around at the same time as early versions of Frame), for a few years. Not for the first time, the employer backed the wrong horse – they also picked ForeHelp over RoboHelp.

  • Tom – Thanks so much for the chat this morning. I appreciate your candor and I enjoyed our conversation. I look forward to speaking with you soon.

  • Thanks for your note. I think almost everyone I know who has to create serious content (not just a letter or a 9th grade essay) prefers other tools to Word. I certainly do! This is part of the reason why I scratch my head when I have customers who use Word instead of Frame for complex, non-XML content. I know what you mean about getting emotionally attached to a tool, too!

  • Leslie Tiling


    We met at lunch yesterday at Lavacon. Very interesting article and I could not agree with you more about the MacOS support. I was a loyal FrameMaker evangelist, but that is where/when it really started to go downhill for me and turned out to be the “writing on the wall” for the future of Frame. 

    I have used Frame since 1993 and the Frame/WebWorks combo was my first foray into single-sourcing back in 99. At more than one company, I was the Frame guru and served as an in-house “information architect” — anything that we needed could be achieved with tweaking the template and some “magic” in the reference pages, not to mention a well-formed EDD for structured authoring. It is a powerful and flexible tool, but its development since Adobe took it over is just not what it should have been — and it pains me to say that, because I have been an Adobe fan for years and had great expectations from them. 

    My policy for years has been that I will not work at a company that uses Word as their primary authoring tool. I have turned down more than one job based on that policy. Every time I do have to use it for some random, rogue document need it has confirmed that policy is the correct one for me.

    Recently I have moved over to a startup and had my choice of any tool I requested. No other writers yet, so no need to get buy-in or a group consensus. I went over to Madcap (which I had used previously, but more as an ePub-like conversion tool from Frame). Now I use it as a Tech Pubs IDE, similar to how my developers use Eclipse. 

    However, if Adobe would re-engineer their product so that it could be combined with RoboHelp (rather than just sending content from one to the other) and they again supported the Mac OS, I’d probably be back like someone re-connecting with their old high school sweetheart. 

    But I’m not going to hold my breath.

    • Thanks for your thoughts, Leslie. I’d love to be able to turn away all Word-based projects that way. Unfortunately, we’re too big to do that. And fortunately I have some consultants who actually like using MS Word (I know, I’m equally mind-boggled by this!).

      I will be interested in hearing about your experience with MadCap. We have done a couple of Flare projects and have found that the tool has quite a steep learning curve. We’ve had a couple of writers take MadCap training and once they understand the power, they love it. Please keep me posted on your efforts! And it was nice having lunch with you, too!

      • Sandy Perkins

        Hi Val!
        I’ve moved with the development of the PC through Ventura, Interleaf, and FrameMaker, and in the last two years our little company tried XMetaL and found it astoundingly difficult to convert from Frame and impossible to modify the PDFs without consulting help (which we could not afford). We still have our reference information in Frame, because the effort to convert hundreds of data tables into DITA was too great.
        After 18 months or so of struggle and disappointment, I took the four-day MadCamp Flare training and jumped into creating style sheets for online help, context-sensitive help, and PDFs. Three months later, we are believers.
        Yes, Flare has a learning curve that is extra-steep for those of us without CSS (cascading style sheet) experience, but I’ve created a good PDF prototype; the webhelp looks great; our context-sensitive connectivity problems have disappeared; and two writers are producing new content output that are dazzling our bosses.
        Frame files convert well into Flare, especially tables (yay!), but the quality of imported files improve as your experience with the conversion options improve.The DITA imports into Flare cleanly and ready to print or convert by minimal retagging (because we created mapped tags).
        I know this is very late in the thread lifespan, but you’ve been asking for feedback, and I wanted to give you mine.
        P.S. Flare support is very personal, and very good.  

  • Shelley

    Val, you throw a lot of grist into the mill, not just
    FrameMaker. You toss in all the software that makes up today’s documentation toolbox.
    You drop in XML as the technology for storing and using elements of the content
    we create. Then you allude to the psychology of the people who create
    documentation… professional writers, engineers, technicians, and plain
    hackers. Each of these subjects is probably worth a book alone, but I’ll try to
    touch on each one separately.

    In my opinion (humble or not), in today’s world, XML may be
    state-of-the-art for storing documents, but it is a lot more. It is a universal
    tool, to develop content and manage information. XML incorporates both mechanisms
    to structure content and logic to use that structure to manage and interpret it.
    Engineers love XML because it lets them “program” documents, adding
    structure and logic at the same time they create content. It’s a wonderful toy!
    One of Adobe’s critical errors is not adjusting to the fact that XML is
    becoming the de-facto standard for structuring information.

    Next, I’d like to say a few million, well-chosen words about
    the psychology of communicators. In my opinion, very few people ever consider
    the attitudes and corresponding needs of people who create documentation. First,
    there are professional communicators who know how to research, analyze,
    organize, format, and store content. That’s typically us. We like to use FrameMaker
    because it has been a full-function, easy-to-use (for us anyway), reliable
    content editor. As you mentioned, it is much better than Word for creating and
    editing text.

    Note, I am careful to specify text. With PDF output,
    FrameMaker still leans toward book-like documents and not all the bells and whistles
    of browser friendly screen showcases. Basically, FrameMaker is just a very very
    good text editor. Even with the attempt to make it more Internet compatible, it
    ain’t no Creative Suite.

    The next group of players in the writing jungle are what we
    lovingly refer to as SMEs. These are the people who know the meaning and purpose
    of the underlying technology that requires documentation. The team of professional
    writers and SMEs is unbeatable for creating quality content. Unfortunately, companies
    don’t acknowledge the work we do to make technical documentation accurate,
    user-friendly, and usable. This is probably the single most significant reason
    for the growth of Wiki.

    Wiki is the technocrats’ and amateurs’ tool of convenience
    for creating cheap, fast documentation. The prime example, of course, is
    Wikipedia. Now, anybody can write an encyclopedia… or at least, write an encyclopedia
    article. It doesn’t take a professional communicator to document anything in
    Wikipedia. But it does take an expert to make it useful, friendly, available,
    cross-referenced, and stored properly. Again, engineers love this because they
    don’t have to deal with the complexities of “well-structured”
    information. Many times, I think it’s just “stream-of-consciousness” writing.

    Finally, there are the hackers given the task of creating a
    last minute “User Manual” for some product that’s just about to hit
    the market. These people want the easiest, most convenient editing tool that
    requires the shortest, flattest learning curve… did I hear someone mention

    I think you hit the nail right on the head in your summary
    with one sentence… “Word is still inferior to FrameMaker.” However,
    the world is not looking for a good text editor. It is looking for an EASY tool
    to create content with all the pretty effects possible in today’s presentation
    technology. Unfortunately, FrameMaker is equally inferior to tools that make
    documentation “LOOK COOL.”

    The content is not as important as either the appearance of
    the display or the introduction of the latest and greatest toys… from animated
    displays to interactive learning tools. XML as a framework makes these things possible;
    new tools, not FrameMaker, take advantage of the possibilities.

    • Thanks for your detailed reply, Shelley. I guess I wonder how it is that Adobe, who once had cornered the market for “professional documentation creation” let technology pass it by. Tom Aldous from Adobe, who was kind enough to spend a lot of time talking and listening to me today, would definitely not agree with us, but I have to agree that FrameMaker does not easily allow us to take advantage of many of the new possibilities in the world of content creation. I’m still pondering why they let that occur, particularly in light of the great strides they’ve made in the Creative Suite. (The technical suite sure ain’t the creative suite – I agree wholeheartedly.)

      I’ve received a number of pro-wiki and anti-wiki responses, too. I definitely think that we have a long way to go in terms of controlling collaborative content creation. And I definitely think that it is the wrong answer to a number of content creation challenges. That said, more and more of my customers are going that route for many reasons – not least of which is the cost of creating content. It is unfortunate, but quality is not that important to many companies, as long as some content is out there that is “good enough”. I could write a book on each of these topics too!

      Thanks again for your comments.

      • Kristof011

        The more I work with FrameMaker and Robohelp, the more I wonder what’s going on over there at Adobe.

        It’s mind-blowing to me that the exact same company that is capable of producing such beautifully put-together (and frequently updated) products as Adobe Photoshop, Premiere Pro and even Acrobat Pro can put out something as lazy as the Technical Communications Suite.

        It’s as if they have a whole building dedicated to maintaining and building upon the greatness of the Creative Suite and four guys sitting in a corner who are put to work on FrameMaker and Robohelp about 50% of the time.

        It was nice of Tom Aldous to spend some time talking and listening to you, but he comes across as clueless and out of touch. Really, it’s this sort of top-down thinking which will allow some young upstart with a brilliant (or at least obvious) idea to deliver a fatal blow to Adobe when it comes to technical communications.

        If the company cannot be bothered to be agile and nimble and, most importantly, present AND forward-thinking, that death-blow will be well-deserved.

        • Approved

          ~ Val

          Val Swisher
          Content Rules, Inc.

        • Shelley

           I worked at Adobe several years ago, but I do not know what Tom Aldous authority is at Adobe, My impression is that FrameMaker is a deprecated product only on general maintenance and minimal new development. RoboHelp, I believe is DEAD! When Adobe let the RoboHelp development team go (to form the MadCap company eventually) that was a pretty good signal that Adobe is not too interested in pursuing this product line.

          Yes, Creative Suite is Adobe’s direction. What is keeping everybody from seeing the handwriting on the wall? Does Adobe have to put up a 30-foot glowing neon sign in the middle of Union Square to get that message across? FrameMaker and RobHelp are not big priorities for Adobe. Maybe Tom can show me different evidence, but that’s my impression right now.

  • Steven Tobin

    I used FrameMaker in permanent roles from 1998 to 2004. I’ve been consulting since then, usually as the sole technical author in the place, and not one customer in over seven years has used – or been interested in acquiring and learning – FrameMaker. MS-Word is commonplace and everyone knows how to use it (okay, not everyone is an expert but most everyone can edit a doc even an expert created). Alongside wikis and other web-content it’s become my de-facto norm for documentation. 

    Large companies with a publications/writing team or department can afford to be specialists. In my experience organisations lacking a dedicated writing team have no interest in FrameMaker (or any other specialist writing tool).

    FrameMaker beats Word hands down for control, flexibility and reliability. But Word has the advantage of saturation; everyone uses it already. That I think is a major factor. Only specialists use FrameMaker.

    The customer gets what they want. They’re paying me for quality content, not file format. And many just want documents they can edit themselves once the consultant is gone. Without additional license fees and learning curves.

    • Steven – Thanks for your comment. That is my experience as well. Many of my very small customers insist that when we leave (and they have quality content in their hands) they want to be able to update that content without purchasing any tools or learning anything new. That is why Word still exists in the tech doc arena. Unfortunately, I have spent more time fighting with the formatting that I care to. It is the trade-off between ubiquity and tool-for-a-purpose.

  • Anna van Raaphorst

    I’ve used FrameMaker for close to 20 years (can it be true?!), and I thought it should have expired at least 8 years ago. Remember the announcements or rumored announcements from Adobe that they were going to withdraw support? And the later attempts to market it as a true structured editor especially suited for creating XML/DITA-based documents?

    As for organizations’ lack of foresight in architecting and planning out their structured (XML) documents ahead of time so they can take advantage of information reuse, that is clearly a problem in too many cases. And crowdsourced documentation is often a stopgap measure to get “stuff” (sometimes good, sometimes not so good) out there in a hurry without any thought as to how it will fit into the big picture (oops, there is no big picture, is there?).

    All this is a sea change for many writers and their organizations. To help visualize what is possible in today’s world (as FrameMaker fades into the distance), we think experimenting and prototyping is key. We’ve been doing a lot of that lately, trying to see how best to combine the best of structured with the best of unstructured information collections and looking at new strategies and workflows for writing organizations. Check out http://www.ditainfo.info and http://www.drupalinfo.info.

    • Anna – Thanks for your reply and for our link to some resources on Drupal and DITA. I will definitely check them out. I agree with your sentiment about crowdsourcing and I like the idea of prototyping solutions. There are new technologies coming out all the time and in order to recommend a tools suitable for a customer’s strategy (assuming they have one, that is), prototyping them is an excellent idea.

  • Pingback: Follow-up on Adobe FrameMaker | Content Rules, Inc. (formerly Oak Hill Corp)()

  • Cindy

    I’ve been using FrameMaker since its beta stage in UNIX, on to Mac and PC. It’s a marvelously versatile tool, although my clients have never had any need for the “structured” version. I’m very disappointed that Adobe chose not to upgrade the Mac version to Frame 10, as I recently purchased a Mac Lion. But I’ve solved that by dividing my machine 50-50 so Windows 7 is running all my clients’ work and the Mac side, for now, is just for graphics and playtime (if I ever have any). I still have clients wanting to switch from Word to Frame, from InDesign to Frame, from QuarkXPress to Frame,… from anything to Frame, because it can do everything you want it to do.

    • Thanks for your comments, Cindy. I, too, have started running a VMWare virtual machine on my MacBook running Lion. But, I also have a PC and that is where I have FrameMaker 9 installed. I have not yet upgraded to 10. Remember, I’m even-numbered-release phobic. 🙂

  • I was also a long-time user of FrameMaker, and started using it in the mid-90s on a Unix workstation. It was a great tool for its time, and was *the* solution when it came to handling large document needs. Far better than Word, and more overall support than Ventura.

    Over the years though, it definitely started showing its age, and not only was not keeping pace with the times but was bug-ridden and for the longest time in the early- to mid-2000s seemed to ignore its loyal customer base by offering incremental upgrades (7.1 and 7.2 in particular) that were only marginally better and introduced reams of new bugs. There was hardly a day in the mid-2000s when I didn’t curse the pernicious gods of FrameMaker for crashing during an indexing pass, tweaking an image or even while just saving the document.

    When it came to looking for a collaborative authoring solution, DITA XML while using a CMS made a whole lot more sense than continuing to stick with a product that by 2006 had not had a substantial update in years, and seemed to be a lazy cash cow for Adobe to continually milk. Localization was also costing a fortune, especially the Desktop Publishing (DTP) costs associated with keeping things in FrameMaker. Additionally, having to continually buy third-party tools (IxGen for inserting index markers, WebWorks for online help, etc) to support critical needs just seemed to underscore that continuing to use FrameMaker was a dead end.   

    When Adobe finally got around to releasing FrameMaker 8 in 2007 — with XML and Unicode support — it was too little, far too late (at least for us).  

    Agreed that doing XML authoring without a CMS doesn’t make a lot of sense (other than for very small documentation teams), though when Adobe had the chance to be nimble and innovative with their FrameMaker product in the mid-2000s, they dropped the ball, badly. They’ve been playing catch-up to the marketplace — which demands greater collaboration, can leverage far greater bandwidth and connectivity than was around even ten years ago, and to drive down costs where possible — ever since. 

    FrameMaker was a great product for its time, but that time is past.

    • A shared sentiment, Keith. You expressed it quite eloquently. Thanks for your comments. Gosh, are we seeing a THEME here? 😉

    • FM’s quality certainly regressed after the late 1990s, but why continue to upgrade? Also, your concerns driven by internationalization pertains to a minority of US firms and TCer workers. I don’t that as a primary reason to jettison FM.

      • Thanks for your comment. I’m not sure what you mean by localization pertains to a minority of US firms. In my experience, more and more of my customers are localizing and translating at least some of their technical content. This is a trend that is on the rise in my customer base. Thanks again.

        • Val, you work in Silicon Valley! Not typical of US industry! Software companies are not typical of US enterprises!

          • My customers are nationwide. But, I am happy to agree to disagree on the trend of localizing and translating content. I understand this is not your experience. 🙂

  • Scott Prentice

    Hmm .. looks like I’m late to this party!

    I just want to make one comment about FrameMaker’s XML support. The comparison between DTD and EDD is just wrong. These are not parallel concepts. FrameMaker does use DTDs to validate XML data on the file system. The EDD (and structure application template) is more akin to an XSL-FO stylesheet .. it’s used to apply formatting to the XML data while authoring and for publishing. Other XML editors go through a similar process (some use CSS for styling), they just don’t allow the same level of formatting that you have in FrameMaker because they aren’t intended to be a publishing tool as well as an authoring tool.

    I’m not saying that this is easy, and it can be a roadblock to simple authoring of XML content in FrameMaker .. but once you have the structure application set up for a data model, not only can you author, but you can also publish to PDF .. very nice PDF I might add. I like to think of this as front-loading the publishing effort. Other XML editors let you open and edit the files with fairly little effort, but when you want to publish to PDF, you’ve got a fairly long road ahead of you, and the results are typically not as you’d expect. In fact, most people are told to accept lower quality from their PDF output when they move to XML. This isn’t the case with Frame. When you take the whole authoring and publishing process into consideration, it’s likely that you’ll spend less time and money using Frame, and you’ll get better results. 

    The problem is that most people are lured by the call of “Open Source” and “free” .. so they ditch their seemingly proprietary toolchain for .. well .. another proprietary toolchain .. and one that requires that they pay contractors or outside developers to perform tasks that they used to do in-house. 

    I’m not saying that FrameMaker’s process is perfect by any means. It would be great if it allowed you to edit files without the overhead of a custom structure application. Maybe someday. But it’s important to know what you get from an EDD .. it should not be compared to a DTD .. that’s just misleading.


    • Scott – Thanks so much for your correction and for your opinions. I appreciate it!

  • Shelley

    Val, and everyone else participating in this discussion… I really do hate to rain on this pity-party, but maybe it’s time to face some facts. FrameMaker is only a text editor, a very good one, but only a word processor. There are no “psychic powers” that decide to buy products, only advertising, hype, and word of mouth that convince buyers to choose one product over another. Word is more popular than Frame because everybody knows what it is, and Microsoft loads it on every system that has a Windows operating system. It’s free, cheap, relatively easy to use (for Grandma’s recipes anyway), and it has no “learning curve.”

    Companies don’t want simple, easy-to-use, documentation. They want dynamic, animated, spectacular webpages that SELL their products. The Internet community doesn’t want text, they want pictures, sound, videos, and animated displays that hold their interest and tickle their fancies.  I have had this argument many, many times with many customers. When I tell them they don’t need that kind of frill, all they do is point to a competitor’s product and tell me, “If they have it, we need it!!!” I will give you two outstanding examples of this phenomenon that you can see every single day.

    1. More than 20 years ago, a display manufacturing company commissioned a study to determine the value of color in business data processing online displays. The result was simple — color contributed almost no informational value over basic black and white. Color just wasn’t needed in business computer displays. Look around today… has anyone seen a black and white monitor in the past 20 years? People don’t buy just what they need, they buy what they like.

    2. For hundreds of years, the sound boards of pianos were cast iron, never finished. Then the Yamaha company machined their sound boards to a mirror finish. This machining is totally unnecessary, contributes not one iota to the sound quality of the piano, and drives the cost of manufacturing up dramatically. Do you know that virtually every piano produced today has a machined sound board. People don’t buy just what is necessary, they buy what impresses them.

    The bottom line is that the decision to buy any particular documentation tool is not driven by psychic intuition, but it is far more emotional than scientific. The people that make the decisions want their company’s documentation to be alive, exciting, moving, stirring, and FUN!!! — whether they need it or not. This is the mindset the Internet has created, this is what they buy. And FrameMaker just does not deliver that. I believe that no matter how effective Tom Aldous may be as an evangelist for FrameMaker, no matter how many technical writers demonstrate and protest on their doorstep, Adobe is not likely to re-engineer this world-class word processor to make it into a webpage designer. They already have a roadmap for products to get to that destination, and FrameMaker is just not on it.

    • Shelley – Once again, thanks for your thoughts. I don’t think anyone (or most of the people participating, including me) disagree with you. And I don’t think this is a pity party. I do think it is an honest discussion of why people believe that FrameMaker went from being a viable choice to being a dinosaur. I’m not really hearing anyone saying Frame is the best tool around (except Tom Aldous, that is). We all pretty much agree that Frame’s best days are over. Thanks again. It is an interesting discussion.

    • Ah hem, but there’s a lot more to the Technical Writing world than software product documentation. Take off the blinders and understand that there is going to be a continuing need for long-form technical publication for decades in the government, regulatory, engineering, and scientific realms, all of which employ lots of technical writers. Not to mention that today’s XML/DITA tool chain (especially DITA OT) simply does not support output of format-intensive PDF. Complex table formatting using XML-based solutions? Good luck. FM will continue to play a role as a PDF output engine within a larger XML publication tool chain.

      • I think we all agree that FM is continuing to pay a role as a PDF output engine. That said, I think Adobe has been relegating FrameMaker to a backburner position in terms of potential feature updates, ease of use, and true XML support. It is definitely the best tool for long-form publications and PDF output (though a few people have mentioned Madcap Flare for PDFs, too). Thank for your comments.

  • Thanks for your comments. I am in total agreement with you. What’s funny is that Adobe could be touting the fact that FrameMaker makes beautiful PDF files – and, as you point out, is the only real authoring tool to do this. Lots of companies still need .pdf files and they are not easy to make unless you have Frame. But, Adobe has not picked up this banner as a feature of FrameMaker. Again, I think a combination of product mis-steps and very poor marketing have made it go from the chosen son/daughter to the red-haired stepchild.

    • WritingSolutions2010

      Regarding “and, as you point out, [FrameMaker] is the only real authoring tool to do this”.

      Depending on the need, Madcap Flare does a very good job of producing PDF books.  My experience is that very few if any tech pubs teams need especially complex page layouts, etc.  As such, I’ve discovered that Flare enables me to match FrameMaker’s ability to produce PDF manuals.

      But Flare can also by itself also produce online help; and can output to Word (great for getting review comments), FrameMaker (if an “escape path” from Flare is thought necessary), as well as various mobile outputs, etc.

      Moreover, Flare’s extensive content management abilities enable me to develop a superset of documentation content in a single macro project, then use multiple TOCs, conditional text, gen-time variables, and other product features to generate that superset of content as a variety of bespoke outputs ranging from Quick Start Guides to reference manuals.

      As I stated in my original post, I was for many years of FrameMaker bigot.  But as a consulting technical writer, time is money.  So if if I today have a choice, I’ll choose Flare knowing that it has become the best tool for the job, even when that job includes generating PDF books…

      • Thanks for your comments and information about Flare. We have used Flare on a couple of projects. My Flare writers tell me that it has a bit of a learning curve, but once mastered (see Scott Abel’s comment on mastering tools), Flare is a very powerful tool. I personally have no direct experience with Flare, but I appreciate the information.

      • Marvin

        My technical writing group has recently been using Adobe Robohelp both for creating help projects as well as producing document/pdf style content. It helps us single source content as well as archive and version using it’s integration with source control tools.

        However, it has limitiations in the sophistication of formatting that can be done in the tool and has a tremendous depenency on Cascading Style sheets or Word Templates.

        Some of my complaints may be to my own lack of expertise in using the tool. However, I find it to be as disruptive as anything out on the market and has the potential to replace FrameMaker if Adobe would invest in upgrading the feature set.

  • Why would companies use Word rather than FrameMaker, which seems superior? One main reason is that many more people can be involved in the process because everyone in the office has Word, and only a very few have FrameMaker, in general. So using FrameMaker really restricts who has access to the documents, which many tech writers like, but companies generally don’t. 

    • Agreed. Word is ubiquitous. Everyone knows it – engineers, marketeers, tech support reps. I personally find Word extremely frustrating for even simple documents (it makes me crazy if I have to use it for large, graphic-intensive docs). But, I totally understand why customers demand it. Thanks for your reply!

    • Fei Min Lorente

      All the more reason for Adobe to come out with a FrameMaker Lite, or an XML editing version, or something that makes it cheaper and easier for more people to use FrameMaker. After all, only the technical communicators need access to all the master pages, reference pages, table, paragraph and character designers–everyone else could happily use it to just write and change documents. It’s no harder to learn than Word, and if you factor in all the crazy things that Word does, I think they would find FrameMaker more efficient to use.

  • Jeff Conn

    Is the party over? Am I three days too late to comment? Triceratops is an appropriate analogy. I use Framemaker v9 and 10  almost every workday, 40 weeks a year, year in and year out. Just this afternoon I was looking at the cross reference dialog and realizing what an ancient programming artifact it is. Work is hard enough without getting pissed because the stinking dialog is not re-sizable and I have to scroll way down to get to figure 40 to do my stinking cross reference and then scroll way down again to do figure 41 (Tom Aldous are you taking notes?). I also had to deal with that ancient, piece-of-crap graphics tool bar today –what a remnant of the dark ages of old windows programming that piece of work is…  There is no salvation in switching to Word for long documents, but if only there is something else out there, maybe in the world of xml, that can save me from being stuck in the Framemaker dark ages.

    • Hi Jeff – No, the party is NOT over! I feel your pain. There are so many things Adobe could do, from the small things like improving the dialog boxes, to the large things – I agree. I hope Tom is reading. I have suggested that he pay attention to what everyone is saying on this post. I think Adobe could learn a lot by listening to us. Thanks for your comments.

    • I hadn’t thought of the Frame cross-referencing mechanism for a while… [shudders]. 😉 

      This is an area where XML and access to an API can make life a lot easier. In the DITA CMS we were using we asked for tools to be created to help automate various processes for us. One of the requests was a drag-and-drop cross-reference interface, which worked really well. All we had to do to create a working cross-reference was to drag the target topic onto the topic you were working on, select the section you wanted to link to, and voila! done. Much more user-friendly than the old Frame user interface for that same function. 
      That’s a lot to be said for the additional flexibility that can be had by using open standards and a well-documented API…

  • Scottabel

    Wow! And to think some people still question the value of socially-enabled content. Great job of instigating this discussion — and the two other conversations going on about this topic (that I know of). For me, as a content strategist, these discussions are relevant, timely, professional, and informative. For Adobe, it’s a bounty of free informative, advice, and actionable business intelligence.

    It should be noted, that while Val is spot on with her commentary (and many of the points made in the comment trail are as well) these types of problems are not isolated. Adobe has their fair share of challenges, but so does the industry as a whole — including the other vendors of competing products. I can’t tell you how many times I have wished for my very own “bullshit button” (H/T to Staples marketing team for the “easy” version). If such a button existed, I’d be pressing it almost constantly at most conferences, while reading almost every “whitepaper”, when opening my email, while listening to webinars…you get the picture.

    The problem, as I see it, is a gigantic failure in the marketing of software products. No, despite what you might read in the product marketing collateral, not every vendor is “the industry leader”. Come on, by definition, there can be only one. 

    Don’t get me started on the magical features that allegedly convert your poorly structured, poor-written, poorly thought out content into new and exciting formats like EPUB (not ePub, ePUB, e-Pub, e-PUB…get it right — see: http://idpf.org/epub). “Save As [insert format here]” is not an eBook. No tool in our space actually creates anything related to an eBook, but they’ll lead you to believe they do. They may, one day, once the market settles, standards are fully supported, etc.

    And then there are all of the omissions. The information our vendors neglect to tell you is often more damaging than most imagine. No, Virgina, not everyone can create structured content, but no vendor is going to tell you that.

    I love Adobe FrameMaker. I was raised on it, back in the day, and have always found it a useful application to include in my technical communication toolbox. I like the TechComm Suite even more. I really think it’s short-sighted not to use an integrated suit of tools that includes the ability to create so many types of content (not just the written word) in one familiar interface. Sure, the experience could be much better, the previous attempts weren’t all they could have been, and the speed at which development occurs is not as fast as we need it to be. But, overall, the products are sound. They work, for the most part, and much better than most.

    The problem that seldom is addressed is the lack of commitment to mastering the tools of our trade. Most “professional” technical communicators don’t have a command of their tools. Any consultant will tell you this. And, if you’re honest, you’ll likely admit it. I admit it. I have no idea how to use half of the features (maybe more) of the tools I own. But, in my role, I don’t need to know how they all work. But, I do need to know what is possible, what the tool is capable of doing, and I need to know people who are masters of the tool in question that can help me when needed. If my role were to produce content exclusively about a set of products to a specific audience, then I should definitely have a mastery of my tools. But, most folks don’t. 

    Okay, I obviously need to write my own blog post. Rambling again…Thanks Val. Your instigation is my inspiration. I will watch the comments section here, on Linkedin, and on the forums. 

    • Regarding “mastering tools,” it seems that few on this chat have a clue how to import Word content into FM. Not very impressive. Let your SMEs author in Word, while the TCers produce FM documents. How revolutionary, except that it’s been happening in some shops for over 20 years. Not to mention the very few TCers who use desktop virtualization today to run the right application regardless of its native OS.

      • Hi Paul; Thanks for your comments. I have a feeling that most people on this chat do, in fact, know how to import Word content into FrameMaker. I would even venture to say that many have their SMEs author and perhaps review in Word. I don’t think most people would say this is a very good setup, even though we’ve all been using it for 20+ years. My personal experience is that many of my smaller customers (and some larger customers) are doing away with the Word-to-Frame-to-Word-to-Frame back and forth, and opting for more collaborative methodologies, such as wiki-based writing. That doesn’t mean we aren’t still doing the Frame-Word dance. We are. Thanks again for your thoughts.

        • I wouldn’t understand why there would be any true “back and forth” taking place–that would be a sign of dysfunction. There should be a one-way document flow from SMEs to the publishers. BTW, how complex a data table have you ever entered into a wiki? (That’s what makes me shudder.)

          • Oh, I think that lots of back and forth takes place:

            SME provides content to tech writer (Word to Frame)
            Tech writer creates document send to SME for review (Frame to Word)
            SME provides review comments to tech writer (Word to Frame)

            And hopefully there is time for a second/final review:

            Tech writer provides final review to SME (Frame to Word)
            SME provides any remaining comments to tech writer (Word to Frame)

            At least, that’s the way we’ve been working with our customers and SMEs for 18 years.

          • Better: Produce PDF review drafts, receive review comments via Acrobat. Publishers/editors incorporate revisions.

            Not as good: Produce Save-As-Word review drafts from FM, reviewers revise doc with change bars, then publishers/editors incorporate revisions into FM.

            My experience: when a pubs team exists, SMEs write memos/specs, not document drafts, and only TCers write/edit the customer facing documents.

          • Most of the writers I know absolutely hate getting PDF review comments. And most reviewers I know hate reviewing in PDF even more than the writers receiving the comments. Alas.

          • What each of us likes on a given day isn’t necessarily predictive of a team’s eventual results. Most TCers don’t like learning FM at first, but they eventually become much more productive (vs Word) in the long run, as long as the tool is rolled out and supported effectively.

          • True that, Paul. True that!

          • Anonymous

            Val, the reason for both situations is education. Neither writers nor SMEs know how to effectively use collaborative PDFs. The worst part is that nobody wants to commit the time or effort to changing that. We all want the quick and easy, user-friendly, intuitive tool that will let us instantaneously convert our thoughts to comments.

          • Anonymous

            Believe it or not, I’ve found that most of the baby-boomer generation prefers to make revisions the old-fashioned way with pencil and paper. None of the tools available today are particularly palatable. Again believe it or not, Word is probably the easiest to use revision tracking software around. Adobe has done a really terrible job of making PDF/Acrobat revisions user-friendly and easy-to-use.

            All that having been said, this latest generation coming out of high school and college today has very little use for pencil and paper. They have grown up with keyboards and screens and are intimately familiar with text editing in the ether. However, even with their familiarity, processing revisions is still the one of the most tedious and time consuming tasks.

            I don’t ever think we will get rid of long form documentation (at least not in my lifetime). I still remember my early days as a programmer when everyone was predicting the end of paper. I think we use more paper today than ever before. But… as the Internet becomes all pervasive, I can see that long form doc is heading the way of the LP music disc.

            Paul, even in other arenas than software, the trend is to more online documentation. With smartphones becoming more important tools (and toys) for conveying information, even the government is going all out to eliminate paper and charge into online delivery. Granted, the government will always have to provide hardcopy service to those individuals who are too poor to have a computer or smartphone, or to those who just refuse to use them, but that population is growing exponentially smaller every day.

            The clear direction for today’s technical writing workforce is clearly directed to online collaboration. The tools that will win that particular race will be focusing on interpersonal communication and information navigation. Long form doc is clearly NOT in the center of that mindset (again… just MHO).

          • Shelley, you cannot use Word to combine 25 online reviews into one copy of the reviewed draft that shows all the distinct sets of revisions (for use in an online meeting to accept/reject specific revisions), but you can using Acrobat’s commenting features. That comparative deficiency (collating of revisions to a draft) is yet another dimension in which a pubs workflow using Word does not scale.

            I haven’t seen how an advanced wiki system offers this kind of capability, but I suspect it is a challenge to put into practice because it is inherently a relatively challenging problem to solve, much less to automate.

            Another key issue for authoring in a wiki is formatting expressivity. Are you sure the wiki can produce robust enough content? How complex are the content’s tables? How are references between content objects handled? Can you mix portrait and landscape oriented flows in a given portion of the document? Etc.

          • Shelley

            Actually, Paul, you can combine multiple reviewers’ comments into a single document in Word, and it is significantly easier than it is in Acrobat. Also, comparison of comments is much easier in Word. Change tracking is one of the few areas where Microsoft is much superior to most other offerings.

            I have made no specific comments about Wiki authoring. However, I might suggest the you just take a quick look at the article in Wikipedia about “hypertext” to get some first-hand response to your comments.

            My only concern initially to Wiki authoring was that without adequate supervision, crowdsourcing has a considerable risk for inaccuracy, poor literacy, and very sloppy appearance. With adequate professional TC review, all these objections disappear.

  • Tom Aldous


    You know I am reading and learning as much as possible about how we can improve FM moving forward. I am and always have been the customer and partner advocate. There are some great suggestions that we can use here.


    • Thanks, Tom. I know that my readers are really hoping you are paying attention. The fact that Adobe hired you (and that you accepted the challenge!) gives many people hope for the future of the product.

  • Annjackson22

    Adobe has screwed its customers with terrible pricing policies as well as all the other issues.  Don’t upgrade Frame for two releases, and you pay essentially full price.  How does that keep customers?  And what about that big waste of money that Adobe made such a big deal about, the Tech Comm Suite?  We tried it, and have abandoned it.  I love Framemaker for all documents.  But we end up using Word more than Frame largely because there are so many features of Word that make reviewing easy.  Now we’re converting to XML and using Frame as our temporary XML editor.  But because Frame is not standard in all the ways you mention, I know we won’t continue with Frame unless Frame 11 is massively upgraded.

  • Peter Dykstra

    These days, for me at least, the major disadvantage of Frame and most of the other desktop
    XML tools is that they are single-user tools in a
    multi-user world. 

    I’ve been producing tech doc for over 30 years and managed tech writers using Frame for most of them.  In my experience, even with its outmoded UI, Frame is still an unparallelled tool for a lone writer creating and editing long documents with complex formatting, putting out beautiful pdfs, and, with WebWorks, able to managing large libraries of fully indexed online help.  I often hear the structured vs. unstructured argument as if documents are either structured or unstructured, when in fact this is entirely a matter of degree. Every document has a structure. The question is which structure to use and why. 

    For example our group of 20+ writers in four locations used “unstructured” Framemaker to create and manage topic-based libraries with thousands of topics; we achieved consistent structure by following a style guide and by simply adding a Frame heading style called “topic heading,”  to start a new page in PDFs and trigger each new Help topic in WebWorks.  We considered using XML editors and decided that the overhead of paragraph-level tag enforcement did not really help us produce better documents and actually was a distraction. Flare sounded great but forced writers to write each topic as a separate file and having to manage many short files.  Frame let us we could build out a set of related topics in a single document and mark topics by applying a paragraph style, almost as simple to use as Word, only much more stable and robust.

    However many of us are not lone writers.  I think that’s one reason a Confluence user in this stream “never looked back.”  My own experience is with an open source Web-based content management system called Daisy.  With status-based permissions and a few usage guidelines, Daisy enables SMEs, writers, editors, and reviewers to work on the same files with none of the need to convert and traffic files back and forth multiple times on every release cycle.  Users can access Daisy directly to see published topics online, or Daisy can be used to publish pdf books.  Since they are XML with a little more work Daisy documents can by published as standalone Help, or even converted to Word or Frame for downstream reuse.

    One size doesn’t fit all.  For example lately I hear more success stories about DITA XML. On the other hand I also hear more about the cost and complexity of managing DITA-based documents, and cases where editors that enforce paragraph-level tagging are overkill  On the other hand I also hear more stories of groups moving to free or low-cost Wiki-style systems and finding them powerful, easy to use, and well-suited for publishing topic-based document sets on tight schedules.  I am sure these are not for everyone, but they seem to hit a sweet spot for many groups that once would have been strong candidates for Framemaker.


  • Megmiranda

    Follow the doc team budget money. Many doc teams report directly to Engineering managers.  Many of those folks look at FrameMaker and see Microsoft Word, so they don’t understand why it costs what it does.  When they look at an XML editor, they feel comfortable and understand where their money is going. XML and building customized doc schemas and scripts to convert to multiple outputs means jobs for programmer types with personalities that the Engineering managers understand. At the same time, team XML was pushing that technology hard at doc conferences and through certification programs.

    I’ve authored in DITA, DOCBOOK, and unstructured FrameMaker. I prefer unstructured FrameMaker, but really don’t care.  If you think about your content in the same way, the tool is only a means to the same end. 

  • If there is anything in the world that is unstructured, it’s the use of Wikis and so-called ‘collaborative authoring.’ How do you do version control? How do you do conditionalizing? Variables? How do you ensure this using raw XML editing? What a shame that this is happening. 

    • Peter Dykstra

      Richard: I’ve worked in both unstructured and structured Wiki environments. The unstructured environment I’m thinking of was a sprawling mess. What I’m calling the “structured” environment had (controlled) collaborative writing and editing, version control, conditionalizing on steroids (compared to FrameMaker), with single sourcing across product families, product releases, and multiple languages and support for variables.  The difference was twofold: how each environment was managed, and which Wiki tool was used. The structured Wiki environment was managed by the tech pubs group with editorial expertise, stylesheets, editing roles and permissions, and explicit editing processes.  High end Wiki tools are quite sophisticated content management systems.  A Wiki environment does not have to be a free-for-all.  

    • Shelley

      Wiki right now is the ONLY pure form of collaborative authoring. NO overhead, everyone writes what is necessary to answer readers’ questions, and there is nothing between the SMEs and the Users. There are no cumbersome software protocols, no BS rules imposed by lousy software design, and nothing to prevent ALL the information from reaching the final audience.

      Now, let’s talk about control and structure. What we need is moderators… people who know about things like organization and grammar… people who think about version control… and maybe even people who can verify authenticity and technical correctness. That is what WE get paid for.

      I for one am looking lots more favorably on tools that EVERYONE can use and not just those few of us who happen to be trained gurus on one particular brand or flavor of text (or even online) editor. If you really want to have the people who know the information contribute to the authoring process, you must give them the ability to do it. In fact, the reason Word is more popular than FrameMaker is because Word does just that…. everybody can use it.

      The question is not structured or unstructured, it is how can we integrate a management process into the free contribution of anyone who can provide the information. The best example of this freewheeling information exchange is still Wikipedia. Here we are talking about hundreds of thousands of contributors supplying millions of factoids in thousands of categories. TELL ME ONE OTHER PRODUCT THAT CAN DO THAT???

    • michael o’neill

      Hi Richard!

      I think that it’s a shame when wiki authoring is forced into the wrong environment. Certainly, if the features you mention are the lifeblood that makes your docs successful, then I’d be hard pressed to advocate for wiki adoption.  It is worth noting, however, that in many environments the cost of maintaining a knowledge silo is simply not worth it.  Again, not right for every environment, but neither is a heavy documentation production process that only a few people can use.

  • I think that Val is right on the money (along with Scott) in pointing
    out where Adobe has dropped the ball, and also where there is immense
    opportunity for synergy. 

    I’ve been working as a TW/TC/Etc. since 1990, and have used probably every authoring package out there at one point or another.  I still prefer FM for most Technical Writing, and MS Word for Business Writing (FM and mail-merge never really got along… ). Pretty much every package had at least one feature that I wished others would have.  As a contractor, I’m working with FM->RH for one client, and purely in MadCap Flare for another.  I’ll work in Word if I have to for TW pieces, but I know never to trust it. Usually I’ll do the doc in FM and then port it for delivery.  

    In talking about the various applications out there, I often compare FM
    to a diesel engine. Solid, reliable, and even perhaps boring.  But it
    will let you climb any hill and haul pretty much any load. FM seldom
    surprises you, and that’s a *good* thing. But as folks (Jeff, “WritingSolutions2010”, others) have pointed out, FM is getting long in the tooth, with a lot of legacy code that begs to be updated. (TOM— I’d also point out that most of the “graphics” that are bundled
    in FM date from around 1990-1991— and were somewhat outdated even
    then!)  Not to mention functionality that has been missing (real kerning, for example), and an inability to produce much of the “oooh! Sparkly!” material currently in favor. Or even the rational output of EPUB/Kindle/Rocket/Nook-ready output

    My ideal product would probably be some mashup of FM, Ventura Publisher, and InDesign, with the database-driven backend of Author-It. The missing piece is a way to architect documents as blocks (something like Visio, perhaps?)

    On the other hand, perhaps the answer is not to stuff everything into one box, but instead, break it all apart, and then let people assemble modules to create the content-creation stream that works for them. FM is a great text editor, and not a bad book-builder, but it’s not web-ready, let alone any multimedia.

    OK. Somebody else’s turn on the soapbox!

    • Grant. I hear you! And, I would like to add to that wish-list, the ability to submit eBook formatted content to eBook superstores (iBookStore, iTunes, Amazon) from within the application (like submitting content to a CMS from within FrameMaker — as well as integration with an “app” development tool. These are just a few of the features I’d like to see. I yearn for a day when a software maker makes me drool over a technical communication tool. 

  • Mysti Berry

    I don’t think Adobe ever had a good solution. FrameMaker is a propietary format, and therefore doomed, sooner or later. Word is just going to take longer to die, it’s doomed too, at the enterprise level, anyway.

    • michael o’neill

      I recently (within the last 1-3 months) read of a business owner who banished MS Word in favor of a wiki at his company.  If it was something being sent internally, it went on the wiki.  If it was something that went external, he used the Word or PDF export from the wiki.  Was interesting. I’d like to follow up and see how it’s working out for him and his firm.

      • This is actually how documentation is created in an increasing number of companies. Unfortunately, even in these companies Word and a mishmash of other tools are also used. It’s not unfortunate the other tools are used, actually. They are being used because the are the right tools for the job, oftentimes. The unfortunate thing is that no one has yet designed a product to meet all of our authoring needs. It’s not just what the tools can produce, but how they do it, how attractive they are to users, and so much more. 

        • Shelley

          I wonder at the term “mishmash of other tools…” Every profession has a SET of tools to do its work. Surgeons don’t have one scalpel, they have many, one for each particular cutting requirement. Carpenters don’t have just one hammer or one saw; they have several to do different kinds of hammering and cutting.

          Why does anyone think that one tool is all a Technical Communicator needs to create meaningful, comprehensive, and complete documentation. Word has its place in our profession, just as FrameMaker, and Flare, and Wiki, and maybe dozens of other products that meet each persons needs and preferences.

          One size does not fit all. Diversity is good for everyone. Competition among products makes every product better, and makes our jobs much much easier in the long run. Understanding — and even converting from one tool to another — is our job; that is what we get paid for.

    • Shelley


      Word will never die. Grandma still wants to put her recipes in the computer, and every college student writes home to ask for more money. Some text editor will always be around, and Word comes with every PC computer and laptop that has Windows.

      • michael o’neill

        > …Word comes with every PC computer and laptop that has Windows

        Is that now the case? I thought you had to purchase it separately still.  (The first thing I usually do if I buy a computer with Windows on it is remove it.)

        • Shelley

          Word used to be 100% free on every computer with Windows, but in the last few years, Microsoft installs a “trial” version that lasts for 30 days (I think — it may be longer). After that, you need to buy at least the cheapest version to even start it up.

        • Michael: And, if it were a physical product, once it was removed, I would jump up and down on it until it was totally dead, then boot it out the door.

  • Ed Rush

    Best would be if Adobe would spin it off — recreate Frame Technology. It might be too late, though, for the reasons so excellently described above. I began using FrameMaker with version 1, got the Mac version 2, and continue to think it is far and away the best tool for structured documentation. 

  • Davlynj

    Thanks, Val for bringing up the subject of FrameMaker and
    including me in your comment list. 
    I have read all the comments and agree with most all of them. 

    The Question, Hamlet, is why has FrameMaker appeared to have
    bit the bullet, passed on, died a slow, untidy death.  Well, maybe it is short of a funeral and a wake; but IMHO –
    Frame is dying; but not yet dead.  Will
    there be CPR?  Recovery?  Resurrection?  Only the Adobe gods can know.

    As a long time user of FrameMaker, both on the PC and the
    Mac, most recently with Frame 10 on a MacPro laptop with Mac OS Lion and
    Parallel/Windows 7, I was disappointed in its current incarnation.  It seemed cumbersome, awkward,
    repetitious and tedious.  And on a
    laptop screen, it was difficult to see, let alone read and use as a processing

    Maybe that was the fault of Windows.  I am unabashedly a Mac person.  I was enraged that Adobe did not stay
    with the Mac platform all those years ago. 

    I am also puzzled by Windows, after all this time, not
    allowing two or three application files to be onscreen simultaneously, side by
    side, so I can see them and work them as I easily do on the Mac side.  I hate going in and out of Frame,
    Visio, and Word applications, finding the files, then my place in the files, then
    cutting or pasting text or graphics, and repeating and repeating it all, ad
    nauseum.  And tables?  That’s a mess.  But that’s just me.  I like to Option Key – drag and drop
    between application files sitting side by side on my screen.  Why make it difficult?

    And today’s new Word? 
    Let’s not even go there. 
    Why did they “fix” what ain’t broke?  It is simply terrible. 
    It should be trashed as a non-useable tool for writers.  I hate it when Microsoft wants to think
    for me.  So bad, and I started with
    Word when it was version 1.07 for the Mac only.  I could make it sing, but not anymore.

    I agree that FrameMaker is still working on the antiquated
    Windows system, and is hampered in functionality by it.  But I also believe that is not the real
    issue with documentation and Frame. 

    Hasn’t anyone noticed that the folks of today are more
    visually oriented?  They don’t want
    a set of books with its own gift dolly to tote them into the room.  They don’t even want a 3 x 5 card
    written summation and they don’t want language or lexicography barriers.  They want a single, colorful picture
    that tells it all.   And they
    want that picture to be interactive.

    When I started in this field, back when we were still in IBM
    cold rooms, (Yes, Gridley, I am that
    old.), we had a motto:  We write for the reluctant reader. 

    Today I would paraphrase that motto to be:  We write information for random
    inquiries followed by links to intranet and internet websites that contain photos,
    videos, animated cartoons, color-coordinated slides, Online Help systems, design
    graphics, designer fonts, and flow charts that explain things simply and visually;  much of it to a colorful and musical

    When I write today, I visualize an overscheduled Lady Gaga
    or hip-hop fan completing a task that is new to them.  The task has a 3-step procedure that is shown visually on a
    flow chart or clever graphic with numerous links to deeper detailed graphic
    explanations and descriptions.  And
    all of it accessed through tapping fingers on a mobile device screen display on
    an iPhone4S, an iPad and a Kindle Fire – all of which I – and today’s User – have,
    use and own. 

    If a book of written explanations and descriptions is
    required, you can call it up and read it on your mobile device of choice screen
    display.  Or you can access it
    through Google docs.  Or download
    it from the iCloud to your computer. 
    And all the multi-purpose variations in between.

    The point I believe, is that the times they are forever a-changein’.  And FrameMaker should change to meet
    the new user – today’s content writer AND reader.  FrameMaker should be a tool that is Intuitive, Visual and Simple
    to use.  It should be flexible and
    useful on more than one platform.  It
    should give the writer a visual menu of uses and be linkable, easy to follow be
    they novice or expert.  It should
    give the reader what is needed and get out of the way.  Today, FrameMaker is not any of those

    Sigh.  Perhaps a
    funeral should be scheduled.

    • You have stated this so eloquently – thank you! I could not agree with you more. You are absolutely spot-on in every way.

      In response to this blog post, and the stir it has created, Adobe invited me to do a webinar with them. Tom Aldous and I will be discussing FrameMaker, and I will have an opportunity to ask Tom some questions. If there was one thing you’d like me to ask him, what would that be? I can’t promise it will make the list, but I’d love to hear from you (and anyone else participating in the conversation).

      The webinar is on December 14th at 10:00Am Pacific Time. Here is the link to register:


      I look forward to hearing from you and thanks for your comment!

      • I look forward to this!  I’m an author embarking on a 4th edition of my book.  I haven’t used FM since the last edition and am struggling now with the question as to whether to upgrade to FM10 or port the whole thing into InDesign, at 1/2 the cost.  I think I’m running about 10% of FM’s power–I just need to make a nice PDF for print and for conversion into Kindle format.  Thanks for initiating this discussion!

  • Eddie VanArsdall

    I am a long-time tech writer in the Washington, DC area. Government contracts dominate our market, and MS Word is the standard for most government agencies. For years I thought I would never have an opportunity to use FrameMaker, and then I landed a succession of FrameMaker-only contracts lasting for five years. I ended up developing and maintaining Frame templates for the National Cancer Institute.

    I share many writers’ admiration for FrameMaker. It raised the bar for tech writing tools and gave us many robust features that we’ve come to rely on. Frame is a real workhorse, and I always found it reliable for what it does best: books to PDF. At the same time, I found it limiting when I needed to publish to HTML. Using separate tools to complete the workflow was time-consuming and expensive. 

    I believe that one of the worst things to happen to Frame was that it fell into the hands of Adobe. As you and others have pointed out, they dropped the Mac version and let the Windows version languish for years. To its credit, Frame still performed well, but once it became part of the Technical Communication Suite, the UI became messy and bloated. Now we are expected to buy four tools instead of two.

    These days I work mostly with online content (Drupal, Alfresco, wikis), but for  writing projects, I use MadCap Flare. I find that Flare matches and extends Frame’s best features, including conditional text, variables, snippets (similar to text insets), and customizable cross-references. Page layouts were introduced in 2008, and Flare’s PDF engine has steadily improved to the point where I can set up and produce double-sided, multi-sectioned books. I have done a number of Frame-to-Flare conversions and will be delivering a webinar comparing the two tools on February 7, 2012.

    And no, I don’t work for MadCap. My relationship with the company has grown from my admiration for their products and my relentless suggestions for improvement, all of which they have taken seriously. While Flare is part of a suite of tools (MadPak), it works well as a standalone solution for publishing to both print and the web. I reviewed the current version at http://www.contentinsomnia.net/streamlining-your-workflow-with-flare-7/ .

  • Cayenne

    I’ve just read this entire thread with interest, and am curious about what’s not being said… While I know it’s a discussion about FrameMaker, and many have outlined specific reasons for its alleged demise, I propose that the job has changed such that it’s no longer the right tool in some ways.
    I’ve been a technical writer for about 13 years, and came in on the wave of high use of technology and newer companies or startups. The few times I’ve used FrameMaker, it was with companies that had been around for a while, and doc departments used to publishing books as the main documentation, and doc mangers who had been in their jobs for a long time and hadn’t necessarily kept up with current trends.

    The emphasis and thinking around books is extremely linear, and the nature of how we view, use, and deliver information has changed radically from the linear. Single-source, reuse, and separating content from presentation are key to delivering information – not documents – in this more usable way.

    The conversation about whether or not an organization _needs_ structured content can be put back a step to ask why not? There are many more options with structured content, and it might be useful to look at what those are, and whether they could be useful now or down the road.

    I can’t imagine a more painful conversion than importing Word to FrameMaker, as you still end up with the same content in the same form – as folks here have said, basically a text editor.

    I’ve led or performed single-handedly quite a few change management projects to either implement new systems or convert from Frame/Word or other tools/systems into single-source documentation. I have repeatedly chosen Author-it when it was up to me, as it often was. I recently chose Madcap Flare instead, and regretted it.
    Flare seems to be more in use in this country, but having used Author-it for many years in Europe I found it to have some pretty serious drawbacks. Conditions is one of the largest blocks – you can only set one condition on something, and I had to use them to NOT publish topics. Publishing to html, Flare publishes everything in the library – so searches turn up draft topics, note topics, and topics on separate products. This is a major downfall, since I then can’t use conditions for any other purpose.
    Also, Flare provides five ways to do everything, but only one or two of them work. The Flare documentation (!?) does not provide best-practice suggestions, but instead docs each detail in the interface, usually in exactly the same language used in the dialogs.
    It does publish to PDF, but keep with next randomness and other
    problems meant it took a long time to see where all the issues were
    coming from, as was the case with many problems. And there were print
    output issues that were considerable and could not be solved.
    The Word/text imports were never correct, did not allow much control over style and format conversions, and required a LOT of work to get them right. Fortunately, in this company there was not a lot of existing content to import.

    I don’t work for Author-it, but am curious why it’s not more in use in the US. It is expensive, but maybe folks don’t know the possibilities. I’ve converted thousands of pages of Word and Frame docs into Author-it and out again in a shorter time than possible with any other tool I’ve used. I’ve also set it up and done minimal training to non-writers and non-techies to be able to make small changes as needed. The imports were generally very good, and I have a lot of control over how to translate the styles and formatting in the original docs.

    As to the need for what someone calls “back and forth” and what I call “round-tripping”, this is one way to allow updates/commentary/participation, and it works well in Author-it. I could publish any group of topics to Word, give the doc to a developer or SME, and then re-import and overwrite the original with the new doc, editing it as necessary.

    There are other tools that are much less expensive that would work for smaller companies, or those not sure of their direction, and make it easier to change course later. But a simple interface, ease of rearranging content, and setting parameters for output inside the system is a lot more useful than using multiple systems and complex configurations for publishing. If you have the content chunked appropriately, your options are expanded considerably. And Frame does lines, not chunks, in mnsho.

    • Mike Barnes

      This is an interesting thread indeed. 

      I was a long time FrameMaker user and have switched completely over to Flare for my projects (we create PDF manuals and online Help).  I found that there was a learning curve since it is different than FrameMaker, but that didn’t make it difficult to use.  Overall I am extremely happy with Flare, and the responsiveness from both the MadCap sales team and technical support is second to none.

      Cayenne has pointed out a few issues in Flare that I am not familiar with, or do not understand… I’m assuming they were using an older version (I’m using v7).  I have hundreds of conditions in my projects and I have things conditioned several times, from segments to elements to files.  I can get beautiful PDFs from Flare and when outputting to HTML, I can select to exclude output files that are not used in my target.  Plus, each new release of Flare continues to impress me.  They seem to do a good job of listening to their users.

  • Pingback: What are Your Best Practices for Preparing Content for Translation? | Content Rules, Inc. (formerly Oak Hill Corporation)()

  • Catherine Caldwell-Harris

    I love framemaker for my scientific writing but had to give it up when it was no longer supported on macs.  I now want to revise an old, unpublished, back-burned document — but need to get it out of framemaker and into word, rtf, html or even pdf.  Would anyone be willing to convert two small-sized files of mine?  Email charris@bu.edu

  • Pingback: FrameMaker Redux | Content Rules, Inc.()

Get the Scoop

our monthly dose of compelling content delivered to your inbox

strategy | development | globalization writing | terminology | XML | ebooks


Free eBook

The Five Phases of the Translation Workflow

Learn how to avoid common pitfalls and streamline the workflow of translating your content. Download this free ebook to save time and money, while improving the quality of your content in all languages.

Success! An email has been sent to you with your ebook.

The Five Phases of the Translation Workflow - Free eBook

The Five Phases of the Translation Workflow - Free eBook

Learn how to avoid common pitfalls and streamline the workflow of translating your content. Download this free ebook to save time and money, while improving the quality of your content in all languages.

Success! You should receive an email shortly with a link to your ebook.