TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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 -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.
