Category: Software

New Portfolio using FlareNew Portfolio using Flare

Posted January 18th, 2008 by paul.
Category: MadCap Flare, Software, TW Tools, Technical Writing | Leave a Comment »

For those of you who are interested, today I released a new version of my online work portfolio. The content is pretty similar to the old portfolio, however there is a totally new layout and the back end is completely different.

I’ve migrated my entire portfolio site to use MadCap Flare. I know that Flare is usually considered a help authoring tool, and an online portfolio doesn’t really fit into the category of help, but I decided Flare was the best tool for my project because I wanted the following:

  • Multiple outputs. An online portfolio is great, but the truth is that often times when I need to present my portfolio, I am going to want to be able to provide it in a hard-copy version. Since my source files are in Flare, I can create one target that publishes my portfolio to my website and another target that publishes it to a Word or Framemaker document.
  • Output conditions. Ideally a portfolio is customized for a specific situation. Since my source content is in Flare, if I want to create a customized version of my portfolio for a particular audience, it is as simple as adding conditions to my topics, and creating a new target. In addition, if I don’t want to include links to my resume or writing samples, I can create one output type that excludes this information, and another output type that includes it. I can publish the limited-info version on my website, but publish the full-information version to a CD that I can give to people.
  • Resume single sourcing. This part isn’t complete yet, but I realized that on my old portfolio site, I had several different versions of my resume that I was always updating to keep them current. That was kind of a pain, plus I had to keep all versions of my resume behind a “locked door” so-to-speak, as to keep private information private. With Flare, I’ll be able to create one version of my resume, conditionally exclude private information for the website, and create as many outputs as I need–all from the single file.

You’ll notice that my new site doesn’t have the frameset that is a standard part of Frame’s WebHelp output. I didn’t need the frameset because I don’t need the same functionality as I would for a help system. I could have modified my Flare skin so that the tool bar was only 1 px high and the sidebar was hidden by default, but that still loaded the site in a frameset, which I didn’t really like, so I set up HTTP redirection to take you directly to the topic page.

If you are interested in how I created the layout, I did all the layout in a Master Page. The layout is entirely CSS-based (as opposed to using tables for layout) which makes the site more accessible and standardized. (If you know how, try disabling the attached style sheets to see what I mean.) The images were all added to the style sheet, but I ended up inserting the banner image into the template’s HTML file so I could do an image map (which makes the words on the right side of the image links to the various sections).

In the end, I’m pleased with the new site. It gives me the flexibility to publish my portfolio in multiple media types with slightly different content for each target while maintaining only a single source for all my documents. Flare was a great choice for this project, even if it is an unconventional use for the tool.

Flare Tip: Quick LinkingFlare Tip: Quick Linking

Posted December 5th, 2007 by paul.
Category: Software, TW Tools, Technical Writing | Leave a Comment »

I stumbled across a cool feature in MadCap Flare v3.1 the other day. I doubt this is a new feature; rather, it is one I just didn’t know about.

There are several ways to create links in Flare, some easier than others. Normally, you would just chose an insertion point in your topic, then from the Insert menu, click Insert Hyperlink (or you could use the Ctrl+K key combination).

Today I want to talk about the following link creation shortcuts:

  • Dragging links
  • Context menu linking

Dragging links

If you want to insert a link from one Flare topic into another topic, the quickest way to add the link is to drag the target topic from the Content Explorer into the Topic in the XML editor.

Say you are editing TopicA.htm and you want to link to TopicB.htm. Open TopicA.htm in the XML editor. Find TopicB.htm in the Content Explorer. Drag TopicB.htm from the Content Explorer into the XML editor, dropping it where you want the link to appear. A dialog box will allow you to modify the settings for the link. Click OK and the link is inserted into your topic.

This is especially useful if you are linking to a topic in a different folder in the Content Explorer, since using the Insert Hyperlink dialog box to locate a file in a different directory is kind of a pain.

If you want to add a hyperlink to text that already exists in your topic, you can highlight the text, and then find the target file in the Content Explorer, and drag it to the highlighted text. The highlighted text will turn red before you drop the link on it, so you know it has been selected. You will see the Insert Hyperlink dialog box. Click OK and the highlighted text is changed to a link.

I only wish there were an easy way to make these into cross-references, instead of hyperlinks. What I’d like to see here is a Ctrl+drag combination or a right-click+drag combination that would insert a cross-reference to the topic, rather than a hyperlink. I guess I’ll submit a feature request.

Context menu linking

There are several options in the context menu for inserting hyperlinks and cross-references. (Unfortunately these don’t work properly when you are modifying text the MadCap:Drop-down-body element.)

flare-xml-editor-context-menu.jpgWhen you are working in a topic in the XML editor, you can use the Context Menu to quickly create links and cross-references; the process is the same for both.

The Quick Link and Quick Cross-Reference options allow you to easily link to topics in the same folder, topics that are open, or bookmarks in the current document.

To use the Quick Link / Quick Cross-Reference functions, open your topic in the XML editor. Right click at the location where you want to insert the link (or cross-reference). The context menu appears (shown above).

For Quick Links, you can insert a link to a bookmark, a topic in the same folder, a new topic (that you will create by selecting this option), or to any topic in the project (a window will appear so you can browse to the topic).

For Quick Cross-References, you can insert a cross-reference to a bookmark, a topic in the same folder, or an open document.

flare-xml-editor-quicklink.jpg

Often, when I’m creating a cross-reference to a topic in a different folder, I’ll open the topic I want to cross-reference to, then open the source topic and insert a quick cross reference. The only problem with this method is that you don’t see the Insert Cross-Reference window, so you can’t pick the cross reference properties. I have three different cross reference styles, and the Quick Cross-Reference feature uses the default one. (I actually don’t understand why this doesn’t work in parallel with links; when you insert a Quick Link, you get the Link Properties window, but when you insert a Quick Cross-Reference, you don’t get the Cross-Reference Properties window. )

There is your Flare tip on easy methods for inserting links and cross references—allowing you to author your help content more efficiently.

Content Reuse Wrap up: Putting it all togetherContent Reuse Wrap up: Putting it all together

Posted December 1st, 2007 by paul.
Category: Software, TW Tools, Technical Writing | 2 Comments »

(This is part five of a five-part series dealing with content reuse in the Help Authoring Tool (HAT) MadCap Flare version 3.1.)

Review

It’s time for a brief review: When we talk about content reuse, we mean writing content once and then creating multiple outputs from that single source of content. Flare is a help authoring tool created by MadCap Software that allows you to single source your content in powerful ways. Flare includes tools for using variables, snippets, and conditional text to create a powerful source from which you can create multiple output targets.

Variables are small strings of text that you can replace for an entire project, and can even change for individual targets. You might include your product name and version as a variable. When this information changes, you can change the variable definition, and the project is instantly up-to-date. Snippets are like large variables. They are actually entire XML files that can include images, text, formatting, etc. You can use snippets for chunks of information that you re-use in multiple topics in your project. When you need to change that information, you change the snippet file, and all the topics that include that snippet are instantly updated. Conditions allow you to mark content (all the way from the character level up to the entire topic level) with conditions. When the project is built, you can include or exclude content marked with those conditions. For example, you can have one topic that includes some information or terms used in printed output, and other terms or information for use in online output.

Project Application

Today I thought I’d talk about a fictional project and show how with proper use of content reuse tools you can create several distinct outputs from a single source of text.

Suppose you are writing a user guide for a product we’ll call Widget. You give a basic version of Widget away for free, but you have a version of Widget called Widget Plus that requires a subscription. You have an OEM agreement with another company, and they bundle Widget Plus with their application, but they call it Super Widget. (For this example, we’ll assume the content in Super Widget is exactly the same as the content in Widget Plus; the branding, colors, and product name are the only differences. We’ll refer to these two versions as the advanced version of the application.)  All three versions have online (F1) help. Widget Plus and Super Widget also have printed guides (provided in PDF format).

In an old-school style help system without tools for content reuse, you would probably have to create several different projects; You’d need:

  • Online help system for Widget
  • Online help system for Widget Plus (with added functionality and Widget Plus name)
  • Online help system for Super Widget (with corporate branding of affiliated company)
  • Text-based project for Widget Plus
  • Text-based project for Super Widget (with corporate branding of affiliated company)

You recognize that these five outputs contain sections that are very similar (or even the exact same content in some cases, with just the name changed) but you end up maintaining five separate projects because you need five separate outputs.

Single sourcing with Flare (or another similar HAT) means you only need one project. You add all the content to the one project, and you just create five different output targets. Then you use the content reuse tools in your HAT to simplify the process.

In this project you would create two different TOCs and five different targets. You would want a TOC for the simplified Widget application, and a TOC for the advanced Widget Plus and Super Widget applications. You would create a separate target definition for each of the outputs I listed in the bulleted list above.

For this project you’d want to use a variable for the project name. Every time you reference the project’s name, you’d use the variable instead of Widget, Widget Plus, or Super Widget. In your topic you might see something like:

The Preferences screen allows you to customize the [variable:ProjectName] interface.Then, in each of the five target definitions, you’d update the variable definition. When each target is built, the proper project name is automatically inserted.

If you have chunks of content that you reuse in multiple topics, you can create snippets to allow you to reuse those content chunks across multiple topic files.

Then you would use conditions to customize your outputs.

For this project you might have the following conditions:

  • Basic
  • Advanced
  • PrintOnly
  • OnlineOnly

One way these conditions can be applied is to content within topics. The Preferences screen for the basic application may have fewer features than the Preferences screen for the advanced version of the application. You still only need one Preferences topic in your application. This topic includes all the features. The extra features can be marked at the paragraph level with the “Advanced” condition. The targets for Widget can be set to EXCLUDE the Advanced condition, and this advanced content is not included in the basic version’s help system.

You can also have text on the screen marked for online output only, with other content marked for printed output only. You might have the following text:

This [condition:print]guide[/condition][condition:online]help system[/condition] documents [variable:ProjectName].

The online help systems can include the “OnlineOnly” condition and exclude the “PrintOnly” condition. The printed guides can include the “printed” condition and exclude the “online condition.

In our fictional project this one sentence can be rendered five different ways, depending on the settings in the target file:

  1. This help system documents Widget. (”OnlineOnly” condition, “Widget” variable definition.)
  2. This help system documents Widget Plus. (”OnlineOnly” condition, “Widget Plus” variable definition.)
  3. This help system documents Super Widget. (”OnlineOnly” condition, “Super Widget” variable definition.)
  4. This guide documents Widget Plus. (”PrintOnly” condition, “Widget Plus” variable definition.)
  5. This guide documents Super Widget. (”PrintOnly” condition, “Super Widget” variable definition.)

You can also apply these conditions at the file level. You might have a feature that is only available in the advanced versions. You can apply a condition to this topic in the Content Explorer, and that topic will only be included in the advanced outputs. (Your basic TOC wouldn’t include the advanced functions obviously, but for a WebHelp target, the actual files will still be copied over, and would be available in a search. If you exclude the topic however, the files simply won’t be included at all in the output.)

To get the branding right for the OEM-ed Super Widget, you might create an additional style.css file, separate masterpages for printed output and online output, and a separate skin for the WebHelp output. In the target definition files for the Super Widget targets, you would change the style settings, masterpage settings, and skin settings to use these Super Widget-specific files.

Conclusion

I hope you can see the power in single sourcing your content. The content reuse tools in MadCap Flare are powerful. You can use a single project for an unlimited number of outputs. Your imagination is your limitation.

This concludes my five-day series on content reuse in MadCap Flare. Feel free to share your comments with me, either as part of the posts in this series, or by contacting me via my contact form. You can also look for me in the MadCap user forums where I go by the name Doc-Guy.

Good luck single sourcing your content. It is worth the effort.

Content Reuse In-Depth: ConditionsContent Reuse In-Depth: Conditions

Posted November 30th, 2007 by paul.
Category: Software, TW Tools, Technical Writing | Leave a Comment »

(This is part four of a five-part series dealing with content reuse in the Help Authoring Tool (HAT) MadCap Flare.)

Now that we’ve covered variables and snippets in depth, I want to talk about another tool that Flare includes that makes content reuse possible: conditions.

Conditions are settings that are applied to content. When a target is built, that content will either be included in the target, or excluded in the target, based on the conditions. For example, you can have some content that only appears in online versions of your help, and different content that appears only in print version of your help.

You may want to include a simple procedure in your online help, but for the printed guide, include additional paragraphs of information. You use the same topic; you just mark the additional content with a print-only condition, and exclude the print-only condition in your online output.

Conditions can be applied at the character level, paragraph level, or topic level. That means that you can choose to include/exclude a character, a word, a sentence, an entire paragraph, a series of paragraphs, or an entire topic.

In my Flare projects, I typically use four conditions:

  • printOnly
  • onlineOnly
  • internalOnly
  • doNotDistribute

I’ve already addressed the print/online only conditions. My internalOnly condition is associated with internal versions of our target files. In our release notes, for example, I add the bug number after known issues, or after resolved issues so we can track them from release to release. We don’t want this information published in our customer-facing version, but I do want it in the guides I release to our support staff (so if they have questions about a particular issue’s progress, they can open the bug tracking system to the specific issue).

I apply my doNotDistribute condition to text that I only want to see in the Flare editor. This content isn’t included in any Flare output; it just exists in the source files. This allows me to leave notes for myself in individual topics that I can easily see when I am looking at a topic. Because the condition is excluded from all my outputs, I never have to worry that these pubs-staff-only notes will be included in an output.

If you produce multiple versions of your content, you can use conditions to mark some content as basic and other content as advanced. You can then exclude advanced content from the basic guide, and include it in the advanced version of the guide.

The conditions available in your project are governed by the file(s) in the Conditional Text folder of the Project Organizer. Unless you are an advanced Flare user, you shouldn’t need to add an additional file to this folder. You can just modify the Default conditional text file.

To modify the Default file, double click it in the Conditional Text folder of the Project Organizer. Here you can add a new condition, or change the conditional text background color. This is the color that will be applied to the text, paragraph, or topic that contains the set condition.

As with variables, don’t change the name of a condition after you have added it to a topic, or the conditions won’t build correctly for those topics.

Save your changes by clicking the Save button on the application tool bar.

Now you are ready to apply the conditions to your content.

To add a condition to a character or partial paragraph in Flare:

  1. Open a topic, and select some content.
  2. From the Format menu, select “Conditions…”
  3. Select the condition you want to apply to the content.
  4. Click OK.

The selected content will have the background color for the condition that you applied. (If you don’t see it, be sure you’ve enabled the “show/hide conditional text indicators” option on your XML Editor tool bar.)

If you apply more than one condition to text, you will be able to see both condition colors in the background in a checkerboard pattern. If you don’t see both condition colors in this pattern, see the Note at the end of this post

Let’s say you have the following text (I’m include my conditions in brackets; this isn’t the exact code Flare uses, but it is easier to read and is close enough for the purposes of this discussion):

[Conditions="PrintOnly"]Jack and Jill went [/Conditions]
[Conditions="OnlineOnly,PrintOnly"]up the hill [/Conditions]
[Conditions="OnlineOnly"]to fetch a pail [/Conditions]
 of water.

If my output includes no conditions settings, I’ll get the following text in my output:

Jack and Jill went up the hill to fetch a pail of water.

If my output includes the “PrintOnly” condition, but excludes the “OnlineOnly” condition, I’ll get the following text in my output:

Jack and Jill went up the hill of water.

If my output excludes the “PrintOnly” condition, but includes the “OnlineOnly” condition, I’ll get the following text in my output:

up the hill to fetch a pail of water.

Notice that the text “up the hill” has both conditions applied to it. If any condition is included in the output, the text will be included, even though another condition has explicitly excluded the condition. The include setting trumps the exclude setting. (See Note at end of post.)

To add a condition to a paragraph-level element in Flare:

  1. Open a topic, and right-click on the element’s block.
  2. From the context menu that appears, select “Conditions…”
  3. Select the condition you want to apply to the content.
  4. Click OK.

The selected block-level content will have the background color for the condition that you applied. (Again: if you don’t see it, be sure you’ve enabled the “show/hide conditional text indicators” option on your XML Editor tool bar.)

When using block-level conditions, if you apply two conditions to a block, you’ll see a checker-board mix of the condition colors, so you can see that multiple conditions apply. Remember: if your output includes any of those conditions, the block will be included in the output, even if the other condition is explicitly excluded.

To add a condition to a topic in Flare:

  1. Open the Content Explorer.
  2. Select a topic (or a folder).
  3. Press F4 (or right click on the topic, and select Properties).
  4. Open the Conditional Text tab.
  5. Select the condition you want to apply to the topic/folder.
  6. Click OK.

The selected topic or folder will have the condition color appear in the box next to the topic title in the Content Explorer. If you apply more than one condition to a topic or folder, you’ll see multiple colors in this box.

When you exclude a topic from a target, then that topic won’t be copied when the target is built. This can be important if you are providing the files to your clients and you don’t want them to have copies of the files that are only included in the “advanced” version of your project. (It is important to note here that all files in the project are included in all online output versions if they aren’t excluded at the topic level. This allows you to link to files in your help system, even if they aren’t listed in your TOC.)

Conditions can get a bit complicated, and I hope you’ve been able to follow through to the end on this one. It is, however, their complexity that allows them to be powerful tools in your content reuse tool box. You will notice that I’ve not discussed snippet conditions in this discussion. I think Snippet conditions are different enough from your standard conditions, that I want to discuss them in a separate post to try to keep their differences separate. Suffice it to say that there are even more options for conditions with your snippets (new functionality in Flare V3.1).

Now you have the power to use variables, snippets, and conditions so you can use a single source for your content and still publish it in multiple formats, with different content depending on the output. This is content reuse at its finest!

Come back tomorrow and we’ll talk about a sample project where we put all of this together to create several separate output products using the content reuse skills we’ve been discussing in this series.

Day 5: Wrap-up

NOTE: This is an update to my original post, which corrects some information I originally included. When you apply the condition settings properly, the INCLUDE condition trumps the EXCLUDE condition. In order to apply the settings properly, you must select each chunk of text separately and apply the conditions to it.

In our example, you would select “Jack and Jill went” and apply the PrintOnly condition. Then you would select the “up a hill” and apply both conditions. Then you would select “to fetch a pail” and apply the ScreenOnly condition. When you have done this properly, you will see a checkerboard background comprised of both colors. That is how you know you applied your conditions correctly.

Instead, if you were to select “Jack and Jill went up a hill” and applied the PrintOnly condition, then selected “up a hill to fetch a pail” and applied the ScreenOnly condition, you would have applied the conditions improperly. The background would only show one color, and the conditions will not be applied correctly in your output.

Proper nesting of conditions

The tip here is to watch the background. If you see the checkerboard background with both condition colors, you’ve done it correctly. If you don’t both colors in the background, you’ve done it wrong.

Content Reuse In-Depth: SnippetsContent Reuse In-Depth: Snippets

Posted November 29th, 2007 by paul.
Category: Software, TW Tools, Technical Writing | 1 Comment »

(This is part three of a five-part series dealing with content reuse in the Help Authoring Tool (HAT) MadCap Flare.)

Yesterday we talked about variables. Today I want to expand on that discussion and talk about snippets. Think of snippets as long variables that can contain formatting and text.

If you’ve used variables for a while, you’ve probably found yourself wishing you could include more than just short text in the variable definition. Suppose there is a procedure that you include in multiple locations in your documentation — the first three steps are the same in all these procedures. You’d like to create a bulleted list with these three steps that you can update in one location if that changes. You can’t do this in a variable.

Enter snippets.

Snippets are basically topics that can be imported into other topics. They are chunks of XML text that can be used multiple times anywhere in your project.

In the example above, you can create a snippet with the ordered list with the first three steps. You import that snippet into your content wherever it is needed. If something in those three steps changes, you can update the snippet file, and all your topics are automatically updated.

Some content authors use snippets to include a copyright footer at the end of every topic (Flare includes a better way to do this, using master pages, but I do know that some people still chose to include them in every topic.)

You can create a snippet file and name it “copyright”. Then you can import that snippet at the end of your topics. When the year changes and you need to change your copyright text, you can just edit the snippet and all the instances are updated.

So, how do you create and use snippets in Flare? It’s actually quite easy.

If you are creating a snippet from scratch, you can just go to the Project menu, and select “Add Snippet…”

In the dialog box, you give the snippet a name, and click Add. You’ll be prompted to confirm adding the file to the project; click OK. The snippet is added.

The new snippet is displayed. It works just like a Flare Topic. You can add any content to the snippet that you can add to a Flare topic. When you created your snippet, it was linked to the default CSS style sheet in the project, and you can use those styles as you create your snippet. If, however, the topic you insert the snippet into uses a different style sheet, the snippet will use the styles inherited from that topic (unless you make your style changes in line). This is actually handy; you can insert the snippet without worrying what the style will look like, because it will match the topic in which it is embedded.

Now that you’ve created your snippet, you’ll want to insert it into a topic. Snippets live in the Content Explorer in the Resources folder in a folder called (oddly enough) Snippets. This folder doesn’t exist in a project until a snippet has been added to the project.

Open a topic, and insert your cursor where you want the snippet inserted. On the Insert menu, choose Snippet. In the dialog box, locate the snippet and click OK. The snippet is added to your topic.

This is the best method to create a multi-paragraph snippet, or one that includes images.

You can’t edit the snippet in a topic. This prevents you from accidentally editing a snippet that might affect other topics. You can right click on the content of a snippet and select “Open Link…” for quick access to editing a snippet.

If you want to convert an existing element into a snippet, you can click on the element’s block in the XML editor, and select “Create snippet…”. The default behavior will allow you to name the snippet, and the source content will be replaced by the new snippet (which you can now reuse in another topic). The down side to this is that I haven’t figured out a way using this method to create snippets that contain more than one element. I can create a snippet that contains a <p> element, or a <ul> element, but I can’t figure out how to get two adjacent <p> elements into a single snippet using this method.

Snippets are fabulous for two reasons. First, because they are single sourced content, you only have to make changes in one location, and all the topics that use that snippet are automatically updated. Second, if you are localizing your help system, generally you pay for every word translated. By reusing the same procedures over and over, you only translate the snippet once, and you get to reuse it as many times as you need, saving you time and money.

Along with variables, snippets provide you with the flexibility to single source and reuse content in powerful yet simple ways.

A final word about snippets: I think you’re going to find in the neat future that Snippets are even easier to use when MadCap releases the Analyzer product. I’ve linked to the product page, but the part that is interesting in this discussion is the “snippets suggestion” feature. According to their marketing material, Analyzer will search through your project for places where you use the same phrase or segment of text (and images?). Analyzer will show you these chunks of text that you reuse frequently, and let you decide if you want to convert them into snippets, which Analyzer can do with just a couple of mouse clicks. It sounds like a powerful feature. I’ll review it here after Analyzer is released.

Tomorrow we’re going to continue the series on content reuse as we discuss Flare conditions. Then the next day we’ll wrap it up with some concrete examples of putting it all together. Stay tuned!

Day 4: Conditions