RE: [FrameSGML] Arbortext Epic with Style compared with Structured FrameMaker

["Steve Schwedland" <steve@xxxxxxxxxxxxxx>]

Hedley,

I have been working with Structured FrameMaker/FrameMaker+SGML for about 8
years now, setting up systems to both author/edit content and publish
finished documents in an XML workflow.  It is my opinion that there is no
better PUBLISHING solution, dollar for dollar, than FrameMaker.  However, I
do not generally recommend Frame as an authoring/editing front end.  There
are basically two reasons for this:

	1. One of the benefits, from a productivity standpoint, of an XML
workflow is that the author is not directly responsible for the formatting
of a document at the time of content creation.  He simply does not have
reason to concern himself with that and therefore is freed up to simply
create content.  An editing tool like Epic is perfect for this step in the
process.  FrameMaker, on the other hand, still allows the authors to play
around with the formatting of the documents.  Generally authors do this in a
way that is contrary to the goal of the XML process, by using formatting
overrides (i.e. making a book title bold).  Once the file is saved out to
XML, all of the override information is lost, along with the reason for the
override.

	2. Translating some XML constructs, like tables, graphics and
cross-references, from XML elements to FrameMaker objects and back can
sometimes be problematic.  This, of course, depends greatly on the DTD being
used.  Usually, the more customized the DTD is to your specific content, the
more difficult it is to go back and forth.

Editing applications like Epic are perfectly suited to the content creation
step of an XML workflow because they do not allow authors to do things "the
wrong way".  That is, they force the author to tag a book title with an
element that denotes it as such, like <emphasis type="book title"> or simply
<book.title>.  How that element is formatted in the final document is not
for them to decide at that time.  Formatting decisions can easily change
over time and certainly will change depending on the delivery mode (print,
PDF, HTML, WML etc...).

FrameMaker is ideal for pushing your XML content out to print and PDF
formats, but is not ideal for Web delivery and is darn near useless for
wireless handheld delivery.  It is generally less trouble to set up a
Structured FrameMaker Application for print output when you already have
established FrameMaker templates.  Even without that it is not a daunting
task.

In most circumstances the company switching over to an XML workflow brings
in an outside contractor or consulting company to set the system up for
them.  Once the system is up and running, and everyone has been trained,
they step aside and you run with it.  The question then becomes one of
maintenance.  Using just the Read/Write rules and the EDD there is a lot of
flexibility that the end user can control when it comes to the final
publishing step.  This coupled with the use of a customized import client
(created by using the FDK) can be very powerful.  Using FOSI or XSF-FO based
publishing solutions makes it more difficult for the end user to control any
minor changes after the system is in place.

Overall, it is my opinion that FrameMaker as a publishing back-end is as
good as there is for most needs.  I have helped set up systems for clients
in many different fields of operations and have very rarely had any major
issues.  The last system I set up was for medical equipment user
documentation, delivered in 23 languages and we have had very little trouble
with the overall system.

I hope this help,

Steve




.==========================================================.
	Stephen L. Schwedland	steve@xxxxxxxxxxxxxx
	XML Publishing Specialist
	7951 Depew Street		phone: 303-412-5424
	Arvada, CO 80003		mobile: 303-921-5022
	USA				http://www.schwedland.com
.==========================================================. 

-----Original Message-----
From: hedley.finger@xxxxxxxx [mailto:hedley.finger@xxxxxxxx] 
Sent: Sunday, February 27, 2005 9:31 PM
To: Austechwriter Post; framers@xxxxxxxxx; framers@xxxxxxxxxxxxxx;
FrameSGML@xxxxxxxxxxxxxxx
Subject: [FrameSGML] Arbortext Epic with Style compared with Structured
FrameMaker



All:

We are considering moving away from (unstructured) FrameMaker to either (a)
Arbortext Epic with Styler (AES) or (b) Structured FrameMaker (SFM) for
single-sourcing printed user guides and on-line help.  We want XML to be the
native file format (SFM can be made to do this). XML is the only way to go
for reasons that are beyond the scope of this message.  We figure there is
about as much pain transitioning from FM to SFM as there is from FM to AES,
and that choosing which one to go with should depend on other than
transitory migration issues.

I am just starting on a detailed AES evaluation.  In the past I have used
Structured FrameMaker (back to when it was called FrameBuilder and
FrameMaker+SGML).  But I am by no means an XML/SGML or EDD guru, having
used SFM only as an author relying on a prebuilt DTD/EDD.  Has anybody else
faced a similar choice and can supply the reasons why they chose a
particular tool?  I am looking for war stories and potential gotchas in the
areas below.  How was your experience with these major areas?  [The subitems
are just to indicate the kinds of things that might be covered.]

Migrating legacy unstructured FrameMaker
      Tools and aids in either environment
      Difficulty in migrating legacy content -- quality of migration aids

Installing and implementing chosen solution
      Installation of clients, servers and licencing scheme
      Degree of integration, i.e. need lots of plugins for acceptable
functionality?
      Configuring installation, including user accounts or other access
requirements
      Total cost of ownership, viz. purchase, implementation and running
costs over five years

Designing templates -- DTDs or schemas, stylesheets, workflows
      Capabilities of design tools  -- graphical views v. text

Authoring environment
      Structure view, ease of restructuring, guided editing
      Find and replace with reg exps
      Multiple dictionaries
      Error checking and project management

Conditioned content (condition formats, profiles)
      Creating condition formats/profiles
      Applying conditioned formats/profiles, and visual indication
      Support for ORing and ANDing of overlapped conditions
      Hierarchical conditions

Generating output -- on-line help and printed documentation
      Ease of setup
      Supported help formats
      Setting up print and PDF output
      Ease of switching from one type of output to another

Content management
      'Book' control file for managing component files -- chapters,
appendices, TOCs, etc.
            (Actually, we would like granularity at the topic level)
      Alternative books with different combinations of components in
different sequences

Raindrops on roses, And warm woollen mittens
      What's best and worst about Structured FrameMaker?
      What's best and worst about Epic with Styler?
      Any major gotchas to be wary of, e.g. Unicode support?

Please reply to the list as no doubt others will be facing this decision in
the coming years as Adobe lets SFM languish in limbo.  I hope others may
find the results of this useful. (I have cross-posted to the FrameSGML,
Austechwriters, Techwr-l, framers@omsys, and framers@frameusers lists.)

[Windows 2000, FrameMaker 6.0p405, FrameScript 1.27C01, Enhance 2.03,
Acrobat 4.05.2, mif2go 31u33, WebWorks Publisher 7.0, IXgen 5.5.h, HTML Help
Workshop 4.74 build 8702.0, HTML Help 1.31]

Regards,
Hedley

--
Hedley Finger
MYOB Australia Pty Ltd  <http://www.myob.com.au>
P.O. box 371   Blackburn VIC 3130   Australia
12 Wesley Court   Tally Ho Business Park   East Burwood 3151   Australia
Tel. +61 3 9222 9992 x 7421  Fax. +61 3 9222 9880  Mob. +61 412 461 558
<mailto:hedley.finger@xxxxxxxx>



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/FrameSGML/

<*> To unsubscribe from this group, send an email to:
    FrameSGML-unsubscribe@xxxxxxxxxxxxxxx

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





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