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 features that are especially important for most authors and ones that you are likely to use.
Following are some general key features in Flare.
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. This includes features such as topic-based authoring, conditions, snippets, variables, multiple tables of contents, and more.
In Flare, content is authored in Extensible Markup Language (XML). This 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 XML or HTML, this might sound intimidating at first. But even if you do not know anything about 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 XML or HTML, you will be glad to know that you can work in the markup, taking advantage of all of the benefits of this structured language.
Topics are not the only Flare documents that use XML. All Flare files are separate XML documents—topics, TOCs, browse sequences, targets, skins, snippets, glossaries, destinations, condition tag sets, variable sets, and more. This means that Flare projects are completely open, transparent, and accessible.
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.
Flare content conforms to industry standard schema requirements from the World Wide Web Consortium (W3C). Therefore, Flare content can be edited in the Flare XML Editor, in external editors, or transferred back and forth between the two at will. Flare's code adheres to the W3C XHTML Schema specification, making it easy to integrate with other XML or XHTML applications.
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 separately as image files and are included in topics and snippets by reference. Your table of contents is a different file. The glossary is yet another file. 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.
As far as indexes are concerned, they're 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.
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 it in different places in various outputs.
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. You can also convert cross-references to elements such as page numbers for printed output.
You can also take advantage of context-sensitive cross-references, which are especially designed for generating print-based output. When you use a context-sensitive cross-reference, the text automatically changes based on the relationship of the link and the target location if they are on the same page or only one page away.
Let's say you have a cross-reference designed to display the text "See Figure 2.1." If the link and the target fall on the same page, the cross-reference is updated to display the text, "See Figure 2.1 above" or "See Figure 2.1 below." If the link and the target are on adjacent pages, the cross-reference is updated to display the text, "See Figure 2.1 on the previous page" or "See Figure 2.1 on the next page." If the document is double-sided with the link on the left page and the target on the right page, the cross-reference displays the text, "See Figure 2.1 on the facing page."
In Flare there are many ways that you can link one file to another, thus creating a dependency. Link dependencies are created when you perform tasks such as: inserting a text hyperlink, inserting an image, applying a stylesheet to a topic, and more. The Link Viewer window pane lets you see know how your different files are connected and may be one of the most useful tools you use in Flare.
A snippet is an important file used for single-sourcing that acts sort of like a miniature topic. In a snippet, you can insert and format text, tables, pictures, and whatever else can be included in a normal topic. We’re not usually talking about single words or phrases; that’s what variables are for. A snippet can be inserted into one or more topics throughout your project. You can even insert them into other snippets, creating nested snippets.
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 everywhere that the snippet is added.
Variables are brief, non-formatted pieces of content (such as the name of your company’s product or phone number) 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
When you insert images into Flare content, you can specify that the images should be displayed as thumbnails (i.e., much smaller versions of the image) in the output. This is a way to condense topics so that images are not taking up as much real estate. When you use this feature, you can specify ways that the user can enlarge the image to see its full size (e.g., by hovering over the thumbnail, by clicking the thumbnail).
Capture is MadCap's screen capture and graphics editing application. From within Flare, you can launch Capture, add or insert a new screen capture, and edit images. Capture contains many unique features that are especially useful for online documentation authors, including the ability to single-source images in Flare projects. For a single image, you can provide one group of settings for online output, and another group of settings for printed output.
You might want to use a resolution of 150 DPI for images that appear in your regular topic content, but a resolution of 300 DPI for images that appear in full-color brochures, which require more detail during printing. Rather than creating two separate images and using condition tags, you can use this feature.
You can also single-source images when resizing them in Flare. This can be done through the use of styles (applying the settings to many images at once) or local formatting (applying the settings to one image). When you generate one kind of output (e.g., HTML5), the image will be displayed in one size, and when you generate a different type of output (e.g., PDF), the image may be displayed in another size.
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 something that you can apply to different areas of your content so that some sections show up in some of your outputs but not in others. This is where Flare gets really powerful. 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 them to separate the content when you build your output.
You can take advantage of cascading stylesheets (CSS files) and the rules around them to control the look of your output in one place. This helps to keep the content separate from its presentation, which is very important when it comes to single-sourcing. CSS isn’t a MadCap Software idea. It’s an international standard for formatting web content, and it was developed by a group called the World Wide Web Consortium (or W3C). You can learn all about the W3C at w3.org.
Flare lets you work with stylesheets in a number of ways. You can associate stylesheets with individual topics (you might do this if you need to have multiple stylesheets for your output), or you can use a "master" stylesheet, automatically associating it with all files at the target level or project level. Then you apply the styles from the stylesheet to the different pieces of content in your topics and snippets.
The bottom line is that you want to avoid the opposite of styles as much as possible. That's called "local formatting." For example, you can highlight some text and make it green and italic right where that content exists. But if you do that same thing 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. Instead, it's much smarter and better to use a style.
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 Properties?
You can create and use both mediums and media queries in Flare. The two concepts are very similar; in fact, you will see them side by side in different places in Flare's user interface. However, mediums and media queries are not the same. So what is the difference between a medium and a media query?
- Medium A medium is an alternative group of settings in a stylesheet and can be very useful when you are generating multiple kinds of outputs.
Unless you tell Flare otherwise, default style settings will be used for the different outputs you generate. But there may be times when you want to override a default style setting for a particular output; that's why you would use a medium. You need to explicitly tell Flare which medium you want a particular target to use. This is done from the Advanced tab of the Stylesheet Editor.
- Media Query A media query is an alternative group of settings in a stylesheet. These settings are automatically used under certain conditions, such as when a screen of a certain size is displaying the output. Media queries are able to do this because they are configured with specific criteria (e.g., maximum width of the screen, orientation, resolution). When the criteria are met, the style settings in the media query are used to display the output. You do not tell a Flare target to use a media query; it just happens automatically.
Creating a table of contents 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 Top Navigation output, the TOC items become links in menus.
You have the option to customize your TOCs in lots of ways, getting as fancy as you want. However, there are some things you should know. Most importantly, you need to understand that 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.
You can see both online and print TOCs in action by looking at Flare's many project templates on the Start Page. Typically, the templates labeled as "Basic" use the easy auto-generation method for creating print TOCs
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 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 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. 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 (most notably the Zurb Foundation grid system) by adding the appropriate styles in your stylesheets and topics.
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, double-byte languages, and more. RTL languages are supported in all outputs except DotNet Help and FrameMaker. Flare supports bi-directional languages not only at the topic level, but all the way down to the paragraph and sentence level. If you have a sentence containing both LTR and RTL languages, Flare will treat each of them appropriately in that sentence.
Following are a few of the most important things to know about language support in Flare.
You can select a language for a project, target, topic, or even specific content. Selecting a language affects spell checking as well as the language skin used.
A language skin can be used to display the interface in a specific language for online outputs. Language skins hold only text used for the output; they do not control the look of the output. To control the appearance of the output, you must use a regular skin in addition to the language skin.
One of the easiest ways to translate a Flare project is for a translator to open that project within MadCap Lingo, which is tightly integrated with Flare. Because of this integration, there is no need to transfer localized files outside of the actual project, which helps prevent content and formatting corruption. In addition, translators can leverage all previous translations created in other tools by importing Translation Memory eXchange (TMX) files.
After opening your project in Lingo, a translator can immediately see a list of all of the files (e.g., topics, snippets, variables), index markers, and concepts that need to be localized. Then, after translating the content in the Lingo interface, the translator can export the results to a new Flare project in that language. For more information, please refer to the documentation provided with MadCap Lingo.
If you have translated your project into other languages, you can link Lingo projects or additional translated Flare projects to your master project to create multilingual output
There are several ways that you can import files into Flare projects.
The two most common types of imported files are FrameMaker and Word documents.
- FrameMaker Documents 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.
- Word Documents You can import Microsoft Word documents, including DOC, DOCX, and RTF files. Flare tightly integrates with Word (including Word 2007), 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.
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.
See Exporting Projects.
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.
There are many output options available in Flare. You can produce output in online and print-based formats, drawing from the same source files.
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 Top Navigation output, which gives 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 FrameMaker or Word output. See About PDF Output.
Microsoft Word The output is exported to Microsoft Word in one of the following file formats.
See About Word Output.
- XML This is the default document format created (if you do not select one of the other formats in this list).
- DOC You can export Word to the standard DOC format.
- DOCX This is Microsoft Word's platform-independent, open XML format.
See Specifying DOCX Output Via Microsoft Word.
- PDF In addition to sending output directly to PDF, you can generate a PDF file automatically when building Word output. Because Flare supports Microsoft Vista and Word 2007, you can send Word output to PDF format, even if you do not have the Adobe Distiller installed.
See Specifying PDF Output Via Word or FrameMaker.
- XPS In addition to sending output directly to XPS (as described above), you can generate an XPS file automatically when building Word output. You can do this by installing a free add-in download from Microsoft.
See Specifying XPS Output Via Microsoft Word.
Flare provides several features that can be used to manage your project and enhance team authoring. Following are some of the most commonly used project management features.
Analyzer is a tool that lets you scan your project to find and fix issues, as well as create reports that display the information captured. There are two versions of Analyzer—internal and external. To take full advantage of the power of Analyzer, you must purchase the full external version, which provides access to all of the features. The internal Analyzer is a lighter version that is built in to the Flare interface, allowing you to use some Analyzer features.
You can generate custom reports based on the information contained in your project, for just about any type of information that MadCap Analyzer 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 source project file. 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 files.
Let's say you are working on three different Flare projects. Within those projects, you might have 35 topics and 50 images that are identical in the three projects. In addition, you might use the same stylesheet in each project. Rather than maintaining three different sets of identical files, you can store one set of those files and import them into the individual projects when needed. Here are a couple of options: (1) One option is that you could consider one of your three Flare projects as the "global parent" for those shared files. (2) Another option is that you could create a new Flare project (perhaps naming it "global"); this project could have no other purpose than to serve as a repository for the shared files across your projects. In other words, you would not necessarily generate any output from this parent project, but simply use it as a place to hold your shared information.
When you want to use any of the shared topic, image, or stylesheet files from the global project, you would import them into the child project. This creates a link between the imported files and those in the global project. Therefore, when you edit those files in the future, you would do so from the global project and then re-import the changes (either manually or automatically) to the other child projects.
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. Although MadCap Central is located in the cloud, it is integrated with MadCap Flare. This integration 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 publish output (and roll back when necessary) without the need to involve an IT department. 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—http://help.madcapsoftware.com/central/.
Note: MadCap Central is sold separately from Flare. Please contact MadCap Software Sales for more information.
By integrating your output with MadCap Pulse, you can involve an audience in your output, communicating with them and observing how they are using your documentation. Pulse is a documentation-centric social collaboration platform that enables you to connect, collaborate, and share knowledge with fellow authors, employees, and customers. With advanced socially-enabled features, Pulse helps maximize the value of social collaboration and enhance the quality of your documentation.
Note: MadCap Pulse is sold separately from MadCap Flare. Please contact MadCap Software Sales for more information.
Flare supports close collaboration between authors and others through the use of file reviews and contributions.
- Reviews You can email review package files containing topics and/or snippets to other individuals for their feedback and/or changes. Alternatively, you can use SharePoint integration or the external resources feature to store the review package files. The reviewer's changes are always automatically tracked so you can see what edits were made. After inserting annotations (comments) or making changes to a file with Flare or with Contributor (for non-Flare users), reviewers can send the package back to you. You can then view those comments and accept or reject the edits so that they are added to the source file(s).
- Contributions Authors, developers, or other individuals in your company can use Contributor to create new documents and files, which can be incorporated into your Flare project.
Flare supports integration with Microsoft SharePoint. If your company uses Microsoft SharePoint (software that allows organizations to collaborate, share files, and publish information to the Web), you can connect to a SharePoint server. Doing this makes it easy to access and edit the SharePoint files from
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 integrated support for version control applications. Built-in support is available for Microsoft SourceSafe, Microsoft Team Foundation Server, Perforce, Git, and Apache Subversion. In addition, the Microsoft Source Code Control API (SCC API) allows you to configure your project for integration with other version control tools.
See About Source Control.
See About Templates.