atw: Re: Arbortext Epic with Style compared with Structured FrameMaker
- From: "melanie.kendell" <melanie.kendell@xxxxxxxxxxx>
- To: hedley.finger@xxxxxxxx
- Date: Tue, 1 Mar 2005 11:58:29 +1100
hedley wrote:
> 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...choosing which one to go with should depend on
> other than transitory migration issues.
One of the beauties of XML is that, being a standard format, you can switch
editor as your requirements change.
I have not used Epic but have been watching their development and they seem to
be doing some of the right things (although, as some others have mentioned, at
a rather high licence and setup cost).
I have, on the other hand, built EDD/DTD for SFM and have been happy with the
result.
The most important thing, rather than which editor to use, is to create your
schema.
Rather than making a final decision now, I would use FM (the tool that you
already have, and that you have familiarity with) to help you come up with the
schema and convert the content to XML (getting help from a consultant at this
stage is also well worth the money - <blatant plug>).
After that you can reassess your requirements and you will be in a better
position to evaluate other editors.
As to your specific questions:
> Migrating legacy unstructured FrameMaker
> Tools and aids in either environment
> Difficulty in migrating legacy content -- quality of
> migration aids
Your existing unstructured FM files will, in conjunction with its reasonably
good conversion tools, help you work out your schema, so I'd say this is a plus
for FM.
> 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
FM licence is not horrendously expensive, plug-ins are typically not expensive
and are contributed by more than just the single company.
> Designing templates -- DTDs or schemas, stylesheets, workflows
> Capabilities of design tools -- graphical views v. text
I'm sure there are better tools for creating schemas but FM is OK for this.
FM obviously has heaps of advantages in the stylesheets area due to its
publishing background.
Not sure what you mean by workflows - I thought we were talking about editors
:). With workflows we start getting into the territory of content management
systems (which is probably going to be your next concern but can wait 'til
later).
> Authoring environment
> Structure view, ease of restructuring, guided editing
Yes FM is good for all of these.
> Find and replace with reg exps
I would highly recommend the FrameSLT plug-in from West Street Consulting
(www.weststreetconsulting.com) for increasing FM's capabilities in this area
(it will also give you a taste of what XSL can do).
> Multiple dictionaries
Yes for FM.
> Error checking and project management
Error checking is pretty good and not too restrictive (some editors will not
allow structure to ever be invalid which can cause problems - FM does not do
this). Again, I'm not sure what you mean by project management, and again, I
would expect this to be handled by a content management system.
> 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
Even though FM has conditional text, it is too limited to be of use (eg, as you
have obviously worked out, ORing and overlapped conditions are not feasible) so
you would have to use a more native XML-type of conditioned content. Again I
would recommend FrameSLT to assist with managing this (or, if you are heading
in that direction and can wait until it's implemented, full content management)
but more importantly you need to get your schema right to make this work
effectively.
> 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
FM wins hands down for me with regard to printed documentation (which includes
PDF) and you have some targeted tools for producing online help, HTML, etc
(although the demise of RoboHelp for Frame was a bit of a blow - we're using it
but it would have been nice to recommend it to others).
> 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
One advantage of FM is the ability to combine structured and unstructured
chapters in a book - eg, we have a catalogue where the body is structured, but
the front and back fluffy stuff is not structured and I didn't have to come up
with a schema for it (the ROI of building such a schema for single use stuff is
negligible).
There are content management systems that will "burst" SFM files into XML
topics to allow you to build publications from components according to your
needs (eg SiberSafe from SiberLogic - www.siberlogic.com).
> Raindrops on roses, And warm woollen mittens
> What's best and worst about Structured FrameMaker?
Best:
* Familiar enough environment for authoring and publication (and therefore able
to draw on pool of people)
* Built-in tools to assist with creating schema and converting docs to that
schema
* Ability to work with both structured and unstructured content
* Good stepping-stone for everyone to ramp up to getting their head around
structured content
and number 1 best feature:
* At no stage in the project are you left not being able to publish because
your XSLT isn't working
Worst:
* Probably not the best long-term solution unless Adobe wake up to what they've
got and put some serious resources into SFM (I don't see this as a problem,
because of the portability of XML, but it is a shame)
* There are some inconsistencies between SFM and XML that you need to bear in
mind so that the XML will still work when you get that far
> What's best and worst about Epic with Styler?
> Any major gotchas to be wary of, e.g. Unicode support?
Can't comment on this unfortunately, but I would also say that if you move on
from FM, Epic is not your only choice.
-Melanie
**************************************************
To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx
To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.
To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with
"unsubscribe" in the Subject field.
To search the austechwriter archives, go to
www.freelists.org/archives/austechwriter
To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
Other related posts:
