This is the fourth blog segment in my series on moving away from page-centric, traditional publishing to modern content development. Since joining MadCap Software on March 1st, I have been impressed by the many advantages that Flare has over traditional, print-focused publishing.

I spent over 20 years working primarily with Word and Regular FrameMaker®, as well as 10 years of attempting to promote DITA, primarily via Structured FrameMaker®. My observation has been that today there about 35% of the DITA users that were forecast 10 years ago.

As a result, I developed many habits that I was comfortable with, tied to a traditional publishing model that is still common. FYI -- while Flare supports DITA import and export, native DITA authoring is not currently on our roadmap, so my blog series does not delve into this.

Although overall I have found Flare to be very accessible and relatively easy to master, there are many categories which are radically different from the traditional publishing model. A bit of adjustment is required while moving in almost an opposite direction from Regular FrameMaker®, to achieve single-source publishing to multiple outputs.

In this blog post, I will focus on templates (Cascading Style Sheets), Responsive Layout and more.

Single templates vs. multiple CSS style sheets

For the past two decades I’ve become a master at designing Regular FrameMaker® and Word “templates” that were in reality richly formatted documents. I could either import all categories (paragraph, table styles and page layout) or a single category from an external document. Although this method can potentially be powerful if applied with great discipline, any record of where my formatting came from depended on screen captures and carefully captured notes. In contrast, Flare supports multiple style sheets automatically linked to project or topic, which are stored in an easily visible folder adjacent to the content.

Much of the formatting information in Regular FrameMaker® was not easily viewed. For example, if you wanted to view a table style, you needed to create a temporary instance of it on a page adjacent to your catalog. In a similar vein, if you wished to see the differences between four headings, you need to retag a paragraph instance on a page to note the differences.

Regular FrameMaker® employs “Designer” menus with multiple tabs: you must select a tab (e.g. font) to view one segment of a style’s formatting at a time.

Another stark contrast to MadCap Flare is that Regular FrameMaker® has no concept of “inheritance” with styles. In other words, each paragraph style is a unique entity which contains all of its formatting under a named style in a catalog. The same is true for tables and character-level styles.

Where is the source template? In Regular FrameMaker®, templates are not dynamically linked to books or documents. A manual import of styles from a designated document changes existing styles and adds new ones. An old workaround was to have an extra Reference Page in the “template” document which had a date and version number. This “I.D.” page could be overwritten with subsequent template imports.

This methodology for template import was not terribly different in Microsoft Word.

Inheritance in Flare templates

Because Flare “templates” are composed of industry-standard Cascading Style Sheets (CSS) vs. proprietary authoring software catalogs, many time-savers are available to the template designer. A key advantage is inheritance: you can specify your most common format values to an element like “p” for paragraph. All other styles that you modify or create only need to have the few values that are different from the “p” style.

Incidentally, Flare comes with an attractive set of CSS templates “out-of-the-box,” so you do not need to start with a “blank screen” when making your own styles. Sample projects are pre-populated with a sensible variety of topics to help get you started.

What you see is what you get

If you are new to a project in Flare, you can use a simple style window for applying styles. As indicated in the screenshot below, your style names have a permanent preview to help identify styles visually.

In the example below, the cursor is in a paragraph that has a “class” of “tip” applied to the [p] element, which is shaded in the structure bar to the left. A dark box around “p:tip” to the right, indicates the current style.

01 style preview

As with many traditional publishing solutions, keyboard shortcuts may be used instead of manual style selection from this window.

Preview Table Styles while they are defined

One of the biggest surprises and delights for me in Flare is Tables. I was not expecting this since Tables have been one of the hallmarks of Regular FrameMaker® since the early 1990s; that feature was way ahead of its time back then.

While defining a Table Style in Flare, you have a real-time preview of your efforts below the panel in which you specify values. This eliminates the need to create a temporary “sample” table in an open topic. For screen target formatting, you may specify column widths as a percentage or in pixels.

View Multiple Mediums while modifying styles

Now you can modify styles for multiple mediums and see values displayed side-by-side. This is especially useful for projects which may have a very different style for PDF output than various HTML outputs.

04 Multi Medium

New: Different Flare templates (CSS) for projects and topics

New to Flare 12 is the ability to apply CSS to individual Topics as well as Projects. For example, you may have a few topics which are heavy on Table Styles, and need additional or modified styles. The CSS with table styles applied to the project is overridden by the CSS specified for individual topics.

This enables you to reduce style choices in some templates, and also to control table styles from a separate location.

Progressive Disclosure via DHTML while authoring

Perhaps one of the biggest disparities between Regular FrameMaker and Flare is the ability to apply Dynamic HTML (DHTML) for text pull-downs etc., during the authoring process. In my FrameMaker days, this was achieved by importing Regular FrameMaker documents into RoboHelp, and inserting DHTML there. The “gotcha” was that if the FrameMaker files were linked, all of your DHTML efforts would be washed away if you updated the FrameMaker source file.

DHTML for text pull-downs or text expansion is necessary for progressive disclosure. Since HTML5 responsive layout is an increasingly common publishing target, you may wish to have a “Read More…” link to temporarily show/hide 2 or 3 paragraphs on smaller, hand-held devices. DHTML will become invisible in PDF with a few sensible steps in CSS for that target.

What about Print? Is all this magic just for screens?

Any product has some “baggage” via past limitations. Early versions of Flare used to be limited to print via publishing Word documents. Since 2008, PDF capabilities for Flare have been dramatically improved.

Two releases ago, Flare added highly sophisticated templates for PDF output, including multi-fold brochures that can be modified for medical labeling. As a result, MadCap Flare is definitely a full-featured authoring system for all of your print as well as screen publishing needs.

In conclusion

Here is a summary of my recent discoveries:

  • CSS-based style-sheets have a level of flexibility not found in traditional publishing solutions with proprietary, binary files for templates
  • Flare has many visual cues to assist authors and designers; for instance, the structure bar for re-ordering file components in an error-free manner
  • Tables capabilities are surprisingly powerful and compare favorably to traditional publishing
  • Flare project structure keeps your style sheets and resources saved in logically named folders which you can access “at a glance”
  • Flare moves you into a sensible, topic-based authoring model that does not mimic PDF display while you are authoring for multiple targets