Flare Key Features
Flare has many features in it. Over time, you will find that some of these are more important to you than others. Following are some important characteristics of Flare, including key concepts and features that are especially important for most authors and ones that you are likely to use.
Following are some general key concepts and features in Flare.
In Flare, content is authored in XHTML (Extensible Hypertext Markup Language), which is a cross between XML and HTML. XML is a standard developed by the World Wide Web Consortium (W3C) and is intended as a replacement standard for HTML to render documents on the World Wide Web. XML is not a fixed set of elements like HTML, but rather a metalanguage (a language for describing languages). It enables authors to define their own tags.
For anyone unfamiliar with XHTML, this might sound intimidating at first. But even if you do not know anything about XHTML, XML, or HTML, you can create your content in Flare's main content editor (the XML Editor) in much the same way you would use a tool such as Microsoft Word. The XHTML markup is automatically created for you behind the scenes.
If you happen to be experienced with XHTML, you will be glad to know that you can work in the markup, taking advantage of all of the benefits of this structured language.
One of Flare's biggest strengths lies in single-sourcing, which means to reuse content, producing multiple outputs from the same set of source files. Flare lets you single-source your projects in many ways, using various features, including (but not limited to):
In other authoring tools, you’re probably used to everything being a part of a single file—the content, the table of contents, the glossary, the styles, and so on. It’s not like that in Flare. Instead, most of the pieces are separate, sort of like building blocks. This is one of the things that helps to make Flare so powerful and give you so much flexibility in how to create your output.
Your content is stored in topic files and in smaller snippet files. And images exist as separate files and are included in topics and snippets by reference. Your table of contents is a different file, as is the glossary. The styles are stored in a separate cascading stylesheet file. In fact, you might even have a project with multiple TOCs, multiple glossaries, and multiple stylesheets. It all depends on how you want to work.
Indexes are different because they are created in part by inserting index keywords into topics and snippets. There is no separate index file in the Flare project. However, for the most part, you’re dealing with separate files as building blocks in Flare.
Then you use another file called a “target”
Topics are where you type your text and other content
But don’t make your topics too short either. We’re not necessarily talking about single sentences or short paragraphs. You want your topics to have enough substance to stand on their own, but short enough to be able to easily reuse them in different places in various outputs.
All files in a Flare project are separate XML documents. This means that Flare projects are completely open, transparent, and accessible. One great benefit of this is easier customization of your project and files via scripting.
Note: Although it is possible to open any Flare files in a third-party editor, it is recommended that you avoid editing these files in certain programs while Flare is running. For example, opening a stylesheet in Notepad++ is not an issue. But you might experience problems if you open a topic or snippet in Microsoft Word and edit it while Flare is running.
A schema is a collection of metadata that describes the elements in an XML document. Flare‘s document schema is a hybrid between XSD (XML Schema Definition) and a custom schema created by MadCap Software to account for the unique tags and styles required to support all of Flare’s features. Therefore, the Flare schema conforms to industry standard requirements, recommended by the World Wide Web Consortium (W3C). This means Flare content can be edited in the Flare XML Editor, in external editors, or transferred back and forth between the two at will. Also, because Flare's code adheres to the W3C specification, it is easier to integrate with other XHTML applications.
Following are some key authoring features in Flare.
A cross-reference is a navigation link that lets you connect text in one topic to another topic (or a bookmark within a topic). This is somewhat similar to a text hyperlink. However, cross-references are more powerful in that the links can automatically be updated based on commands (e.g., appears as a text link in online output, but page numbers in print-based output).
The best practice is to use cross-references to create links between files and locations inside a Flare project, and hyperlinks are preferred for links that point outside of the project (e.g., websites, external PDFs). There are exceptions to this, but most of the time this is the recommended approach.
In Flare there are many ways to link one file to another, such as inserting a cross-reference or text hyperlink, inserting an image, applying a stylesheet to a topic, and more. The Link Viewer window pane (View > Link Viewer) lets you see how your different files are connected and may be one of the most useful tools you use in Flare.
A snippet is a chunk of formatted content that is heavily used in single-sourcing. Snippets can include text, tables, images, and whatever else can be included in a normal topic. You can insert snippets into one or more topics throughout your project, thus allowing you to reuse content that is maintained in one place. You can even insert them into other snippets, creating nested snippets. Snippets are not usually intended for single words or very short phrases. In those cases, you probably want to use variables instead.
The major benefit of using snippets is that you only have to create your content once, rather than having to type the same information in each topic where you want to use it. If you need to modify the content of a snippet, you only need to change it in one place and the change is made automatically in every topic where the snippet has been inserted.
A variable is a brief, non-formatted piece of content that can be edited in one place but used in many places throughout your project. They're especially good for text that might change frequently, such as version numbers and dates. Variables are stored in variable sets, which can hold multiple variables.
You can insert images into
You can embed Flash, Windows Media, Quicktime
Also, numerous multimedia files are supported in PDF output. This means that those files play when viewing the PDF in electronic format. If you print the PDF, those files are simply displayed as static images.
A condition is a single-sourcing feature that you can apply to files or to different areas of your content, so that some information displays in some outputs but not in others. For example, maybe you need to produce both online and print-based output. Much of the content you create is going to be the same for both outputs, but some of it is going to be written only for online output, and some only for print-based output. So you can create condition tags for each and use those tags to separate the content when you build your output.
Creating and editing a table of contents file in Flare can be very easy to do for both online and print output. You can drag topics from the Content Explorer to the TOC Editor. You can also manually add TOC books and items, and then link them to other files. The links usually point to topics, but for online outputs they can also point to external files, other Help systems, and movies. You put all of these books and items in a structure that you think would be useful for the individual. In online output, end users browse through a TOC to find information. And in HTML5 Side and Top Navigation output, the TOC items become links in menus.
The TOC files you see in the Project Organizer work differently for online output than they do for print-based output. For online outputs, TOC files are exactly as their name suggests; they are files that create TOCs or menus in the output. But for print-based outputs, that same TOC file functions more like an outline. The element that actually generates a TOC in print-based output is called a “proxy,” which is inserted into a topic. You can manually create that proxy yourself, or you can select an option in the Advanced tab of the Target Editor and let Flare do it all for you. There are pros and cons for both methods.
Context-sensitive Help (CSH) is a way to tie your existing topics with specific dialogs or windows in a software application, or with simple web links created somewhere (e.g., on a website). This is done with a map ID. When users open a particular dialog or window in a software application, or click a web link, they can quickly open a topic pertaining to it.
Responsive web design (RWD) is a way to construct your HTML5 output so that the display is adjusted automatically depending on the device. Therefore, on tablets and smart phones, users will see a condensed look that is more appropriate for those devices, compared with larger monitors. You can get the same effect if you shrink your browser to a smaller size.
There are two areas where RWD can be applied: (1) skin and (2) content.
HTML5 Side and Top Navigation skins are always enabled for responsive output, but you can adjust some settings on the Skin tab in the Target Editor. For Tripane output, you can enable responsive output in the Skin Editor, and you can adjust the same settings as Side and Top Navigation output in the Target Editor. When a skin is responsive, the navigation elements are automatically adjusted depending on the size of the screen.
Styles and media queries can be used to make your content responsive in HTML5 output. This lets you present information—both its substance and structure—differently depending on the size of the screen or device. Flare provides a Responsive Layout window pane that helps you create this kind of content more easily. You also have the option of using third-party solutions (e.g., Zurb Foundation grid system) by adding the appropriate styles in your stylesheets and topics.
You can use the Preview window pane to see a quick preview for a topic, snippet, or master page. The Preview window pane is dynamic, allowing you to keep the preview open while you work and see changes as you make them in the XML Editor.
Initially, the window pane opens as a floating window. This can be quite useful if you are working with dual monitors, because you can drag the Preview window pane to one monitor while editing the topic in the other monitor. However, you always have the option of docking the Preview window pane to the interface.
See Previewing Topics.
Following are some key design features in Flare.
Styles are used in Flare projects to control the look and feel of your documentation, and keep the content separate from its presentation. Most of the styling is based on Cascading stylesheets (CSS), which is an international standard for formatting web content, developed by the World Wide Web Consortium (or W3C).
Flare lets you work with stylesheets in a number of ways. You can use a “master” stylesheet, automatically associating it with all files at the target level or project level (recommended). However, if you have some topics that you want to use a different stylesheet, you also have the option of associating those individual files with that other stylesheet. Once you’ve set up your stylesheet, you can apply its styles to the different pieces of content in your topics and snippets.
As much as possible, you should avoid the opposite of styles, which is local formatting. For example, you can highlight some text and make it green and italic right where that content exists. But if you make that same change in many places, it takes a lot longer and it's a lot more work to control the look of that content if you later change your mind.
In addition to using stylesheets for topics, you can use separate stylesheets in Flare specifically for tables inserted into topics.
For the differences between regular stylesheets, table stylesheets, and local properties—and when you should use one over the other—see Regular Stylesheets, Table Stylesheets, or Local Formatting?
A master page lets you apply certain content and elements (e.g., text, images, breadcrumbs, menus, toolbars, search bars) automatically to multiple topics in the output. A master page is primarily used in online outputs, but it can be used in Word output as well. For Word output, a master page lets you determine page specifications (such as size or orientation) and to apply certain content (e.g., header text or page numbers) to many topics in a manual. For print-based outputs other than Word, page layouts are used instead of master pages.
Let's say you want every topic in your Help system to include a footer with contact information about your company. Rather than having to type this content or insert a snippet in every topic, you can create a master page and enter the footer in just that one location. Then you associate the master page with any of the targets in your project. The footer is automatically included at the bottom of every topic when you build and view any of those associated targets.
A page layout is used for page specifications (e.g., size, margins) and to apply certain content (e.g., headers, footers, page numbers) to many (or all) topics in print-based output. It allows for easy configuration through the use of content frames, bleeds, crop marks, registration marks, margins, padding, alignment features, and more. See About Page Layouts.
Page layouts are similar to master pages, but are more flexible and easier to use. The general rule is that page layouts are recommended for print-based output, and master pages continue to be the best method for automatically adding headers, footers, and breadcrumbs in multiple topics for online output. Another difference between page layouts and master pages is that page layouts can be used for either Adobe PDF or Microsoft Word), whereas master pages can be used only for Microsoft Word when creating print-based output.
A skin is a file that contains information about the appearance of an online output window, including navigation elements. See About Skins.
Depending on the type of output, a skin can help to determine the following:
- Pane position
- Slide-out menu style
- Main menu position
- Top menu depth levels
- User interface text
- How big the output window should be and where it should be positioned on the user's screen
- Which online elements (e.g., TOC, index, search) are included in the output and which one should be the default element (the one that is active when users first access the output)
- And other settings…
Flare supports authoring and output for left-to-right (LTR) as well as right-to-left (RTL) languages. This includes English, French, German, Japanese, Chinese, Arabic, Persian, Hebrew, multi-byte languages, and more. Flare supports bi-directional languages not only at the topic level, but all the way down to the paragraph and sentence level.
There are multiple ways to produce output in different languages. For example, you might translate content directly in a Flare project, perhaps creating a different topic for each language. Alternatively, you can send the Flare files to a translator, who can use a CAT (computer-assisted translation) tool in order to translate the text strings. MadCap Lingo can be used as a CAT tool or for project management, packaging your Flare files to be sent to a translator, who uses a third-party CAT tool for the translation.
There are several ways that you can import files into Flare projects.
Three of the most common types of imported files are Word, HTML, and FrameMaker files.
- Word You can import Microsoft Word documents, including DOC, DOCX, and RTF files. Flare tightly integrates with Word, using modern XML data flow techniques and leveraging the Microsoft XML Schema for Office documents. This allows for superior content fidelity during import.
See Importing Word Files.
- HTML You can import HTML files, automatically converting them to XHTML.
See Importing HTML Files.
- FrameMaker You can import Adobe FrameMaker documents, including BOOK, FM, or MIF files. Because you can import the source FrameMaker BOOK and FM files (rather than just MIF files), Flare has full access to FrameMaker variables, conditionals, autonumbering, and so on. This means that those features are converted to Flare seamlessly.
See Importing FrameMaker Files.
You can export an entire Flare project, or parts of one, to another location. One reason you might want to use this feature is to quickly and easily archive projects, especially if you have an extremely large Flare project and need to archive only parts of it. Another use for this feature is translation. If you only need a portion of a master project to be translated, you don't want to send the translator all of the files, but rather a smaller version of the project containing only the files requiring translation.
Flare supports multi-channel publishing, which means you can draw from a common set of source files to generate and publish output in multiple formats. This helps to ensure your content is accessible to end users, wherever they are, and however they prefer to consume the information.
Although you have many choices about the kinds of output you can generate, following are the most popular and recommended formats.
HTML5 This output format supports the HTML5 specification developed by the Web Hypertext Application Technology Working Group (WHATWG—http://whatwg.org) and the World Wide Web Consortium (W3C—http://w3.org). Therefore, the HTML5 format results in better markup and offers additional features not found in the WebHelp outputs in Flare. HTML5 also lets you create traditional Tripane output or the newer Side or Top Navigation outputs, which give your output the appearance of a modern website with integrated responsive skins and content. In addition, HTML5 lets you use advanced server-based features (e.g., searching of non-XHTML files) that are also available with WebHelp Plus.
See About HTML5 Output.
Adobe PDF Short for "Portable Document Format," PDF is an open standard format for electronic documentation exchange invented by Adobe. PDF files are used to represent a two-dimensional document in an device- and resolution-independent fixed-layout format.
You can generate PDF output from your project directly, or you can generate a PDF while simultaneously building Word output. See About PDF Output.
Microsoft Word The output can be exported to Microsoft Word in various file formats.
See About Word Output.
For HTML5 targets, you can choose the type of search engine you want people to use—MadCap Search, Google Search, or Elasticsearch (for Side Navigation, Top Navigation, or skinless output). There are additional steps that you can follow and features you can select, depending on the search engine you choose. For MadCap Search and Elasticsearch, you can include micro content in the output, which can especially enhance your search results.
With some extra effort and scripting outside of Flare, you can also use micro content for other advanced purposes, such as chatbots.
Flare provides several features that can be used to manage your project and enhance team authoring.
Flare lets you scan your project to find and fix issues, as well as create reports that display the information captured on the scan.
You can generate custom reports based on the information contained in your project, for just about any type of information that the analysis tool captures. In addition, you can design the look and feel of reports, save them for future access, and open them in a browser window (where you can print them).
You can import content and project files contained in another Flare project, thus allowing you to maintain the information in one location but reuse it in any other project. When you use this feature to import files, you can include or exclude particular types of files (e.g., topics, snippets, stylesheets, glossaries, targets), specific individual files, or files that have certain condition tags applied. Simply use the include/exclude methods that work best for you.
This is different than a simple import process, because in this case, the imported files remain linked to the source project. This allows you to make future updates to those files in just one place—in the parent project. When you perform ongoing imports using your previous settings, Flare recognizes changes to the source files. Therefore, the new files can be brought over, replacing the outdated ones.
MadCap Central is a cloud-based platform that lets you plan, track, and manage the processes, content, and teams that are at the heart of your organization. MadCap Central's integration with MadCap Flare lets you store copies of your projects in Central, continue to work on them locally in Flare, and keep both sets of copies in sync. You can use Central to quickly build and publish output (and roll back when necessary) without the need to involve an IT department. You can also send topics and snippets for review on Central, as well as use custom checklists to track your progress in Flare projects.
The MadCap Central window pane in Flare lets you upload (bind) and import projects, as well as push project changes to Central. Additionally, you can see project properties, log in and out of your Central account, and launch the Central portal in your browser.
Note: For more complete information about the benefits of Central, see its online Help:
Note: MadCap Central is sold separately from Flare. Please contact MadCap Software Sales for more information.
There are a couple of processes that you can use for Flare topic reviews and collaboration.
- Central Reviews (Recommended) The Central review process lets you send Flare topics and snippets to be reviewed by subject matter experts (SMEs) or other Flare authors on MadCap Central. After making edits and adding annotations (comments) to the files in a lightweight editor on Central, the reviewers submit the finished files, sending them back to your inbox in Flare. You can then accept or reject their changes and accept the file, replacing the original source file.
Because this system uses the cloud, SMEs do not need to download any software to review your files. Also, multiple reviewers can edit the same file at the same time. See About the Central Review Process.
- Review Packages The review package process lets you send Flare files for review, as well as receive file contributions from, SMEs and other Flare authors. Non-Flare users can download a separate application called MadCap Contributor when collaborating with you and your Flare project. You can also use the same features to send files for review to other Flare authors using Flare only.
See About the Review Package Process.
Note: If you do not choose to use either of these systems, you can always generate output—such as PDF or Word—and send those files to your reviewers. However, although this can be an easy method, it is also more manual and means that you need to copy and paste the changes into your source Flare files.
Flare supports integration with Microsoft SharePoint (software that allows organizations to collaborate, share files, and publish information to the Web). After connecting to a SharePoint server, you can access and edit the SharePoint files from Flare.
One of the ways Flare supports team collaboration is that you can create mappings to external resources. The External Resources window pane lets you select and maintain groups of external files that you want to share among Flare projects. The paths of these files are written to the registry so they will be available for all your Flare projects.
Because all content and project-level files are stored as separate XML files, projects are compatible with all source control systems. All files in a project are independent of one another, which means that there are no file dependencies that hinder multiple authors from accessing project files. Flare also provides built-in support for Microsoft Team Foundation Server, Perforce, Git, and Apache Subversion. Also, if you integrate MadCap Central with your Flare project, you can use Central as a source control solution, with Git working behind the scenes.