Embedding Video

To embed video into Flare, you have to insert the video as an image file. As long as the video is a SWF file, it embeds directly on the page. In order to keep the Flash player buttons on the video, use Camtasia Studio’s Express Show format.  Express Show packages the Flash player buttons inside the SWF file, without requiring multiple files to play the video.

Note that you have to include the height and width dimensions for the “image” (which is really a video); otherwise, the video will expand to fill the entire browser. Also, the expand-to-full-frame view won’t work inside Flare — not sure why.

With the video embedded, you can easily include the video inside a drop-down hotspot. Just make sure the video is small so that it loads quickly on the page.

Relationship Tables

I’m fascinated by relationship tables. Relationship tables give you one (or more, if desired) tables where you can manage your related links. By adding topics to the same row in the relationship table, the links can become part of the same family. Links in the same family appear on the topic in a reciprocal way. You can also specify other linking options, but the family setting is easiest to maintain.

When I first created my relationship table, I styled its display to appear on the right rather than at the bottom (similar to a sidebar on a webpage). But as I looked at the help from a 1024×768 perspective, I realized that the side display crowded out too much screen real estate (leaving me with about 400 pixels after the TOC). So I moved the relationship table to the bottom of the topic.

In the master page for the project, I also added drop-down hotspot code around the relationship table code so that it would expand when clicked. I think it’s pretty cool looking. Unfortunately the project is behind a firewall and confidential, so I can’t display it without creating Greeked text and dummy screenshots, which I don’t have time to do.

Capture

I’ve been using Flare for 2 years now, and up until last week I turned up my nose at Madcap Capture. I was perfectly happy with Snagit, so why should I bother with a new screen capture tool? Now that I’ve explored and started using Capture, I’m kicking myself for not using it earlier. Capture provides you with several distinct advantages if you’re authoring in Flare:

• Shapes you add to an image remain in layers. They aren’t flattened, so you can return later and update any callout or bubble text on the screen. This is a major advantage. You can also add variables and conditional text in the callouts if necessary.
• You can add nice-looking callouts and bubble captions to the images. The bubbles are vectors, so they resize nicely. You can also choose to round the corners of the callout handle in a cool way. Previously, I inserted my callouts into numbered figure captions below the image. But in browsing Madcap’s help, I realized that I was drawn to the visual experience of the caption bubble directly on the image, with its handle pointing to a specific spot that the caption explains.
• Capture integrates nicely with Flare. You can initiate a screen capture from within Flare, and the image is inserted at your cursor’s position. If you initiate the screen capture from Capture, it saves the image directly into your Flare project’s Resources > Images folder (as long as you indicate that path in your Capture profile). To edit the image file, just right click the image and choose to edit it in Capture. Every aspect of the image is still editable.

Capture is robust and I’m still learning how to use it. I like to take 800 x 400 pixel screenshots and resize them to 75%. You can do this by setting your background scale to .75 and your canvas crop settings to 600 x 300 in your profile. When you add a caption bubble to the screenshot, the text in the caption retains its regular size (as long as you take the screenshot with your profile that has the background scale setting). Because the text isn’t resized, it doesn’t lose crispness. By the way, it’s nice having Doc-Guy, a Flare trainer, on our team. He gave me that last tip.

Exporting to DITA, Importing to WordPress

I’ve been fixed on the idea of authoring in Flare, exporting to DITA, and importing into WordPress using a DITA Import WordPress plugin. I finally set up a test site to do that on a secure server at work. It actually did import decently. Beyond that import, though, I haven’t done much with the idea. (The test server is the only server with the PHP/MySQL technical setup that I can publish to at work, so that’s also an obstacle.)

It’s cool that Flare is starting to handle DITA, and I know the intent is to import to DITA, not export to DITA. But sometimes when you have your content in DITA, you have more options for manipulating it.

Thumbnails

Flare now has the option to resize images as thumbnails. But not just any little thumbnails. When you move your mouse over the thumbnail, the image resizes with a lightbox effect — the background dims and the resized image seems to pop out at you.

I’m not sure how I’ll use thumbnails, but it’s a neat option that Flare now has. It might be useful in release notes, where you’re explaining a lot of new features but you don’t want to include full-size images everywhere. Or it could be useful if you’re writing a post in Sarah Maddox style, or if you have narrow columns without much room for full images.

Future Experimentations

Flare is a robust tool with a lot to learn. One thing I’d like to experiment with is incorporating jQuery effects into the topics. This ProPhotoBlogs support site seems to use a ton of jQuery. If you’re using jQuery in Flare, I’d like to hear from you. Or if you have other insider tips and tricks with Flare, I’d also like to hear about them as well.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

The following are some of my takeaways from the podcast:

• In an interesting real estate twist, Madcap moved back into 7777 Fay Avenue, which is where the former Blue Sky Software headquarters were. (Blue Sky produced eHelp, which later became RoboHelp.) This move back into the Blue Sky’s offices wasn’t intentional, but it seems fitting for Madcap, whose staff consists of many former RoboHelp employees. Apparently when the real estate agent unexpectedly announced the address of the new-found property, everyone listening on the phone fell silent.
• You can sense Mike’s enthusiasm in the podcast. As a former technical writer, he and others at Madcap say they understand the technical writing community and its pain points. They’re trying to solve all problems technical writers face, and they’re approaching solutions for the entire workflow.
• One can hardly ignore the impressive innovation Madcap has put forth over the past two years. They’ve produced a vast product line in a short amount of time. Some have even accused Madcap of having a “secret sweatshop of developers.”
• In talking about innovation, Mike says they aren’t “just taking a handful of existing tools, throwing them in a box, and doing some marketing” (which he refers to as shovelware — obviously referring to Adobe’s Technical Communication Suite). All of Madcap’s apps were built from the ground up to support the concept of single sourcing. The products share integration of variables, visual elements, and even code.
• Madcap Analyzer, one of their recent innovations, is a new product that Jeter says is “so good it’s scary.” Madcap Analyzer allows you to see problems in the help, such as inline formatting applied instead of styles. Hamilton says they “will continue to innovate tools into this space.”
• Madcap has an open roadmap of development. They talk about what they’re working on, what’s coming in future releases of their products. Nothing is secret at Madcap, and they even solicit their roadmap ideas from customers.
• Madcap actually uses their own tools to produce their documentation (what Jeter refers to as “eating their own dogfood”). This is also a point Rob Houser raised in his review of RoboHelp 7.
• A recent San Francisco chronicle article reported that Adobe is laying off employees, while Madcap is rapidly expanding its staff and offices.
• If you’ve downloaded Flare and Blaze, you know that the two look very similar. Mike says that when developers update the Blaze code base, it also updates Flare too, so that any hooks and other development foundations are available in the other products. This blending of code is how they share variables and other interactive features (and how they’re able to quickly produce so many products).
• Madcap’s centralization of employees gives it an advantage when it comes to communication. If you need to talk to a developer, you can walk over to his or her desk with questions (as opposed to Adobe’s distributed model, which has developers in India and offices in the U.S. and other countries.)
• Blaze promises to be a heavy-hitter — more impressive than first imagined, apparently. The formidable Sharon Burton has joined the Madcap team as product manager and is heading up Blaze.
• Madcap now has 25% of the market growth. This is a trend that has a sharp curve upward.

Personal Reactions

The rivalry between Madcap and Adobe isn’t World War III, Mike says. But there is a strong tension between the two companies. The rivalry between Adobe and Madcap is good in an economic sense, in that it keeps consumer costs down, encourages innovation, and removes the ability for either company to sit back on their laurels.

During the podcast, Hamilton talks a lot about Madcap Capture (the integrated screen capture tool). He highlights this as an example of the integration of the Madpak authoring suite. Hamilton clarifies the purpose of the suite: Madcap is trying to provide single sourcing solutions that fit the software development workflow which technical writers live in. All the products function together to enable total single sourcing of your content.

Despite the logic behind the complete product line, the emphasis on integrated screen capture tools seems hard to buy. I almost invariably tweak my screen shots using SnagIt and Photoshop before inserting them into online help. I love both of these image capturing and editing tools. Why ask me to abandon them for something else? Every product has strengths and weaknesses and customers may want to pick and choose selectively. For example, I’d choose Captivate over Mimic, and Flare over RoboHelp, and Snagit/Photoshop over other screen capture tools, and Audacity over Echo (if they’re even competitors), and Visio over some other tool they might create. In my opinion, the concept of the suite is similar to a Swiss Army knife: lots of tools in there, but all kind of mediocre.

Mike points out that content created by a variety of tools may look inconsistent. If I were to use the Madcap suite of tools, the screenshots and screen demos and online help would all have the same look and feel. And you can share variables and content more easily between a suite of tools rather than a miscellany of products.

Maybe he’s right. I haven’t tried the Madpak suite of tools — only Flare and Mimic separately. Maybe the concept of the suite will grow on me with use.

Where Are the Blogs?

Finally, where are the blogs? With all the war going on between Adobe and Madcap, you’d think that each product champion would be hitting it hard on the blog scene. Nope, they’re both blog shy. If either were to start blogging in a whole-hearted, authentic way, they’d surely win over some of the audience.

Adobe has basically outsourced its blog to the development team in India, and Madcap sticks to its forums. Neither of these puts a personable face on for customers.

Based on some insightful comments, I decided to strike out the above. Adobe does have a good blog, and it looks like Madcap is getting ready to enter the blog scene.