Re: Future of FrameMaker: InDesign? [Long]

[Dan Emory <danemory@xxxxxxxxxxxx>]

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

All of your points are well-taken.

BACKGROUND
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.

IT'S DECISION TIME
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.

WHAT ARE THE OPTIONS?
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@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo@omsys.com with "subscribe framers" (no quotes) in the body.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **