Welcome to my second blog post on Modern Content Development, which charts the journey of discovery by a long-time FrameMaker® user transitioning into the world of topic-based authoring via MadCap Flare. Since my Intro blog post, I’ve completed 4 classes on MadCap Flare. Working with the leaner, content-focused tools in Flare has been a real eye-opener. My initial discoveries include:

  • Authoring effectively with a true separation of format from content via XHTML and Cascading Style Sheets (CSS)
  • A slender but potent “structure bar” that replaces an unwieldy “structure view” common in XML and DITA authoring software, presenting only essential choices to the author
  • Constant content reuse with a different type of variable (which can be inserted almost anywhere) and nimble snippets
  • A single “launching pad” for publishing targets, from responsive HTML5 to print
  • Continuous access to DHTML and other means of adding visual importance to links during the initial authoring process

Although I’ve found some functionality in MadCap Flare that has a loose equivalent in Regular FrameMaker® (authoring without DITA), I’ve been astonished at the number of tools in Flare which have no equivalent at all in my previous authoring solutions. Looking at a history of the two products, it is easy to understand why they are so markedly different. Let’s start with a recap of when FrameMaker® was developed and how authoring has changed since then.

Looking back 10 and 30 years: why Flare is so different

The first release of FrameMaker came 30 years ago this April. FrameMaker® was one of the first authoring solutions to enable simultaneous word processing, page layout, and graphics editing. You could even edit a document while printing in the background! Few products were capable of this triple threat back then; FrameMaker® was empowered by early UNIX-based workstations which allowed true multi-tasking.

FrameMaker® has certainly improved dramatically over the past three decades, but the key components of the basic user interface for formatting are little changed. FrameMaker®’s current, super-charged paragraph designer would be recognizable to users from the early 1990s.

For at least the first 15 years of FrameMaker®’s life, paper was the primary deliverable for all projects. One of FrameMaker®’s hallmarks was the ability to manage massive projects over 1,000 pages long via chapters in a book paradigm. FrameMaker®’s basic publishing model was well established before several significant publishing standards emerged:

  • PDF became a common standard in the mid-1990s
  • HTML-based Web Help started in 1994, and the World Wide Web Consortium (W3C) began promoting cascading style sheets (CSS) for HTML after 1997 (when FrameMaker was 11 years old)
  • The first specification for XML went into “rough draft” in 1998 and XHTML had a specification by 2000

By 2010, the concept of “single-sourcing” and “multi-channel” publishing had radically expanded beyond different versions of print content derived from a single set of source files (documents). Although a number of improvements and add-ons have since appeared, un-Structured FrameMaker®’s basic authoring model for standard authoring still rests on paragraph catalogs and the book model of documents and pages.

Flare and the last 10 years

MadCap Software released the first version of Flare in 2006, 20 years after FrameMaker® and after all of the standards listed above had matured. Most significantly, the concept of “Help Files” had considerably matured, and the proliferation of mobile devices could be foreseen on the near-term horizon. Two key “game-changers” occurred early in Flare’s development.

  • 2007: launch of Apple iPhone and Amazon Kindle
  • 2010: launch of Apple iPad

Smart phones and other mobile devices changed customer reading habits overnight. One has only to remember one of the many famous photos of the faithful gathered in anticipation of the new Pope Francis: they were all holding smart phones instead of candles.

Due to the number of times per hour that we seek information on hand-held devices today, our orientation has permanently moved away from paper to glass.

Because Flare started with screen display as the primary early target, the product has sensible, built-in structure which rewards the user for employing topic-based authoring. A page- or paper-based authoring model does not lend itself as well to modern, multi-channel publishing that reaches a host of display platforms as well as PDF or print.

Here are just a few areas of MadCap Flare that strike me as a welcomed departure from traditional authoring solutions.

Fewer choices, more power

Because Flare authors in XHTML, the XML editor presents styles that are “multi-purpose” (via classes) in contrast to a traditional paragraph catalog. Since formatting is controlled via style sheets (CSS), a single style can serve multiple purposes; formatting can be controlled more effectively on a global basis.

CSSEditor flare12

The advanced CSS editor in Flare 12.

Inheritance pre-formats all of your styles

In traditional page-centric authoring, each paragraph is a self-contained repository of formatting. This is evidenced by the “mish-mash” of formatting that occurs if you delete a paragraph ending marker that is followed by another style.

An arcane method of selecting multiple paragraph styles and applying an “update all” makes it possible to reformat more than one paragraph at a time in a FrameMaker® document/template. Regular FrameMaker® documents are globally reformatted by importing styles from an external FrameMaker® document; the burden is on the author to remember which document is the “template”.

In stark contrast, Flare uses style sheets which are contained in your project’s folder structure. It is very easy to determine “from whence your styles cometh.” (Multiple style sheets may be employed and will be covered in a later post.)

MadCap Flare leverages the power of inheritance in CSS: your base style contains fonts, sizes, etc. that are common to all styles in your project. When defining a new style in Flare, you only need to select the few categories that are different from its inherited values. Style sheets come predefined with sensible overrides to several levels of headings.

Incidentally, because Flare was designed for a different publishing paradigm, style sheets even allow you to select a graphic for automatically “bulleted” lists, instead of a unique font character! (That has been on my wish list for years.)

Constant content reuse

Flare is designed for the author to create topics, rather than complete chapters in a single file. Since topics may easily be reused, redundant content is limited to a few source files that may be edited to globally update the entire project.

In yet another stark contrast to the traditional pubs model, Flare allows you to create and employ Snippets. These “file chunks” can contain practically anything, but can reduce all your Cautions and Warnings to a handful of unique, referenced source files.

Multiple targets eliminate old-fashioned style mapping

When modifying or creating style sheets, you can select multiple “media” targets; this allows you to simultaneously preview styles for HTML5, PDF, Word and more. The important difference in the Flare model is that you do not have to work with “mapping tables” to assign CSS styles to old-fashioned paragraph formats.

Due to its earlier birth, Regular FrameMaker® approaches on-line publishing targets as a derivative process, spawned from content inherently designed for print or PDF. In a separate process with distinctly different menus, the Regular FrameMaker® user will map paragraph styles to XHTML styles for online publishing.

Built-in project management tools

As you expand your publishing assets (skins, targets, etc.) in Flare, they are automatically saved into your current project folder. Locating project assets is an intuitive process, as you are not dealing with folder structure determined by the arbitrary preferences of different authors.

Fairly robust analysis or reporting tools in Flare make it a snap to determine if you have broken links, or where and how often an individual graphic is used. You may generate short, convenient reports, which may be printed out (in contrast to a series of screen captures in Regular FrameMaker®). This feature alone can eliminate countless hours in project management.

“HATs” off to Flare

Earlier versions of Flare were sometimes perceived as “only” a Help Authoring Tool (HAT), with limited print capabilities. Several releases ago, Flare dramatically expanded its print publishing capabilities; so much so that technical documentation authors whose primary target is PDF or print could seriously consider Flare as their preferred tool. Many of the “out-of-the-box” PDF targets (templates) in Flare are so sophisticated that some people would not imagine that their published results came from our software.

As referenced in the timeline at the beginning of this post, Flare was born in a recent period of publishing history when it no longer made sense to author from a page- or print-centric model. As a result, in MadCap Flare we have an elegant multi-target authoring solution with a sensible user interface. As our tagline states, “Create, Manage and Publish Content for Any Audience, Language or Format.

Stay tuned for my next post, which will focus on many unique benefits of MadCap Flare’s user interface, and several “power tools” that will be new to anyone still working with a traditional, page-centric authoring solution.