<div dir="ltr">I had originally offered to share my story offline with anyone who is interested. However, the outpouring of interest (i think 30 or 40 people emailed me) and the urging of several to post this to the forum has changed my decision. So here it is.<div>

<br></div><div><div>For those on the FM list, I suspect the formatting in this email is going to get stripped out and make it hard to read. Just email me if you want a copy that's easier to read.</div><div><br></div>
<div>
Note that I am actually going to have three posts because of how long this will be. One that discusses why I am dropping FM and TCS, another about why I chose Flare, and then a final post that describes how I converted from FM to Flare. <br>

</div><div><div><br></div><div>Before I proceed, I should note that everything  I am expressing here are my own opinions and experiences. This is based on my use case and what worked for me. Some or all of what I have written may not apply to you or your work situation. I don't want anyone to think that I am criticizing their choices. I am not passing judgment on you and how you do technical communication. I am just sharing my story because I think it may help some people with their work.</div>

<div><div><br></div><div>To summarize what I am going to talk about (because I am afraid this will be quite long):</div><div><ul><li>My Business Case</li><li>Why FM failed to meet that Business Case </li><li>Why Not RoboHelp?</li>

</ul><div><br></div><div><b>SECTION 1: Business Case</b> </div><div><br></div><div>When you have a reasonably large documentation set (approximately 50 pdfs and 3,000 pages), changing the tool you use and how you and your team author content is an expensive decision, especially in the short term.  Off the top of my head:</div>


<div><ul><li>the up front conversion cost is going to be at least 160 hours (1 month) or more of work even with automation tools. In all honesty, if you aren't budgeting for at least one person to work full time on conversion for 4 to 6 weeks, then you aren't being realistic.</li>


<li>training on the new tool for all the people in the tech pubs department</li><li>training SMEs on how to do reviews with the new tool</li><li>cost of the software itself (usually going to be at least a couple thousand dollars) and that's on the low end</li>


<li>learning and implementing a new publication process</li><li>Localization costs -- Among other things there's a risk that the translation memory can no longer be used as is.</li></ul><div>I am sure I have missed others. When you add up all the hours and money spent, you are easily talking about a 10,000 to 15,000 dollar investment. </div>


</div><div><br></div><div>I needed a compelling business case that would <i>justify </i>that investment. </div><div><br></div><div>And with that let me start with the following customer complaint. I am paraphrasing. </div>


</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><i>You have so many PDFs. I have no idea, which PDF I should look in for the information that I need to know. I have to download a huge zip from your website, open each individual PDF, and then do my search in that PDF. Can you please just give me a single place to search for and find what I am looking for?</i></div>


</blockquote><div><i><br></i></div><div>And then there was another problem that the PDF deliverables were causing customer support. Frequently, customers would open up tickets about a problem they were having and it would turn out that this issue was 1) covered in one of the PDFs 2) would resolve the customer support ticket. The customer support person then had the burden of trying to hunt down this information or asking me where it was. The customer support team in other words had a similar complaint as the customer: we want an easy way to find a particular procedure or section and then provide that content to the customer.</div>


<div><br></div><div> It became clear to me that:</div><div><ol><li>No one had a desire to or would read the PDFs as a book i.e. a linear narrative. Technical content is boring, people are busy. They just want to get the information that they need to get their work done. They are completely uninterested in reading a 400 page user guide from end to end. </li>


<li>The <i>only </i>thing someone wanted to do  was have a google search like facility that would search all the content and then return the information they wanted.<br></li><li>The idea that people don't read end user documentation is not true. If it was, then no one would be complaining about their inability to find content. The fact that they are searching through the documentation indicates a desire and a need they think documentation can fulfill. </li>


<li>They want something that is fast to search, easy to access, and easy to view content. </li><li>And what they were searching could be boiled down to the following two questions: What is it or what does this mean? And how do I do that? In other words, concepts and procedures.</li>

</ol><div>Hmmmm, did someone say topic based authoring? Well, if they didn't, I did.   <br></div></div><div><br></div><div>
If I switched to topic based authoring (which of course would mean a significant restructuring and rewriting of legacy content) and I provided all content in a single package, then that would address the usability complaints raised by customers and customer support.</div>


<div><br></div><div>Right off the bat this would reduce customer support costs (less time spent resolving a ticket at a minimum) and increase customer satisfaction. In the medium term, that may actually justify the costs right there but when I considered the limitations of FrameMaker to implement topic based authoring and the other costs the current FM publication process imposed, then it became a slam dunk case for dropping FM.</div>


<div><br></div><div>And before I move on, here were some other requirements I had:</div><div><ul><li>The tech pubs is a small team. At most there are going to be 3 writers and typically it would be 1 or 2.</li><li>Contractors will be frequently used.</li>


<li>Budget is extremely constrained -- we couldn't afford a solution that was six figures. </li><li>We need a tool that is easy to onboard and train someone to use in one to two days. </li><li>We wanted an easy way for people, including, SMEs to review and generate content even if they weren't technical writers. </li>

</ul></div><div><br></div><div>
<b>SECTION 2: Why FM failed to meet that Business Case and Other Problems</b><br></div><div><b><br></b></div><div>I have used FM since 7.2.  I am currently on FM 10. I highly doubt FM 11 in any way addresses my criticisms but anything is possible. </div>


<div><b><br></b></div><div>All my content is in unstructured FrameMaker so some of my criticisms may not apply to structured FM. But that was irrelevant to me since I would rather chew off my arm then deal with the complexity and cost of trying to convert over to structure (it would have been prohibitive and yes I analyzed this in detail). </div>

<div><br></div><div>The topic based authoring business case was the key forcing function that got me off FrameMaker but there a lot of other problems that contributed to my decision to jump. If it was just the topic based authoring issue, then this decision would have been much harder. So lets dive into the many ways that FM has slowly been driving me insane.</div>


<div><br></div><div><b>Ahem FM=Books=PDFs</b></div><div><br></div><div>So first of all, can someone do topic based authoring in FM? Yes, but only at great cost and pain. The FM data model is a book model. For pete sake, it literally has a file called a <i>book</i> where you are supposed to add chapters to it. Everything about FM is geared towards and encourages book based authoring. Topic based authoring in FM is like shoving a round peg in a square hole.  And nothing illustrates that more, then this: FM can only generate a PDF of the source content. </div>
<div><br></div><div>So could someone create one or more FM files with a set of topics and then generate a humongous PDF from it.....Sure, I guess. I am just not sure why you want to.  Furthermore, by putting everything in a PDF, this severely undermines one of the most useful attributes of topic basic authoring -- topics are short and digestible. Even if topics are segmented by headings, from a user point of view it looks like one undifferentiated blob in the PDF. I could go on but I really doubt anyone who isn't Adobe is going to argue that FM is a good tool for topic based authoring. </div>


<div><br></div><div>And even if you ignore the profound limitations in authoring topics in FM, how does one avoid the final deliverable? PDFs are a terrible way to provide topic based help. There are a multitude of reasons that when someone says "topic based authoring" they are almost always referring to some sort of online help where the source content is XML. PDFs are books.  The bigger the pdf, the longer it takes to send, read, and search. And of course are friend the PDF is certainly not updateable in real time or otherwise. HTML help systems are a series of topics that are searchable, are fundamentally more scalable, and can be hosted server side. </div>

<div><br></div><div><b>And speaking of the cost of PDFs....</b></div><div>Way before my time, I had heard that much earlier versions of FM were supported on Unix and that these versions supported PDF batch processing. I have dreamed of this functionality for <i>years </i>on windows. Lets talk about one of the least favorite parts of my job: publishing PDFs. The following are all manual steps that must be done for each FM book.</div>


<div><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><div>So lets do some basic arithmetic. 3+1+3+3+1+5+10= 26 minutes for a book. I have 50 books so that means it will take 1300 minutes or 21 hours to produce an entire documentation set. In other words, it takes 2.5 days to generate a documentation set for one product. But it gets better, I have multiple products that I generate the documentation set for. Due to branding and legal names, even though the content is identical in many cases I still have to generate a document with different variables and conditional text set. So I have 3 products, where each product takes 2.5 days to generate a doc set for. That means it takes over a <i>week </i>just to generate all the documentation for a single release. In addition, my company follows the Agile SDLC, so I get to do this every 3 to 4 months. So in a single year, I can expect that someone would literally have to spend a month's worth of time <i>just </i>generating PDFs instead of oh i don't know actually writing content!!  And that's the ideal situation with someone who is familiar with the complex, manual process for generating the PDFs. The beauty of this process is its really hard to train and highly error prone so its not like this can be offloaded to an inexperienced tech writer or a contractor, who would inevitably screw it up. It means that a highly experience senior tech writer has to do it. </div>

</div><div><br></div><div>And now in theory there may be one or more custom FM plugins or even an ExtendScript that could be developed to automate this. But I view that as an unacceptable option for the following reasons:</div>

<div><ol><li>The cost would be significant -- if the contractor is competent he or she would surely charge thousands of dollars</li><li>The cost would be ongoing -- every time an upgrade of FM is needed that plugin would most likely need to be refactored.</li>

<li>The plugin becomes a SPOF in the documentation process. If the person who wrote the plugin either is no longer working or passes away, then you are SOL until and unless you find someone else to support it. </li></ol>
<div>
<br></div><div>And finally note this: <i>I am spending a month of man hours generating PDFs for an end user who does not want them.</i></div><br><div><b>The FM GUI is a clunky and Administrative Tasks are Painful</b></div>

</div><div><b><br></b></div><div>This is unfortunately just a catalog of ongoing grievances that I have had. One or two of them eh whatever but they really start adding up.</div><div><ul><li>Typing words in a FM file? That's easy enough. Applying paragraph styles and character styles okay fine. But everything else? Dear god its awful. I find the pods hard to navigate and use and the fact that a lot of the fields aren't resizable or small doesn't help. And hoo boy has anyone looked at the colors dialog box lately? That's just plain scary. The key issue i have with the GUI is that doing any type of administrative task or clean up is a 1) slow 2) multi click process in a 3) gui that makes it hard to see what it is you are doing. </li>

<li>The import process!? Why must it be unidirectional. I can get stuff in but its impossible to get stuff out without manual effort.  Accidentally imported 5 variables into 25 files? Oh well, go manually remove each one. And of course that applies to just about anything you choose to import. And yes I know there are plugins to address some of these problems (i dearly love the bookvars plugin for example) but that's just it: FM could handle this stuff much better but it just doesn't. <br>

</li><li>How does one know if files need to be cleaned up? FM reporting capabilities are not suited for that at all. </li><li>Of course if the template changes, then that means manually updating that change in every FM file that you have. Central control of the look and feel of all the files is non-existent in FM.</li>

<li>The search!!? Why in gods name can't they support regex, <i>especially </i>since the stinking files are binary and using an outside search facility isn't available?</li><li>Remember how ExtendScript was supposed to save the world and automate any and all administrative tasks? yea, its buggy and slow and it causes FM to crash. And oh yea the documentation is HORRENDOUS. If you want an API to be used by someone, you need to explain how to use it.  I can only assume that Adobe thought it would be a good idea to have an API and provide documentation that failed at doing such basic things as DEFINING WHAT THE BLASTED OBJECTS ARE!! Maybe I am just being silly but when you have an object in a JavaScript API, it would be wonderful to know what it is and what someone might want to do with it. And oh yea examples.....an example of how to use the object....oh well one can only dream. </li>

<li>The Integrated Help System Is An Abomination. If you select the help button, you LITERALLY wait at least 15 to 20 seconds before it loads (i know because I timed it, I had originally thought FM was freezing/crashing for some reason). Then, once loaded, it takes forever to 1) navigate, select, and load a topic from the TOC and 2) perform searches. I suspect the slowness has to do with the adobe air format and its insistence on having internet access to pull things from adobe servers. CHM may look uglier but its way more functional then this piece of garbage. And to add insult to injury, the actual content in the helps system is atrocious. Physician heal thyself. </li>

</ul><div><br></div></div><div><b>Having source content in binary, proprietary files is problematic.....</b></div><div>For a variety of reasons. </div><div><br></div><div>I used to store my FM files on a NFS. The network latency was awful and forget about using VPN. So migrating FM content to SVN brought me relief from that....but it meant storing binary files in SVN and to that I just say yuck. Forget about SVN diffing or blame and all the other useful things SVN can only do with human readable files.  </div>

<div><br></div><div>Because they are binary its pretty close to impossible to feed the FM files into a batch processor that can chug through the files to remove, modify, or add formatting or text.  And yes I know about MIF. Yes, I know I could first go through the process of converting them to MIF, and then either learn MIF (cause learning a proprietary, complex standard that is dying off sounds like fun) or purchase a plugin or program to parse the MIF data for me. So yea, that could work orrrr FM can stop using a binary, proprietary format and just use stinking XML.  And no I don't care about structured FM  or authoring in DITA, I just want the FM files to be XML documents full stop. </div>

<div><br></div><div>And oh speaking about MIF. Fun fact: When someone does localization work in house, that person literally has to save the files to MIF before doing the translation and then save them back to FM after the translation is done. The cost of file conversion adds up over time. Yes I know a plugin could mitigate that problem but not completely relieve it. But it ticks me off that I even have to consider a plugin because Adobe can't be motivated to have the files in a open source, human readable format.  And oh yea, did I mention that if they were XML documents, a translator could import the XML in and out of their translation tool without doing a file conversion? Its almost like having source data in human readable, open source, well-defined and structured format makes processing that data easier....who would have thought!! </end snark> </div>

<div><br></div><div><b>I dreamed a dream that FM never crashed..</b></div><div>And then I wake up to the sad reality. Every release becomes more unstable than the previous. FM 7.2 was rock solid. FM 8 was pretty good. But then hoo boy did things go downhill with FM 9. I suspect the instability got introduced when they revamped the UI but frankly why the crashes happen don't matter as much as that the crashes are in fact happening and they happen a lot. </div>

<div><br></div><div>I author FM files locally on my computer (remember SVN) and configured FM to automatically save the files every minute. And yet the crashes can sometimes happen so frequently that I still end up losing data. The worse part of the crashes is that they don't seem to happen for any rhyme or reason, there is no clear pattern that says if I do X then I should prepare for a crash. Its random but frequent so that's fun. And yes I googled, i checked forums etc I was unable to ever find anything to resolve the problem. And yes I am fully patched etc. Trust me I have been through the whole debugging thing. No luck. The best I have found is to reboot my computer and cross my fingers. </div>

<div><br></div><div>And I'd rather drink battery acid than deal with Adobe Customer Support, I learned my lesson the extremely hard way with that one. </div><div><br></div><div><br></div><div><b>FM Reviews and Track Changes: Buggy, Clunky, Manual, and Time consuming....whats not to like?</b></div>

<div>So subject matter experts.  We know and love them. They have the knowledge that we need to impart to end users. They are the ones that validate what we write is technically accurate and complete. And how pray tell does that work with Adobe FrameMaker as the authoring tool? </div>

<div><br></div><div>Well here's the best workflow that I know of: </div><div><ol><li>SME authors content in MS word or wiki.</li><li>tech writer extracts said content out of the input format, strips out formatting, and manually copies the input in as pure text.</li>

<li>tech writer than manually reformats the content to conform to FM paragraph styles.</li><li>Using the input from SME as a starting point, tech writer writes up the entire feature.</li><li>Tech writer generates a PDF from FM source.</li>

<li>Tech writer uses acrobat professional to enable commenting in acrobat reader on the pdf.</li><li>SME puts comments in acrobat reader and then sends the PDF back to the tech writer for review.</li><li>Tech writer manually goes through each comment and then copies or modifies the content in FM based on that comment.</li>

</ol></div><div>So here are the major problems that I have with this workflow:</div><div><ul><li>Significant amounts of time are spent  by the tech writer to <i>just </i>deal with importing and reformatting content from the SME input into FM</li>

<li>putting large numbers of edits in adobe acrobat is painful, slow, and tedious for the SME. Yes, 10 comments isn't that big of deal but imagine dealing with 300. </li><li>For the tech writer, going through each comment in the PDF and then manually making that change in the FM source is doubly painful.</li>

</ul><div>Yes, I know about FM track changes and I know that FM supports the ability to import comments from PDF into FM. The problem is that comment import process is a buggy mess  that doesn't actually work and has a high tendency to crash framemaker, corrupt the document or both. </div>

</div><div><br></div><div>What I want is the ability for the SME to 1) author in the same environment as the tech writer which means there's no more formatting/import/conversion step for either the SME or the writer and 2) be able to use track changes that are similar in functionality to MS word. FM track changes are nothing like that and they are a nightmare to use when conditional text is also in the same FM source. And oh yes TT causes FM to crash. And because TT are a problem, its hard for a tech writing team to review and comment on content that other people have authored in FM. </div>

<div><br></div><div><b>The FrameMaker and RoboHelp Integration: The Best of Both Worlds if Neither World contains Topic Based Authoring</b></div><div><b><br></b></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">

<div><div><i>So okay, someone might say (probably Adobe),  we get that people don't just want PDFs and that online help systems are really useful and much better suited for topic based authoring. However, can you really say that no one wants/needs PDFs? You know what you need? You need to be able to satisfy both audiences: those that want PDFs and those that want a help system. Plus, do you really want to deal with conversion to a new tool and lose FM's powerful and reliable paragraph styling. I mean my gosh, you'd be certain to lose FM amazing autonumbering capabilities and have to deal with  THE HORROR!!! HTML numbering. Nooooo don't do it!!! So obviously you should author all your content in FM and then use RoboHelp to import your content from FM and convert it into HTML pages. </i></div>

</div></blockquote><div><div><br></div><div>So a couple problems with this argument for the integration. First, consider this argument:</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote>

<i><br></i><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><i>We get that people don't just want printed documents. They also want a PDF because it would be convenient to just download a file or access the file from a CD. However, can you really say that no one wants/needs printed documentation? You need to satisfy both needs.</i></blockquote>

<div><i><br></i></div><div>And that's why everyone still produces printed documentation to this day....oh wait. In fact, plenty of people could die happy never interacting with another PDF again and do. Some people only use PDFs because tech coms may not give them the option to consume the content in an alternative form. And more to the point, even if it is true that some people would like it in a PDF, there's more to this analysis than just the preferences of some customers for a particular output. Among other things, there's the cost of producing PDF content. Not only is it not free, its <i>significantly </i>more expensive than producing a help system. One needs to weigh the customer satisfaction of a subset of people against the labor and time cost of producing the PDF content. I am highly skeptical that in the IT industry the cost of producing PDFs is always worth it when a help system is a viable alternative. More to the point, in any reasonably sized organization, the documentation format, content structure, and the tools used to author the content can persist for long periods time, way past its sell by data, due to inertia, fear of change, cost of conversion, and the fact that PDFs are "safe". Its a well known format that everyone is comfortable using and while giving a PDF to a customer may not be as helpful, its such standard practice that a customer is unlikely to complain that much if at all. In other words, sure a PDF may not be ideal but we have bigger fish to fry......</div>

<div><br></div><div>But there's an even bigger problem and its the idea that one can successfully do topic based authoring through RH integration. One of the biggest mistakes someone can make when switching to topic based authoring is importing legacy content into a tool that slices up content into a different topics based on the topic headings. Some people think that after the import is done, topic based authoring is achieved and then everyone can go home. However, topic based authoring is not a tool or a help system output, its a way of authoring content. And the chances that legacy content which was structured and written for a book output will somehow become topics by virtue of being split apart is highly unlikely. Legacy content is almost never going to fit nicely in a topic based authoring paradigm, in fact what was once well organized content suddenly becomes incomplete, too short, too long or insert all the problems with trying to make book content look like topic content etc. Importing legacy content into a XML authoring tool is the first step, making that content into topics is the next and by far biggest step. </div>

<div><br></div><div>Now consider what the FM-to-RH integration is. All it does is convert FM files into HTML topics. RH gives you the ability to split a FM file into multiple HTML topics based on the heading in the FM file. However, once HTML files are generated -- that's it. If are sticking to the author in FM source and use RH to generate help system  model, then you will link the FM files into RH. That means the source content is always and forever controlled by and comes from FM. Once HTML files are imported from FM, you don't have the option of restructuring the HTML topics, re-purposing, or rewriting topics. And the reason is that anything you do will be overwritten by the FM source, when you update the FM book in RoboHelp. All this integration gets you is FM content wrapped in a help system bow tie. And if that's what you are looking for then great but its unlikely to ever give you topic based authoring output while still having FM source that makes sense in the context of a PDF.</div>

<div><br></div><div>And one of the reasons I know all this is because I have used this integration since release 1.3 of the Technical Communication suite.  I am deeply familiar with how this works and that's why I can say that even if you put aside the concerns about topic based authoring, you will start running into a variety of extremely painful technical problems. </div>

<div><ul><li>Setting up the integration is extremely painful. You need to be very knowledgeable about CSS, understand the FM data model, and grasp how RH is going to map the FM data into a HTML structure. </li><li>The integration is buggy and slow. It can frequently cause either RH or FM to crash. </li>

<li>The process is manual and time consuming. To convert one FM book into a help system, usually takes at least 4 to 8 hours. This assumes you are an expert on the process, know exactly what to, and have a well documented procedure that you follow (the procedure will have a lot of steps I promise you).</li>

<li>Training someone on how to do this integration usually takes at least a week and it takes a new person approximately a week or more to generate a help system on their own.</li><li>The more books you add to a RH project, the more unstable things become and the more likely either RH or FM will crash and burn during an import or update. </li>

<li>The webhelp output can frequently and randomly have mangled or extraneous formatting.  The only way to guard against this is to literally check every single HTML page. If an error is found then you must regenerate the content and then start the checking all over again.</li>

</ul></div><div>So lets do some more math. :)  Lets be conservative and say it takes 4 hours to generate one book. That means generating a help system that contains 50 FM books would take about a month. But it gets better. I have 3 products to support, so you can effectively triple that amount of time for a release if I wanted to do the virtuous thing and cover all the products.  And every time another book is added, the time to generate the help system will increase commensurately.  Since this obviously doesn't scale, I actually compromised and only generate a help for some specific GUIs in the products. On the one hand, this means I only have to generate help for a single book. On the other hand, this means all the other content is not and never will be part of the help system. </div>

<div><br></div><div>And finally if someone is actually serious about doing topic based authoring, why in the world would they bother authoring the content in FM? Why wouldn't someone just import the content into RoboHelp and then break the link to the FM source and never look back?</div>

<div><br></div><div><br></div><div><b>SECTION 3: Why Not RoboHelp?</b></div><div><br></div><div>Alright, so someone might point out that while FM is not the best choice, why not just import FM content into RoboHelp  once and then just use Robohelp. Why wouldn't RoboHelp be an acceptable tool for doing topic based authoring? And guess what? I agree. RoboHelp is a perfectly good tool to do topic based authoring. And the legacy conversion from FM to RoboHelp would probably not have been much worse than doing it with some other product such as Flare. </div>

<div><br></div><div>So why did I end up picking RH over Flare? Especially, since the people who originally created RoboHelp are the people who are now producing the Flare software.</div><div><br></div><div>One answer is that I think Flare is just a flat out better tool than RoboHelp from a technical standpoint but I'll get into that in detail in the next post.</div>

<div><br></div><div>The other issues have to do with the Adobe culture, organization, and the direction that its taking the TCS product. </div><div><b><br></b></div><div>So has anyone heard the term "apoplectic rage"? Adobe has provided probably the worst customer support experience of my entire life. After having been burned so badly two years ago, I have made a concerted effort to never interact with customer support again less my soul enter into a pit of deep despair and I lose all faith in humanity. I don't believe Adobe's business strategy is in providing a good customer experience. I think they view customer support as either a revenue generating opportunity or a  cost.  The former if you have purchased a customer support contract with them. The latter if you have not.  And oh to call their contact center and navigate through their phone tree....[shudders]</div>

<div><br></div><div>Now ....licensing. Adobe is in the process of switching over to a cloud licensing model. Right now its optional. I don't think it will stay that way for long. The revenue potential from cloud licensing model are huge.  Plus, I am sure the model will reduce the company's costs too. So I get why they want to do that and that they will probably do it. But this always inevitably gets into some type of subscription model, where if i don't pay up on a monthly, quarterly, or yearly basis I would lose access to the source content in some fashion. Either the program itself will stop working or if I am forced to keep the content on the cloud, then I'd actually lose access to the content. And then there's all these sticky legal questions about who "really" owns the content. And on top of that, inevitably the cloud model will impact the performance of the software because the software is periodically going to be "calling home". I believe the start of this will be the pricing. Adobe won't at first actually say you have to use a cloud license but they'll start ratcheting up the cost of a perpetual license relative to the cloud license. Then it goes downhill from there. To sum it up, I'd rather do my documentation in notepad + then have a cloud license.  </div>

<div><br></div><div>Finally, consider the financial bind that the technical communication suite puts Adobe in. The core products, the ones that are critical to the suite and probably account for the majority of its revenue, is RoboHelp, Framemaker, and Acrobat Professional. I knows that's the only reason I buy the suite. FrameMaker is dying and lives on only because of all the legacy installs out there and the perceived need for PDF output. I have said it many times before but I'll say it again. As long as PDF is the main deliverable to end users, FrameMaker reigns supreme in tech comm. The moment it does not, it will die. That moment has arrived for me and I think its fast approaching for others.</div>

<div><br></div><div>So Adobe could make a pivot here. They could maintain FrameMaker in order to keep legacy customers happy and benefit from that revenue stream but focus like a laser on RoboHelp to make it the best XML authoring and topic based authoring tool out there.  Then, once enough people have migrated off FM, they just kill FM and they are left with RH. If they did that, then I think that RH would be just as good if not better than Flare. But they don't because they are afraid of cannibalizing their FrameMaker users and the consequences that would flow from that. If RH becomes good enough, then many tech comm people will just  generate help systems. If they just generate help systems, then they don't need FM. And more to the point they don't need or care about PDF output. If they don't care about PDF output, then they don't need Acrobat Professional. And with that you have just killed off the value proposition of the technical communication suite for a lot of people. They'd just buy RoboHelp and call it a day.  </div>

<div><br></div><div>Nothing illustrates this better than the fact that RoboHelp still isn't an actual XML editor. There is no technical reason why it couldn't be, there are compelling use cases why it should be, and yet its not. I think this explains why I found RoboHelp to be so inferior to Flare.  But this post has already gone on long enough. I'll leave my analysis of Flare for my next post. </div>

<div><br></div><div><br></div><div><div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><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>