We are all aware, from direct experience, that publishing target screens are shrinking. Along with it, all of us have experienced shrinking attention spans due to a daily waterfall of information and distractions. Ironically, one industry trend has been to promote DITA as a solution, although it often adds yet another layer of distraction: multi-layered structure that often includes unwanted or unused sub-components.
Where are we now in our journey?
In this final post of my 5-part series, I will review my “learning journey” with MadCap Flare now that I have completed formal training. Last week I took two eye-opening classes, which are also scheduled for the near future:
- MadCap Flare Responsive HTML5 Training Course, Web-based, June 14-15, 2016
- MadCap Flare Project Management & Team Authoring, Web-based, June 16-17, 2016
Having moved from “newbie” to “intermediate” expertise, my appreciation for the Flare publishing solution compared to traditional methods has increased exponentially.
With my new-found expertise, I would revise my definition of some of Flare’s most rewarding aspects in contrast to traditional publishing solutions like Regular FrameMaker®, as stated below.
Flare’s XML Editor is suffused with sensible, accessible structure, making it the ideal launching pad for content authoring or multi-stream publishing. The User Interface presents only essential menus for each task, making this space perfect for new content creation. Workspaces can easily be customized. Project topic components and resources (CSS style sheets, master pages, and conditions) are always a click away to the left of your workspace. Tools in the authoring space are not confined to those appropriate for PDF and Print only. DHTML for HTML5 is no longer a post-process inserted with a separate piece of software (RoboHelp).
During Flare’s regular authoring process, you may select and apply portions of text to apply DHTML for expanding text, toggles and pull-downs for progressive disclosure in HTML5.
Learning curve includes “letting go”
Having come from a couple of decades of heavy production in traditional authoring tools (Word, Regular FrameMaker®), I experienced a brief “period of adjustment” adapting to Flare. In many ways the more focused and efficient Flare workflow starts some processes in what initially feels like a reverse order:
- In Regular FrameMaker® you create chapters with headings, then use a book to generate a TOC that duplicates text in headings, much like Word.
- In contrast, you determine project folder structure to segregate topics in Flare first, then swiftly, but manually assemble a TOC (or TOCs) that serves as chief navigation drivers for online and print.
- Navigation in targeted output is much more versatile in Flare: for instance, you can modify the Top Nav template layout to have your colors and branding.
- The Word and Regular FrameMaker® model had document structure dependent on carefully and intelligently applied paragraph styles. Current paragraph style in FrameMaker® is indicated in lower left corner of workspace window or by bolding style name in an open catalog.
- Since Flare is based on “topic-based” authoring, each “style” that you add to a topic is affixed to a component, [h3], [table], [p] etc. Unlike DITA-based authoring tools, Flare provides you with an intuitive structure bar which enables swift selection and repositioning of topic components or elements.
Increased power with constant content re-use
I worked for Frame Technology prior to the Adobe acquisition and was present when text insets (externally referenced text) were introduced. This feature was primarily intended for the then-upcoming “Structure Builder”, which eventually became “FrameMaker®+SGML”, which morphed into the Structured FrameMaker® user interface available in today’s product.
Within Regular FrameMaker®, text insets have never been very solid. (Don’t take my word for it, search for “text inset” in FrameMaker®’s user forum.) Insets were designed for SGML or XML-type containers available today. As a result, Regular FrameMaker® does not have a real equivalent to snippets in Flare.
Snippets in Flare can contain subtopics (paragraphs with lists, tables etc.) Changing the source can change all instances. Snippets combined with variables provide unparalleled power to seamlessly produce multiple versions of documentation.
Beyond conditional text
Flare has conditions which loosely parallel conditional text in FrameMaker®. I’ve discovered Flare’s version to be more versatile for a variety of reasons. But functionality is extended beyond traditional conditions.
In my most recent training course, I discovered how to apply style “classes” (think sub-styles) to an alternate term or phrase. This can be combined with a “display” property in a medium (Desktop or Mobile) that will cause an instant “show/hide” to dynamically alter a term or phrase when the target screen is reduced to a certain pixel width.
In the screen captures below, the first shot is output at desktop width; “click” is dynamically replaced with “tap” when the screen is reduced to mobile width, as shown in the second screenshot.
This one simple technique of combining style classes with a medium can save hours or work planning multi-layered conditional text expressions in Regular FrameMaker®’s more traditional model.
Beyond Flare: MadCap Analyzer
It has been impossible to cover every advantage that Flare has over traditional publishing, due to word count limits on this type of blog post. My journey will now continue through the suite of MadCap solutions beyond Flare, found in the economical MadPak Professional Suite.
Our latest webinar this week was “Why MadCap Analyzer May Soon Be Your Best Friend” by Jennifer Morse. (Click on the title in previous sentence to view the recording.) This tool provides reports and corrective action on steroids. With Analyzer, you can:
- Locate format overrides, and suggest existing styles to apply. You can apply to multiple instances in one step.
- Unused Content Report: This huge time-saver will prove to be a gold mine for anyone doing translation. Analyzer can display all instances of unused content, which often includes artifacts left over from earlier imports or deleted topics. Unused content can add up to dozens or even hundreds of billable translation hours.
- Snippet and Variable Suggestions: Analyzer locates phrases and text that exactly match snippets and variables in your project, and allows you to replace all instances with a single click.
- Frequent Segments: This powerhouse feature locates multiple instances of identical text that should be snippets or variables. You can convert such phrases into a new snippet or variable in a single click.
- Potential cross-references: Where has this feature been all my life! This feature identifies text that is essentially a “text-only,” unlinked cross-reference. Once again, a single click will convert one or all instances into “real” linked cross-references. Cross references are considerably more dynamic than plain hyperlinks and are often used hundreds of time per project. Because cross references are updated when target text is translated, this is another feature that can considerably reduce billable, post-translation cleanup with your Language Service Provider.
Key takeaway: automation not possible in traditional publishing
In contrast to Word and Regular FrameMaker®, complex (and sometimes fragile) macros or scripts are not necessary to achieve unprecedented automated project management. Since Flare was intended for multiple publishing targets from its inception, there are a host of power-publishing features here unheard of in traditional publishing.
Now that I’ve completed my initial goals with this blog series, l will be moving into far more advanced features, or less commonly used Flare features, like file tags. Whatever I discover, you can count on an element of wonder and surprise. Twenty years of typing on pixel paper (with or w/o DITA) doesn’t fade away overnight.