Six years ago I joined a start-up to write their product documentation. They were using Microsoft® Word, but I desperately wanted a real technical writing tool (yes, I know I’ve just upset some technical writers by that comment). They agreed to use a professional tool, and I was set the task to find the right one. I already knew that I wanted to use MadCap Flare but I needed to do my due diligence. So I set about researching all the popular tools. XML was the buzzword at the time with its ability to separate content and presentation. Other popular themes were CSS, single-sourcing, topic-based writing, and multi-channel publishing. I wanted a tool that checked all the boxes and then some to make sure it would be future-proof.

UnaCogavin-Image2 (004)

Included in my research were the Adobe FrameMaker® and RoboHelp® products. I had worked with both tools extensively in the past and liked them both. However, FrameMaker® could produce only PDFs and RoboHelp® could produce only online help. As separate products they could not do the job of producing PDF and online help. So I was eager to understand how Adobe had integrated them together in order to produce both PDF and online help. I spent an agonizing 15 minutes on a call with an Adobe salesperson trying to figure out how the two products integrated. I finally gave up because the salesperson was not knowledgeable about the products she was selling.

Recently, when MadCap Software asked me to write a guest blog post about comparing my experience with Flare and FrameMaker®, I was interested to see just how much further Adobe had progressed with its FrameMaker® and RoboHelp® ‘integration,’ and whether the integration was still needed to bring FrameMaker® up to parity with Flare.

1. A tool based on modern, open technology, which future-proofs your content

Although I do most of my writing in Flare, I still need to stay familiar with FrameMaker® for clients who want to convert their FrameMaker® content to Flare. FrameMaker® still uses proprietary technology to store and edit content. It then converts the content to HTML, but only at the point of building the output. The good news for FrameMaker® users is that it now produces HTML output.

Flare takes a completely different approach. MadCap is so committed to open standards like XML, XHTML, and CSS that it uses these technologies in its products, as well as output formats. So why is this important? See https://www.madcapsoftware.com/blog/2013/08/16/why-its-smart-to-choose-xml/.

FrameMaker®’s HTML output is in essence an HTML version of the PDF output. You can use conditional text to include/exclude content relevant to PDF or online formats, but that is where FrameMaker®’s capability to customize the HTML output stops. Flare uses XML/XHTML to store and edit your content’s source, so you can separate the content from its formatting. And it doesn’t stop with just your content files. All Flare files are separate XHTML and XML documents—topics, TOCs, browse sequences, targets, skins, snippets, glossaries, destinations, condition tag sets, variable sets, and more. This means that Flare projects are completely open, transparent, and accessible. Not so with FrameMaker®’s proprietary technology.

Because FrameMaker®’s output is HTML and not its source, if you decide to add any scripting to the HTML output, it is lost next time you produce it. In other words the scripting is a post-production task. Flare lets you add scripts and advanced CSS directly into the content. And now that Flare supports top navigation and HTML5 output without frames, you can literally build a frameless Website that Google can index, giving full search capability to all your online content.

TOCs

With FrameMaker® you can have only one table of contents to build and structure your output. That’s why your FrameMaker® HTML output will closely mimic your PDF output. That’s a very limited type of ‘reuse’ model. Flare lets you create as many tables of contents as you want. This means you can reuse content in as many different configurations as you want to. (You need to integrate FrameMaker® with RoboHelp® to add additional tables of contents.)

Source Control

FrameMaker®’s source files are compiled. You can check them into a file versioning tool, but because they are not text-based you cannot merge files. Flare’s use of XML/XHTML technology for storing content and configuration files allows you to merge files. This means you can have more than one writer working on the same content or configuration file and then merge the changes and resolve any conflicts.

Una1

Beginner, Intermediate, and Advanced Users Support

With FrameMaker® you get a propriety UI that acts as a WYSIWYG editor, but only for printed output. Flare provides a WYSIWYG XML editor and a text editor. The XML editor allows you to view what your content looks like in online or print formats with the simple click of a button. You can see how your print CSS and online CSS styles look with your content. You can apply different page layouts to get a full WYSIWYG experience and you can preview output. Flare can do this because of the use of XML open technology at its core. In addition to viewing content files as text, you can open almost every type of file as a text file and get right into the guts of the source… but only if you choose to. Flare lets beginners and advanced users work side-by-side providing the right amount of distance from the ‘source’ for beginners, while allowing advanced users to use text editors and add customized JavaScript and jQuery code.

Una2

2. A single tool with many outputs

FrameMaker® has improved its repertoire of outputs. It can now produce both PDF/print and online WebHelp and HTML help, among other outputs. However, Flare still surpasses FrameMaker®’s list of outputs. In fact to get the full list of Flare’s outputs FrameMaker® users need to purchase and integrate with RoboHelp®. And we are back to the question, what does ‘integrate’ really mean? As part of writing this blog, I decided to call Adobe’s sales to find out. They didn’t really know. They pointed me to their online chat support where I waited for over 30 minutes before a chat representative got on the chat with me.

Because I was determined to finally figure it out for this blog, I spent another hour and 30 minutes trying to get an answer to my question. How exactly does FrameMaker® integrate with RoboHelp®? I was eventually pointed to an online video, which I’d already viewed. So I’m still not sure exactly how well they integrate. From viewing the video it seems that you need to follow an import process from the RoboHelp® tool. OK, assuming the import works smoothly (I doubt it!), do you now author your content in RoboHelp® going forward? Or, do you continue to use FrameMaker® and re-import into RoboHelp® each time you want an output that RoboHelp® provides, but that FrameMaker® does not? I never got a clear answer.

I came to the conclusion that if you are going to go through the pain of importing and mapping your content into another tool it should be one that can do everything you want, and you shouldn’t have to do it repeatedly. It would be so much easier to import your files into MadCap Flare and be done with all the hassle.

3. Topic-based authoring versus chapter-based authoring

FrameMaker® has not yet embraced topic-based writing. It is still operating on the old chapter-based file paradigm. To generate topic-based online help with FrameMaker® you need to integrate with RoboHelp® to convert those chapters into topics before generating online help. Flare, by deliberate design, encourages topic-based writing; one topic per file. You can easily reuse content because it is modular and with Flare’s multi-TOC capabilities you can change the order of the content.

Topic-based writing brings all sorts of benefits and cost savings. You can split writing tasks up among many writers without your tool’s technology getting in the way.  Smaller pieces of content can be reviewed independently, which supports agile environments.

4. Saves money on translating content

If you have ever worked on documentation that is translated you understand the costs involved with translation. You are encouraged to limit content changes to mitigate costs. Even when you don’t change a lot of content you need to run a whole book or possibly just a chapter through translation memory. With topic-based writing you can just send the updated topic through the translation memory. This means faster and cheaper translation. Beyond the savings from minimizing the amount of content that needs to be run through translation memory, MadCap provides specially designed, cost saving tools, such as Lingo, for translation. Lingo allows you to do translation in-house or keep the costly project generation in-house. FrameMaker® has not added any obvious improvements to help with translation costs.

screenshot-FlareTranslationExample

5. Single source content, video, and images

FrameMaker® lets you reuse content to produce different output types. However, single sourcing content is much more than just generating different output types from the same content. With Flare you can combine projects into a global project, which is not something FrameMaker® can do with book files. You can import multiple projects (removing the links to the original project files), auto-import projects (keeping the links to the original project files), or simply refer to a TOC in another project from the global project’s TOC file.

ill-singleSourcing

You can also create a project to store common files that you wish to control centrally, for example, your organization’s CSS file, page layouts, copyright content, etc. You can then set up other projects to automatically import these centrally controlled files when you generate the other project’s output. Or, you can import them manually. Doing this ensures all your projects use the correct styles. FrameMaker® stores styles within each chapter file, so it is not easy to keep each and every file up-to-date with the correct styles.

Beyond single-sourcing written content, you can use MadCap Capture, which is bundled free with Flare, to single source images. For each image, Capture lets you set up image settings for each of the Flare output types. For example, you can generate HTML help and have the image generate as a JPEG file with a lower resolution to help with file loading speed. Then using the same image file, you can generate a PDF and have the image generate with a higher resolution and smaller dimensions. MadCap also has a video capture tool, called Mimic, for integrating videos, simulations, and tutorials. Both Capture and Mimic files have access to the conditions and variables in the Flare project, which extends single sourcing capabilities.

MadCap provides another useful tool called MadCap Analyzer, which you can use to manage your Flare content files. With this tool you can discover content that can be better utilized as snippets for the purpose of reuse.

6. Knowledgeable sales and support teams

As I said earlier, the first time I called Adobe to understand how FrameMaker® and RoboHelp® integrate I was left less than impressed. So I decided to see if their sales and support team had improved. But unfortunately I was disappointed again with their lack of knowledge and support.

In contrast, MadCap bends over backwards when it comes to sales and support. If they have based Flare on open technology, then they have based their culture on enabling and supporting their users. The MadCap sales team is knowledgeable about their products and quickly escalates questions to support if they are not able to provide the answer.

If you can’t stretch to the cost of the Platinum maintenance and support plan, which allows you unlimited direct calls to support, the Bronze plan provides you with unlimited email support. Everyone can access a great community Forum where fellow MadCap users, affectionately referred to as ‘propeller heads,’ help each other with tips and advice. There is also an extensive Knowledge base. MadCap holds frequent free webinars on a wide range of topics. If you can’t make it to a live webinar session, you can access all webinars online. MadCap also has knowledgeable, certified consultants that you can hire if you want to hit the ground running.

7. A company that focuses specifically on technical communication and content development tools

FrameMaker® is an Adobe product. So is Dreamweaver®, Illustrator®, Photoshop®, Captivate®, After Effects®, InDesign®, etc. I think you get the picture! Adobe has a lot of irons in the fire and does not focus purely on technical communication and content development tools. Many Adobe products are great tools, some are even best of breed. MadCap is very focused on technical communication and content development tools. They designed and built Flare, and all the other tools in the MadPak Professional Suite, purposefully to compliment and work together. They sold off RoboHelp® for a reason… it was not future proof. I believe that MadCap has a much better understanding of what a technical writer needs to write and get the job done. Yes, you can still be a techie and be nerdy when you feel like it and have the time (you know who you are!). But when you need to get the job done you want a tool that is smart, efficient, and flexible… and does not get in the way of writing.

8. Navigating cost and return on investment

In my original research six years ago I was somewhat stunned at how expensive some XML-based tools were. You had to be a large corporation to buy them and hope to get enough benefit out of it to make up for the cost. MadCap Flare was the only tool that checked all my boxes and that I could afford to buy. Flare’s pricing was and still is affordable for an individual to purchase, as well as a company. And it gives you all the benefits of the large more expensive tools (See ROI case studies here).

In a price comparison between FrameMaker® and Flare there is probably not that much of a difference, unless you need to add on RoboHelp® capabilities.

Adobe is pushing the subscription license rather than the outright-ownership model. Flare also has a subscription license, so both compare well on that point. However, as with any tool, and no matter how advanced a user you are, a tool needs a good support infrastructure and team. They can be your last life line on the eve of 4th of July, Thanksgiving, <insert your favorite holiday here> when your organization thought it was a good idea to launch a product. You want to invest money in a good support system, and MadCap wins that comparison bar none.

In summary

To be honest I was a little surprised Adobe was still trying to integrate FrameMaker® and RoboHelp®. Now that FrameMaker® has the ability to output to HTML I am wondering about RoboHelp®’s future. On the other hand, RoboHelp® supports topic-based writing and FrameMaker® does not. It is difficult to understand Adobe’s strategy for the future of these two tools. Why continue to have two tools? At the moment it seems risky to commit to one or the other of these tools. Logic seems to say that at some point one of these tools will disappear off the market. Which tool will win out in the end?

My time and my money (two things very precious to me) are still backing MadCap Flare. After all, the original makers of RoboHelp® sold it to Adobe and then created a brand new tool–Flare–for a reason. Flare is a tool that is specifically designed to utilize XML/XHTML, CSS, single-sourcing, topic-based writing, and multi-channel publishing. In other words it still checks all my boxes, while FrameMaker® and RoboHelp®, even combined, do not.
https://www.madcapsoftware.com/blog/2015/12/03/guest-post-8-reasons-madcap-flare-outperforms-adobe-framemaker-every-time/
www.madcapsoftware.com
crawl=CC-MAIN-2019-22
210092
application/http; msgtype=response
sha1:QGLI3OXUN4Q4YPUDU3UYWGDWBKAGZIVN
<urn:uuid:73813010-efd8-4935-9ebf-6429fd6b7e5f>
2019-05-19T16:53:59Z
23.101.169.175
text/html
sha1:VAICWY2PDVKJEJZCT6YV7QBSM2YSRJVI
<urn:uuid:01ac7523-1192-410e-9982-9ade2e488ebf>
https://www.madcapsoftware.com/blog/2015/12/03/guest-post-8-reasons-madcap-flare-outperforms-adobe-framemaker-every-time/
response
<urn:uuid:a52da88e-aa3c-46ef-8baa-3b22d523f3a4>
isPartOf: CC-MAIN-2019-22
publisher: Common Crawl
description: Wide crawl of the web for May 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-47-182-244.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/