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.