atw: Re: Arbortext Epic with Style compared with Structured FrameMaker

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: