Re: Future of FrameMaker: InDesign? [Long]

Subject: Re: Future of FrameMaker: InDesign? [Long]
From: Dan Emory <danemory -at- primenet -dot- com>
To: "Rick Quatro" <rick -at- frameexpert -dot- com>
Date: Sun, 02 Jul 2000 11:20:13 -0700

This thread originated on the Free Framers list. My reply is being cross-posted to the FrameSGML and TECHWR-L lists.
============================================================================ =====

All of your points are well-taken.

Almost certainly, V6.0 represents the end of Frame product development. There was a 4-year gap between V5.0 and V6.0. V5.5 was basically a bug-release that initially introduced more bugs than it fixed. The main investment in 5.5 was the addition of double-byte, which was a marketing ploy intended to increase penetration in the Asian (particularly Japanese) market, combined with the fold-in of Hot Tamale (a product Adobe bought), which was so weak that it's only useful purpose was to give Adobe salespeople an HTML demo capability. Almost everyone with a serious HTML requirement immediately bought WWP.

What Adobe successfully did was to use the huge installed base in North America and Europe (which got little benefit from double-byte) to finance the development of that feature through upgrade payments and new license purchases. But the 5.5 bug fiasco also demonstrated to Adobe that, having lost most of the key people from
Frame Technology, it was unable to successfully maintain and upgrade the Frame product line.

Given that history, only the deluded are waiting for the next release. The rest of the installed base is (or should be) evaluating whether it's possible for FrameMaker and FM+SGML to remain viable for some years to come through the use of scripting and third-party product development. But as you pointed out, Rick, there are limitations on what can be done along that path. At the same time, the large undeluded segment of the installed base is considering other options: What are the possible replacements for FrameMaker, and how soon must we act?

As I mentioned in an earlier post, large license holders with huge libraries of legacy Frame documents must consider the likelihood that, if they switch to some other DTP, the cost of converting those legacy documents will be a painful and prohibitively expensive process. Which propels them to the realization that, if they're probably going to have to switch anyway, they'd better switch now, otherwise they're just going to add to the problem by continuing to produce more Frame documents that will also have to be converted downstream to the new DTP.

Those companies that are already using FM+SGML have less of a dilemma, because they already have a guaranteed migration path to any SGML/XML-aware author/editor product.

Let me add here that the use of WWP to produce XML from unstructured Frame docs is not an acceptable solution for the following reasons:
1. Multi-level structures are not possible.
2. Attributes can neither be defined nor exported.

Rick, You've suggested that InDesign might eventually evolve into something that includes the best long-document features of FrameMaker. I'm quite skeptical this will ever happen, but if it that's what Adobe intends, it must very shortly announce that it is committed to providing a MIF-to-InDesign converter that will produce near-perfect replication of legacy Frame documents if it expects to hold onto to the FrameMaker installed base. Moreover, it is extremely unlikely that InDesign will ever be capable of importing or exporting SGML or XML. Such a capability would have to preserve attributes and multi-level structure on both import and export, and, in the case of XML, preserve the formatting contained in XSL style sheets on both import and export.

I don't think InDesign will ever be the answer.

Another possibility is for companies to upgrade all their FrameMaker licenses to FM+SGML now, allowing them to create all their new documents as structured ones which can be exported to SGML or XML. This, at least, would stop any further additions to the pile of unstructured Frame legacy documents, and the Structure Rules method of converting unstructured legacy docs to structured ones might be a feasible migration path. But the investments in licenses, development of EDDs, DTDs, import/export applications, and APIs, as well as retraining, are likely to be huge. Experience has shown that the Return on Investment of such activities is high, but it still takes at least 2-4 years to recover the investment. It would be difficult to justify such an investment, however, if FM+SGML is facing the same fate as FrameMaker, or if no capability to import XML is added to FM+SGML, then the whole process would have to be repeated after selecting a suitable SGML/XML-aware, WYSIWYG author/editor to replace FM+SGML.

I invite your comments, and, like Rick Quatro, I'd like to know of any other viable options.
| Nullius in Verba |
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.

Previous by Author: What Happens When Temps Organize
Next by Author: Re: New TECHWR-L Poll Question
Previous by Thread: Re: Interviews From Heck
Next by Thread: RE: Future of FrameMaker: InDesign? [Long]

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads