Part 1: Why I am Dropping TCS and FrameMaker

[cud]

Ok, this is a long-winded post, so my reply might be long-winded in 
return.  I'll try not to.  I want to play devil's advocate here, and argue 
a few of the points you made.  You have every right to make your decision, 
and I'm sure there are lots of other issues.  But I can point to a couple 
of them right now.

First, your repeated list of tasks:

   1. Changing conditional tags for appropriate product edition and then 
   updating changes in all files - 3 minutes
   2. hiding or showing certain FM files  - 1 minute
   3. updating variables for appropriate product edition and then updating 
   changes in all files - 3 minutes
   4. check to make sure PDF  options are set correctly - 3 minutes
   5. update book - 1 minute
   6. print pdf through acrobat distiller  - 10 minutes (low end...can be 
   as long as 20 minutes for large books but i am being charitable)
   7. Post processing steps -- change the PDF filename, switch the PDF 
   title to show bookmark, commit PDF into SVN etc -- 5 minutes

I think you overestimate the cost for automating this.  ExtendScript could 
do this pretty easily, so you would not have an SPOF in that instance.  I'm 
an FDK programmer, and I can tell you that it's no more than 8 hours to set 
this up.  It's all very straight forward -- no big decisions, no hairy 
dependencies.  Did you ask around for the cost of automating a batch to do 
this?  I've worked at a number of places that do exactly that.  

BOOK == PDF -- I don't know what you mean there.  I think that is simply 
not true unless you qualify it to read "In our workflow BOOK == PDF."  I 
worked in an organization that automated book preparation, conversion of 
book to HTML, and generation of a PDF for every chapter in the book to ship 
as the "printable" version of each help section.  This limiting of book to 
PDF file is strictly your choice.

PFDs IN GENERAL -- I understand...  You want to get away from PDFs and get 
to something more modern, more open to search, etc.  Again, you can 
implement WebWorks to generate perfectly good HTML versions of your books.  
Or you can do as I did, and convert to DITA -- then use any number of tools 
to generate your help output, plus PDFs, or pretty much anything else you 
could want.  My recommendation is to bite the bullet and switch to DITA 
sooner than later, because to future-proof your content I believe you will 
ultimately have to make that move.
CLUNKY GUI -- By principle I reject this issue.  In that I'm a Luddite, I 
guess.  For me the only issue is whether the paradigm and work flow are 
suitable.  Yes, Maker can be vastly improved there.  But so can every other 
authoring product on the market.  Bits and bobs like icon colors, menu 
customization, and the like do not interest me in the least.  If the GUI 
actually gets in the way, then you have an issue but I maintain that Maker 
is no worse on that count than any other product -- just that the problems 
show up in different areas.  

ADMINISTRATIVE HURDLES -- Again, that can all be automated.  I created a 
Maker plug-in that centrally manages templates, for example.  If you're 
careful about your template maintenance you don't even need that and can 
devise an easy workflow that you can automate via ExtendScript.  Likewise 
with the other issues you mentioned.  For example, I made a number of 
cleanup plug-ins for free because they're that simple to do.

SOURCE IN BINARY -- Get thee to DITA.  HTML is not a suitable source in the 
end, because it captures too little of structure and semantics.  What other 
binary format are you considering -- TeX?  I work in DITA, and use SVN.  A 
vast improvement for me.

CRASHING -- Yes, that's a serious problem.  I can tell you that Maker 11 
addresses many of these issues.  Likewise for any ExtendScript crashes.  
Again, every product has its problems.  There is no such thing as bug-free 
software.

CHANGE MANAGEMENT -- This is a general problem.  I don't like any change 
tracking I have ever seen in any product -- more trouble to use than it's 
worth IMO.  On the brighter side, if you manage to go topic-based, then 
your changes come in per topic -- much easier to incorporate, much easier 
for SMEs to review, and so on.

CONCLUSION:
I really think your situation cries out for DITA.  Well, most definitely 
for XML.  I don't know whether Flare is the best way to get there.  But I 
think once you cross that hurdle most of your other problems will have 
obvious solutions.  You still have to implement a sophisticated search on 
your full collection of docs (I guess), but that's true no matter what.  
You still have to design a better process for review and collaboration, but 
that's true under all circumstances.  Collaboration is as much social 
engineering as anything else.  

Am I trying to talk you out of switching to Flare?  No Way!  I'm just 
trying to point out that there are lots of ways to skin this cat.  
FrameMaker may have steered you toward workflows that make you 
claustrophobic, but there are ways out of that without the cost of changing 
tools.  Maybe you have other compelling reasons, but for the issues above I 
think there are alternatives other than completely switching tools.

Cheers (and I hope this is taken in the spirit it's offered)               
cud
>
>
>
>
>
>  *
> *
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frameusers.com/pipermail/framers-frameusers.com/attachments/20131103/535a42fe/attachment.htm>