Notes about Word and MadCap Flare

This isn’t a code-oriented post. Here are a few thoughts about how to use Word as a part of your Flare infrastructure.

When it comes to technical authoring, inevitably, someone will ask if they can use Microsoft Word. And as author’s skills with Word grow, so does their attachment. A desire to structure content, create a single source, and produce multi-channel output lead the author to ask, how can I do those things with Word? It’s a fair question and it isn’t impossible to accomplish those things with Word. But if you are reading this, you have probably passed through that learning curve.

Word is everywhere and there are many solid use-cases for Word. It turns out that Word can be leveraged to improve one’s Flare workflow as well. In particular, two features of Word combined with Flare’s Word imports can be very powerful.

Flare’s Word import functionality is strong. If a Word document has been thoughtfully constructed with Styles, Flare can do a lot with it. Styles in Word map nicely to CSS styles in Flare. Word emphasizes headings in the default style galleries, which eases delineating Word headings into Flare topics.

Microsoft Office supports a technology called Object Linking and Embedding (OLE). OLE enables embedding of other objects, such as Visio diagrams, into Office documents. A Visio diagram embedded in Word can be seen by the reader of a Word document as a diagram. But to someone editing the document, it can be edited as a Visio file. When a Word document with an embedded Visio diagram is imported into Flare, the resulting item in Flare is an image file and a reference to it in the corresponding Flare topic.

This is great if you want to manage content by subject matter experts. It is almost certain the SME is familiar with Word. If the SME is technically minded, there is a good chance she is familiar with Visio. An SME can create content in Word, including embedded objects, and that content can be imported into Word.

One can place the Word file in a known place, such as on a network drive. If you agree to only edit the Word document and not the resultant Flare topics, the SME can come back and make changes time and time again. Add to that, the SME can update embedded objects and those will come over on the import also.

But Word can be used to as a starting point for a Flare project too. The natural use for Word import is to import existing content. When a Word shop switches to Flare, Word imports are central to the conversion process. But Word can also help create new content. Here is why.

Think about the experience of creating a Flare TOC with blank topics from scratch. It is pretty easy. But it takes longer than creating a new Word document and adding headings to create an outline. So why not just create the Word outline and import it into Flare? If you are only going to do it once, it may not be worth it. There is a time cost to setting up a Word template and a Word import file in Flare to map to the Styles in the template. But, if you like to outline your documentation before you fill in the content, it is definitely worth the time.

2 comments

  1. Thanks very much for this post! I completely agree with using Word to jump start a Flare TOC or one or more Flare topics. I’ve actually used Word in a workflow to jump start an entire Flare project, but Word is only the intermediary. I actually use mind-mapping software (my fav is MindJet MindManager) to design the architecture of what will ultimately be a Flare project. I can easily design all the nodes, and freely move things around until I’m satisfied with the structure. I can even capture a lot of notes for each node, including graphics, tables, lists, and hyperlinks. Next, I export the map to a Word file. Each map node becomes a heading of the appropriate level, and each node’s notes become content under that heading. I might do a little more to the content in this intermediate format. Ultimately, I import this Word doc into Flare, which happily makes all the topic files for me, including any corresponding image files. It’s lovely, the whole workflow. It’s especially useful for rapidly prototyping a Help system in order to help a client envision my “on-paper” design.

    1. I like that, especially the concept of a workflow for rapid prototyping of a help system. Great points

Leave a Reply to Nita beck Cancel reply

Your email address will not be published.

HTML tags are not allowed.

250,812 Spambots Blocked by Simple Comments