<div dir="ltr">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.<br><br>First, your repeated list of tasks:<br>
<ol><li>Changing conditional tags for appropriate product edition and then updating changes in all files - 3 minutes</li><li>hiding or showing certain FM files - 1 minute</li><li>updating variables for appropriate product edition and then updating changes in all files - 3 minutes</li><li>check to make sure PDF options are set correctly - 3 minutes</li><li>update book - 1 minute</li><li>print
pdf through acrobat distiller - 10 minutes (low end...can be as long
as 20 minutes for large books but i am being charitable)</li><li>Post processing steps -- change the PDF filename, switch the PDF title to show bookmark, commit PDF into SVN etc -- 5 minutes</li></ol><p>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. </p><p>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.</p><p>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.<br></p>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. <br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>CONCLUSION:<br>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. <br><br>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.<br><br>Cheers (and I hope this is taken in the spirit it's offered) cud<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><div><div><div><div><br><div><br></div><div><br></div><div><br></div>
<div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<i><br></i></blockquote></div></div></div></div></div></div>
</blockquote></div>