In this third blog post in the series, I share more concepts and tools that have captured my attention during my product exploration of MadCap Flare. Like many people, I have been authoring with a traditional “document-centric” workflow which address multiple outputs (print, screen) at the end of the cycle, rather than at the beginning. (Little wonder, I was Product Marketing Manager for FrameMaker® before it was acquired by Adobe®!) So, some workflow concepts that veteran Flare users may take for granted are a really big deal for people like me.

Why am I so excited about Flare after using Regular (unstructured) FrameMaker® for 25 years? As I summarized in Part One: The 10 Year Paradigm Shift, constant content reuse and a true separation of formatting from content are hallmarks of Flare that are quite a contrast to Regular FrameMaker®’s traditional publishing model.

The following are just a few key features in Flare for which I’ve found no direct parallel in Regular FrameMaker®:

  • Topics, the building blocks of modern HTML5 output
  • Snippets, miniature topics that can be used over and over again
  • Style formatting that exists outside of Topics via Cascading Style Sheets (CSS)
  • A style window that previews style formatting rather than displaying a name in a traditional paragraph or character catalog
  • Responsive Layout window pane to help you design responsive content, and even change the order in which certain elements (e.g. graphics) appear when screen sizes change; preview layout for multiple screen sizes simultaneously
  • Built in project layout templates that pre-define HTML5 Top Navigation Output, keeping key navigation links within constant view
  • Concise and incredibly effective online Help and documentation (see hyperlinks in the next bulleted list)

Note: Regarding the last item listed, I would even venture to say that Flare’s Help documentation may be the best for any product that I’ve used, not just authoring or publishing software!

These benefits will be covered more in depth in future blog posts. In this episode, I want to focus on the benefits of moving away from a traditional, document-centric workflow.

Workflow: creating a new project

With Flare, we think in terms of projects and components rather than books and chapters/documents, which may eventually be published beyond paper and PDF.


Basic steps for starting a new Flare project are:

You may view a brief video that covers all steps for starting a project by expanding “SEE THE MOVIE” on the following Web Help page for Flare: Creating a New Project.

Once a project is defined, you may easily create a more-or-less “empty” project with all assets assembled and “fill-in-the-blank” topics. Then, sophisticated new projects may be swiftly created by novices.

As you create various assets for your project page layouts and style sheets, they are automatically saved to simple category folders under Resources. This is one of the most marked departures from the traditional Regular FrameMaker® (or Word) publishing model: key formatting and layout information is not embedded in a proprietary, binary document format.

One thing this model does is to put authors and publishers in the habit of locating project assets in the same place for each project. Earlier publishing models like Word or Regular FrameMaker® tend to put the burden on the author, regarding where graphics are accessed. The Resource file structure shown above is a common denominator across most projects.

Building blocks vs. documents

01 B build blocks

With Regular FrameMaker®, key ingredients to document structure like styles, page layout, variables and conditions are viewed through the lens of various catalogs and pop-up pods. Because Flare is topic-based authoring vs. document-based, the author thinks in terms of building blocks vs. pages. Styles go beyond print on paper, with consideration for formatting (e.g. boxed text with rounded corners) that lends itself well to content consumption on portable devices. Layout is not limited to a traditional concept of “master pages”: dynamic layout is addressed with a layout editor that previews multiple devices.

Flare users plan for multiple targets and audiences through the lens of strategic building blocks, rather than via the proprietary catalogs and pods of traditional, page-centric publishing.

Flare’s main content building blocks are Topics, Snippets, Images and Variables. There are many other components to choose from, and the author may be quite creative in how building blocks are combined. For instance, Variables may have Conditions defined and Snippets may contain Variables.

When authoring with this model, sensible content reuse becomes second nature. Unlike traditional publishing, Flare rewards users for planning content reuse tools like Snippets and Variables ahead of time.

A parallel feature: building output using a batch target

I did find one startling parallel feature available in both Flare and the FrameMaker® product family: batch publishing.

Flare allows you to create a “batch” target for publishing multiple targets at the same time. Flare’s batch target even has a schedule tab which enables you to run the batch at any date and time. This functionality is available at no extra cost in Flare.

Similar functionality is available through Adobe® FrameMaker® Publishing Server (2015 release). This separate version of FrameMaker® has a list price of US $14,999.00.

Blame it on our youth

Why is Flare so different in design and workflow than traditional solutions like Regular FrameMaker® and Word? Flare was first released 10 years ago, whereas FrameMaker® came on the scene 30 years ago. We can only attempt to imagine how Flare will further develop by 2036, when it has achieved Regular FrameMaker®’s maturity.

Explore some of my favorite features

Until the next post, here is a list of links to brief videos and interesting Help topics that captured my interest: