I was asked to provide help content in the form of a getting started guide for a piece of software that was going to be released world-wide.

I started working on the project using my tool of choice, a help authoring tool called MadCap Flare. This is a tool I really like, and have been using for several years. I’m something of an expert on Flare, so it is my first choice for pretty much any authoring project.

I started working within my group, however, and found that Flare wasn’t going to be the right solution for this project because of project constraints outside of my control. We have an in-house translation group that does all our content translation. They have their tools in place and are not interested in obtaining and learning to use a new tool (MadCap’s Lingo tool). There are certain strings in the project (specifically surrounding variables and master pages) that wouldn’t get sent to translation if they didn’t use Lingo. This project is going to go out in 24 languages, so simplifying the process is essential.

I ended up creating a site using JavaScript and HTML. Translation can handle HTML files, so this project is easy for them to manage on their side.

The moral of this story is that I ended up picking an inferior (in my opinion) tool, HTML and JavaScript because it was the right tool for this project. While I think Flare is a better tool overall, in this case, it wasn’t the right fit. Now I could have gone through a bunch of hoops to output HTML files and then re-import them into the Flare project, and then try to re-generate the project in the new language, but that was more work, with more room for error, even though it would have given me more options for designing and creating my output.

Sometimes you have to pick the right tool, even if it isn’t the best tool.

You may remember the old WordPerfect days. Those were the days of Reveal Codes (Alt F3) when changing the formatting of your document was easy. In fact, in the late 80s and early 90s, WordPerfect was the de facto standard word processor.

Now, twenty years later, Microsft Word has taken over as the market leader and standard word processor. Word Perfect is still out there, but you’re hard pressed to find any company (outside of Corel, the current owners and developers of WordPerfect) that uses WordPerfect.

Most former WordPerfect users have been forced to learn to use Microsoft Word, and many complain that they are lost without Reveal Codes, and are unable to format the document the way that they want. They believe that WordPerfect was a better word processor. However, just because WordPerfect may be the better tool, it doesn’t necessarily mean it is the right tool to use. It turns out that if you can’t share documents with other people who don’t use the same word processor then you have a harder time communicating with them. Or, if your organization doesn’t support WordPerfect, you can’t use it at work.

(Now, I will point out that current versions of WordPerfect are able to read and write MS Word files, so this isn’t a perfect comparison, yet there have been many people who, due to work requirements, have been forced to make the switch to Word, regardless of WordPerfect’s ability to read/write MS Word files.)

The trick, it seems, is knowing when the right tool IS the best tool, and knowing when the right tool is something else. As technical communicators, we need to be more focused on getting the project done the right way for our organization, while focusing less on whether or not we get to use our favorite tools.

I’d love to hear about your experiences with giving up on tools you loved for the sake of a project. Share your story in the comments, below.

This new newsletter, MadNewz, will primarily be written by community members. The inaugural newsletter is a commentary post featuring ten “best practices” for single sourcing. (Read it.)

In this first newsletter, the author uses a conversational, informal tone that doesn’t sound like corporate-speak (which I think was intentional). It contains some useful information for current Flare users, the primary audience. This is a cool idea, as it will give community members a chance to contribute and let their ideas and work be showcased by MadCap. The bottom of the article includes an e-mail address to write to if you would like to contribute to a future article.

Some things I would change: first, the weird gradient background doesn’t work for me. It distracts me from what I’m reading, which isn’t great design. Second, it was only after I read the article twice that I noticed the author’s information in the sidebar. I would have preferred to see the author’s name beneath the post title. When I’m reading articles on the web, I generally tend to ignore sidebars because they generally include navigational information, or other content not directly relevant to the article I’m reading. I found it confusing that the author info was in the sidebar—so much so that I almost posted here that I was disappointed that the author wasn’t given credit. These are very minor shortcomings, however.

All in all, I’m pleased with the direction, and look forward to some quality community-driven content in the newsletter.

I’ve been using Flare V6 for a couple of months now, and this review is to give you an end user’s review of the features and enhancements Flare V6 has to offer. You may be asking yourself if it’s worth it to upgrade your existing Flare installation to the latest version. Let me give you eight reasons to upgrade, if your budget allows.

Reason 1: WebHelp Mobile Output

Flare V6 includes a new target: WebHelp Mobile. This target creates a web-help output designed for mobile browsers, particularly the iPhone.

If you are trying to produce help content in a way that is accessible in the increasingly-important mobile browser market, this output format is exactly what you need.

To leverage your existing content in this new output format, it is as easy as adding any other target. You add a target to the project, and select WebHelp Mobile as the target type. The first time you add a WebHelp mobile target, you will also need to create a mobile skin. If you leave the default values, Flare creates a skin that matches the native iPhone skin very nicely. (There are actually thee different mobile skins to choose from including gray (default), slate, and green.)

Now, set your skin in your mobile target file, and build your project. In about 30 seconds, you’ve created a mobile-friendly target. The results look great:

Reason 2: Batch Generate and Publish

This is a feature that I needed about two years ago, and I’m thrilled to see it built directly into the Flare interface.

Consider the following use case: you are working on your help system in the same cycle as the developers who are coding the application. Nightly, an automatic build of the software takes place. You want to be sure that the latest changes to the documentation get pulled into the nightly build so they can be tested in the application.

Prior to version 6 of Flare, you had to create a script and run Flare from the command line. Your script would build each target, and then would copy it to the production environment where it would be captured by the nightly application build script. Then you had to create a Windows Scheduler task to run the batch file at a specific time.

If you didn’t know much about coding, you this was a manual process. Flare could build to a “build” location, but couldn’t publish to your “publishing” destination. And it was a manual, outside-of-the-application process.

No more.

With Flare 6, MadCap introduces batch targets. A batch target is pretty much what it sounds like: it is a batch of targets that get built and/or published by a single process.

I create a batch target like I create a normal target:

When I create a batch target, I select which existing targets should be included in the batch. Now I can choose to build all the targets in the batch, publish all the targets in the batch, or both build and publish all the targets in the batch.

What is even more powerful is that you can schedule these batch builds directly in Flare. No need to use Windows scheduler.

It is as easy as adding a task, and deciding when the task should run.

Then, of course, you need to leave your computer on during the build time, because clearly the process can’t run if your computer is not turned on.

Reason 3: Multi-Topic Review

Maybe you’ve heard about using MadCap’s review tool, XEdit, or maybe you’ve actually tried it, but found that it didn’t meet your needs. In any case, now it is time to look at it again, and closely.

Flare V6 now supports the ability to send multiple topics out for review at the same time. In prior versions, if you had a lot of topics to send to a single person, you had to go into each topic and start the review process for that topic.

Say your printed guide contained 15 topics, and you wanted a SME to review the entire chapter at once. You had to send out each topic separately for review.

Now you can open a single topic, click to send it for review, and you get the following dialog box:

Here you can add more topics for review, and then save the entire batch to be sent in a single file to the reviewer.

If you wanted, you can send the entire project out for review in a single file. This is going to make getting reviews more efficient and allow you to be even more productive in Flare.

Reason 4: File Tagging

Closely related (for me at least) to the last reason to upgrade, there is another great new feature that makes working with projects much, much easier: file tagging.

With file tagging, you are essentially creating additional metadata about a topic such as the topics author, the progress of the document through the review process, or any other tag you want to associate with a topic.

As an extreme example, I show how this would be useful by giving a real-world use case. A friend of mine (we’ll call him “Steve”) was recently working on a Flare project. He had seven different authors contributing content to him in Word format. Each document had to go through six different reviewers which included at least 4 different drafts of each document.

Steve didn’t get to choose the process, but he had to manage the flow of documentation through the process and into production. He had to create a massive spreadsheet to track the progress of each document through all the iterations of reviews and approvals. Time was spent every morning getting all the writers together to update the status of the spreadsheet document. By the end of the project at least a cumulative 150 hours had been spent trying to keep track of the status of the individual topics. Multiply that by the average hourly wage of the people who were in the meetings, and you see that somewhere in excess of $5000 was spent in those meetings, simply to track the progress of topics through the pipeline.

Too bad they didn’t have Flare V6. With Flare V6 you now have the option to add tags to individual files. In Steve’s case, he could have added a tag for the topic author, and a tag for each review phase. When a document passed through each phase of the pipeline, the author could update the flag for the topic. With Flare’s built-in reports, Steve could run a report and know instantly where each topic was in the pipeline, where each contributor was in their progress, and provide that report to the managers. There is still some maintenance involved in tracking the individual topics in Flare, but at least with Flare you are doing it in a single location. In Steve’s case, his project could have saved—literally—hundreds of hours, and thousands of dollars.

True story.

Reason 5: Improved Template Management

Have you ever tried to create a template in Flare? Prior to version 6, it was a real pain. You had to go out into the Windows file system, and create your own file structure in a specific location with everything spelled exactly correctly or the template files couldn’t be seen by Flare.

No longer. Now you can create your templates right in Flare and manage them from within Flare’s interface.

Here are three menu options in Flare V6 that apply to this discussion:

File > Save As Template…
Project > Save Project as Template…
Tools > Manage Templates…

The first, Save As Template, allows you to save any item you are working on as a template that you can re-use later, be it a topic, a target, master page, etc.

Next time you are creating an item of that type, the template will be there to choose from.

The second, Save Project as Template lets you save the current project as a template. This allows you to create lots of boilerplate content that you can save at the project level, and have ready and available for each new project that you create. This is handy when Master Projects (available since V4, I believe) are overkill. Sometimes you want to start from the same baseline, but be free to develop a project that is significantly different from another.

Finally, the third, Manage templates, lets you manage all your template files in a single window, so you can see what templates you’ve created and what you still might want to develop or modify.

Reason 6: Link Viewer

My colleague, Tom Johnson, pointed out this feature to me, and I think it is great. In earlier versions of Flare you were able to view dependencies for a given file. The link viewer gives you that same functionality, but more.

With the Link viewer you can easily see what topics link to a given topic, and where that topic links to. You can double-click any topic in the list to go directly to that topic to see if any changes are needed.

For example, maybe in version two of your product, you enhance the widget feature. It now works differently, or is invoked in a different way. With the link viewer, you can quickly see what topics link to the widget topic. Then you can open each of them and see if any text needs to be modified to accommodate this new functionality.

This may seem like a minor feature, but when it comes to making updates to documentation, I think you’ll find that this is really rather useful, saving you mouse clicks, time, and mental energy.

Reason 7: Improved PDF Support

I love the new PDF support in Flare V6. In Flare V4 MadCap gave us the ability to publish directly to PDF without needing Word or Framemaker. In Flare V5, they enhanced this capability and included options for including your own metadata in the document. In Flare V6 you can now add additional metadata and can control PDF security options from within the Flare PDF target editor.

This really makes publishing much easier for me. One of the final, manual processes I always had to do on my PDF documents was to modify the security settings and ensure that all the metadata was set in the PDF document. This was a pain, because in many cases, my PDF was pulled into the build nightly based on the batch process I outlined earlier in this article.

Now with Flare V6 I can set all the PDF settings I need in the target, and with the batch builder and publisher I really can let my automatic, nightly build be released without any post-build work at all.

Reason 8: User Interface Enhancements

Flare V6 has several user interface enhancements that don’t seem to be much individually, but in the aggregate make the whole experience smoother and nicer. For example, the target editor has been updated so that you only see the options that are relevant to the type of target you are creating. Icons have been modified throughout the application to make it easy to identify the different types of files you’re working with (each target type now has its own icon associated with it, for example).

While this probably isn’t a great argument in itself for an upgrade, it is a nice bonus.

Conclusion

In this article, I’ve given you eight reasons why you should upgrade your existing Flare installation to version 6. Flare is my first choice help authoring tool, and this latest version makes me like it all the better.

I’m interested to hear your take, as well. Please comment below and tell me your favorite new features in Flare, and sound off about the features that are missing that you’d like to see added in a future version.

________________________________
Full disclosure: I am a certified MadCap Flare trainer and an MVP in the MadCap user forums. I received a free copy of Flare V6 because of my assistance in the forums, NOT because of this review. This article represents my personal opinion and is not influenced by, nor does it necessarily represent the opinion of my employer, or of MadCap Software.

I’m still working on a post to give you the details to help you decide if you should upgrade your existing Flare project to V6 (which I’ve been previewing for about a month), but alas, with work deadlines that post will have to wait until tonight.

So check back tomorrow for my Flare V6 review and upgrade guide!

I’ve been beta testing Flare 5 for a couple of months now, and there are some great new features in Flare 5 that you are going to love. In this review, I want to point out some of my favorite new features, as well as some of Flare 5′s other great enhancements.

Let me begin by saying that I love Flare, and I think Flare 5 is a great enhancement on an already great product. I am biased; I’m a certified Flare instructor, have been a VIP in the Flare Forums for 2+ years, and am a certified MadCap Advanced Developer for Flare V4. But being biased doesn’t necessarily make me wrong <grin>. I’m under NDA for this project, but I’ve received permission to give you a preview of what you can expect from the soon-to-be-released version 5.

Here are five killer reasons you should consider upgrading your version of Flare to V5 as soon as you can:

1. Workspace improvements in both XML Editor and Source Code View
2. DITA Support
3. PDF Target Enhancements
4. Relationship Tables

5. Other Enhancements
   – Topic Tool bars
   – Thumbnail Image Support
   – Text Redaction Support
   – Improved Performance
   – Conditions in Project Organizer
   – Backup Differences
   – New Toolbar buttons

I’ll discuss each of these features in the sections below.

Workspace improvements in both XML Editor and Source Code View

Flare 5 sports a spiffy new code editor with line numbers, color-coded tags, and easy access from the XML Editor. It’s also a lot easier to get to the source code editor, as there is now a button in the XML Editor.

When you are using the XML Editor, click the “Send this File to Text Editor” button, which is now in the XML Editor toolbar.

The code view opens in a separate tab:

This image is kind of small, but you can see that the code editor includes line numbers and color-coded tags. When you make a change and save it in the code view, the change is automatically reflected in the XML Editor (WYSIWYG) view. Flare finally includes a code editor that makes me want to use it instead of an external editor!

In addition, you’ll notice new formatting indicators in the XML Editor. These help you see where the invisible tags are in your source code. For example, the following image shows the Flare 5 XML E

There are three things in the screen shot that are new in Flare 5: First, spans are now identified in the XML editor. Look at the word “originally”; notice the blue brackets around it. These indicate that there is a span applied to that text.  This makes identifying spans easier. They (obviously) don’t affect your output, but when working in the XML editor, you can easily see where the spans begin and end.

Second, notice the condition tag that is applied to the “[5]” reference. Now when you apply conditions in-line as spans, not only does the background change, but now there is a box showing which conditions have been applied (just like you see next to content in the Content Explorer, or in other areas in Flare). This is a small, but very nice enhancement.

Third, Flare now shows you empty tags so you can remove them from your code. In the case of the image above, there is an empty <p> tag set. I can delete it from the XML editor, or I can open the code view to delete it there.

DITA Support

This is the headline feature in Flare 5, and for good reason. You can now import DITA projects into Flare, edit them in Flare, and then generate any of Flare’s output types. This is a groundbreaking achievement.

As with other Flare import types, you can continue to author in a native DITA application and use Flare as a publishing engine, or you can take existing DITA content, import it into Flare, and then use Flare as your authoring tool. In either case, you can then publish your DITA files directly to PDF, WebHelp, Word, FrameMaker, etc.

Flare 5 also has a DITA target output type. This means that you can export your Flare project as a DITA project that you could then transport to any tool that supports DITA.

This is cool for so many reasons, especially when you consider the implications of project collaboration. DITA is quickly becoming a standard format for technical documentation. Being able to export your project to DITA means you can send your project to anybody who uses DITA, with whatever tool they use, and they can open and use your project. If your localization team supports DITA, you can send them a DITA export of your project for translation. If you need to send your project to a client for them to modify at a later date, you don’t have to worry about tool compatibility, because as long as they can work with DITA, you can send them files they can use. And if for some incomprehensible reason you want to use a different authoring tool, you can export your project to DITA, and import it into some other tool.

This is the end of proprietary file types! Your content is YOURS to do with what YOU WANT. You don’t need to rely on somebody creating a transform that can convert MadCap’s content into an importable format for another tool, because you can create a DITA target.

This version of Flare does not yet support native DITA authoring. While you can get DITA in and get DITA out, the project in the middle is a Flare-based project with the Flare-based XHML source files. However, a future version of Flare is supposed to provide native DITA  authoring.

If you are using DITA, or if you are considering how DITA can be used in your organization, you ought to check out Flare V5, because the direction they are going with DITA support is literally awesome.

PDF Target Enhancements

Flare 4.2 addressed some PDF enhancement requests, in that it allowed you to modify the image compression settings for creating PDF files. That was a nice feature, since you finally got some control over how images would be compressed and how that would affect your overall file size. However, you still needed the paid version of Acrobat in order to set the metadata (like author, etc.). No more. Look at what is available to you now:

Now I can truly build and release without any post-processing. I run a script nightly that builds all my documentation and places it in a location where the software build script can pick it up. Now that script builds releasable documentation. That is awesome, and this is a small feature, but one that adds a great deal of value.

Relationship Tables

DITA supports relationship tables, so Flare 5 now supports relationship tables. The Center for Information-Development management has a good article that describes DITA Relationship tables. To summarize, a relationship table is a centralized location where you can link related concepts, related tasks, and reference topics.

In Flare 5 you can insert a relationship proxy into your master page, and then every topic that is linked in the relationship table will show the relationship in the topic, grouped by concepts, tasks, and references (if a relationship exists for that topic).

When you need to update these references, you do them all in one place: the reference table. There is no need to go into individual topics and tag them with a concept; no need to add “related topics” manually. You can have these appear automatically in topics with the relationships proxy.

I have only used this superficially until now, but I plan to use this feature extensively in my next project, so I’ll keep you updated on how it goes.

Other Enhancements

There are several other enhancements I’ve discovered in Flare 5 which include:

• Topic Tool bars
• Thumbnail Image Support
• Text Redaction Support
• Improved Performance
• Conditions in Project Organizer
• Backup Differences
• New Toolbar buttons

Topic Tool bars

You can now include a toolbar anywhere in a topic, which is pretty cool. Here is a skin I created for a project I was working on. I made tabs for the tool bar, and then I moved topic-specific stuff into the topic toolbar, which I floated right. So there you can search the topic, remove highlighting, or mark the topic as a favorite. Since these are topic-level tasks, it makes sense to add them to a toolbar that is in the topic itself.

This feature greatly increases the flexibility options for creating custom skins.

Thumbnail Image Support

Flare now supports image thumbnails. You can create a thumbnail class and apply it to your images. Flare will generate a smaller version of the image, and when users hover over the image (or click on the image, you decide), a larger version of the image can be displayed.

The help system gives detailed information on how to set up and use this feature in your projects.

Text Redaction Support

If you produce sensitive documents, Flare now supports text redaction. With text redaction, you can generate two versions, say of a PDF file. One can contain the full text, and one can contain the redacted text.

You might wonder why you would want redaction when you could conditionally exclude content. In some cases (particularly in government applications) it may be preferable to produce a document with redacted text, rather than just not containing the text. Additionally, when you redact text (instead of excluding it conditionally), the page counts stay the same in both versions of the document.

Improved Performance

Flare 5 sports improved performance, especially surrounding WebHelp target generation. I don’t have any hard numbers here, but it just feels faster. It also seems to have improved stability, based on my experience using it. I can’t remember a time during my beta testing of Flare 5 that the application crashed on me. That is a far cry from the days when I was using Flare 3, which (for me) seemed much less stable. (There was a time, using Flare 3 that Flare was crashing every day at least once, so for me, the improvements in Flare 4 and Flare 5 are fantastic.)

Conditions in the Project Organizer

You can now use conditions in the Project organizer. This allows to you exclude content from the Project Organizer, based on conditions settings in the target. So, if you have separate deliverables in the same project and you want to separate the header and alias files based on the target, you can–and you won’t get any errors when you generate the build!

Again, this is a minor enhancement, but it is one that will make things a lot easier for many people.

Backup Differences

If you use the backup options in Flare, you can now view a diff of the current version from the one that is backed up, which you can view in code view, or in WYSIWYG view.

New Toolbar buttons

There are two new buttons available on the toolbar or the topic toolbar. There is now a Previous button and a Next button. If the topic is part of a browse sequence, then the previous and next buttons show the previous/next topics in the browse sequence. If the topic is not part of a browse sequence, then the buttons show the previous/next topics in the TOC. (This won’t work properly if the topic is added to the TOC in multiple places, or if a topic is not in the TOC.)

Conclusion

Flare 5 is a great enhancement to the Flare product line, and includes more features than the ones I’ve listed. If you are in the market for a help authoring tool or if you are using DITA, check out Flare V5; it will knock your socks off. If you already own Flare, upgrade when it is available. Kudos to MadCap for coming up with a great product with enhancements that really improve the technical author’s workflow, making producing great content faster and easier than ever before.

First, my original complaint with the January update was that when you created videos with small pixel dimensions (because you don’t want to capture the whole screen), when somebody tries to view the video directly (not embedded in a web page), the video expanded to the full screen.

This was a problem for me because one of the VPs in my company has a 30″ screen. If I’ve grabbed a video of a bug that happens in our software, and attach it to the bug report, when the VP tries to view the video of the bug, it is expanded something like 10x its captured size, which is hard to follow and looks terrible.

The release of Jing I installed today fixes that issue! Now when you directly view a Jing SWF file (say it is attached to the bug and the developer clicks on it to view it), small videos don’t expand to the width of the screen. Large videos do, but I can’t figure out where the breaking point is. And frankly, I’m okay with that. It was my small videos (in terms of pixel dimensions) that I was concerned about. So, a big thank you to TechSmith for listening and taking swift action on this issue.

My only gripes, and these are minor, are that first,  I wish the control bar that is added to the SWF file was placed below the capture region, instead on top of the bottom part of the capture region. Take this video for example.

Is there a reason that the controls cover up the bottom part of the captured image? If so, you ought to warn us that the bottom part won’t be visible, so we know to grab a taller portion.

My second gripe is that when I updated to the latest version, Jing lost all my button customizations. I had created several buttons to directly FTP content to my web server in a particular folder, or other buttons to save files on the network share in a specific folder. I’m going to have to remember what those were and re-create the buttons. In the first place, Jing shouldn’t have deleted these, and in the second place, if Jing really needed to delete these when it upgraded, it should have warned me first so that I was at least aware that I was going to lose my user-configured settings.

However, when I updated my second computer, these settings were saved. So there is a chance that this was user error, because for one computer it works like I want it to, but for the other one, it deleted my custom buttons. Ah well.

So my final review in a nutshell: great update, especially if you capture small pixel dimension videos. Great job TechSmith. Be aware, however, that the upgrade *might* totally erase all your custom buttons. Probably it won’t. Unless you do whatever it was I did. Anyway, thanks TechSmith!

• Dramatically faster build time for PDF targets
• Smaller file sizes for PDF targets
• Auto Save

Dramatically faster build time for PDF targets

The first thing I noticed when I built a PDF target using Flare 4.2 was how fast it was.  I’ve commented in the past about how important hardware is in getting the best build time from a Flare project, but I’ve become accustomed to the build time for my hardware set. Last week in Flare 4.1 I build three PDF targets, then I re-built them in 4.2.  Here is a break down:

So, a group of targets that were taking me a total time of more than 20 minutes to build now build in less than 5 minutes. That is a significant improvement.

Smaller file sizes for PDF targets

The next thing I noticed when I built a PDF target was how the file sizes are dramatically smaller now. This is another place that 4.2 shows huge strides. Check out these file size comparisons between 4.1 outputs and 4.2 outputs from my current project:

There are going to be a lot of happy customers when they see this! My three PDFs used to exceed 50 MB in size (added to our project’s already large download file). Now these same files only take up less than 10 MB in size. Wow.

Auto Save

MadCap has finally introduced a feature that is sure to please long time Flare users: Auto Save. You can set Auto Save in the Tools | Options setting. When enabled, by default, Flare will auto save your topics every 10 minutes. I set mine to five. Back when I was using Flare 3, this would have been huge, huge, huge, because I had serious stability problems with Flare (due to some problems with my computer, it crashed at least once per day). I now have a different system, and combined with my Flare 4 upgrade, I’ve had a serious improvement in application stability. I don’t think Flare crashed even once on me during all of January.

Auto Save is a fantastic improvement, but I’m even more thrilled with the overall stability of Flare, which seems to be much better in the V4 line than it was in the V3 line. But if you’re stuck with some kind of problem like I had on my old machine where some conflict causes Flare to be unstable for you, then you’ll really get bang for your buck for this feature. (Especially since it is a free upgrade for all Flare V4 users.)

Conclusion

I am thrilled with this release of Flare. The improvements for my projects are significant, and I’m not even a Feedback customer. If you are a Flare 4 user, upgrade today. If you aren’t a Flare 4 user, what are you waiting for? Join us in the 21st century. You’ll be glad you did!

—–

Disclaimer: If you aren’t aware, I’m a Flare Certified Trainer, and have been certified MAD (MadCap Advanced Developer). I’m also a MadCap MVP  (volunteer administrator) in the MadCap forums. I’m an avid Flare user and advocate, but not a MadCap employee.

I complained last week about Jing’s latest release, and how when I capture small videos and play the SWF file directly, the video scales to the browser viewport size. So videos that I had captured at 300×200 pixels were being displayed six times their size in my web browser, and like 10 times their size on my boss’s monitor.

I’ve had an extended conversation with TechSmith’s support department over this issue, and then yesterday I received an e-mail from a developer who is working to resolve the problem.

We’ve now written back and forth a couple of times, discussing ideas to resolve the problem.

I’ll wait until the next release of Jing to decide what I think about this whole issue, but I wanted you to know that what I think TechSmith is getting right, so far, is  how they are handling my complaint. I feel like my concern has been not only heard, but is being acted upon.

In the end, TechSmith will have to make a decision on how to proceed based on what they think is best. But at least I know that my voice has been heard and considered.

Thanks, TechSmith.

Several times every week, I will be working on documentation, and I’ll use a feature in Flare (for example, conditional snippets), and I stop and literally say, “Wow. I love Flare.”

Now, you might expect a MadCap MVP (i.e. volunteer forum moderator) and a MadSkills Certified Trainer (which isn’t my day job) to like the company that produces the software. I’ll admit I have a bias. But I became a MVP because I loved the software enough to contribute to the MadCap forums regularly. Then I was invited to join the MVP group. And I didn’t set out to be a Trainer. MadCap actually contacted me, because they know how much I know about and like Flare, to see if I could pick up a training session that the other trainers were unavailable to take.

In any case, when I see a blog entry like this, I have to be even more grateful for the fantastic people in MadCap’s support department. In the post, MK Anderson talks about an unresolved customer service incident with Adobe that has been going on since August (4+ months!). And we’re not talking a complex custom feature request. We’re talking about getting a valid product key, even for a newly upgraded product.

I compare that to the customer service I’ve personally received from MadCap software, and the comparison is stunning. I have bronze-level support from MadCap. Yet, several times, MadCap has CALLED ME on the phone to better understand a technical problem I’ve reported. All my support requests have been resolved within a few days (though some of the resolutions were “we’ve filed a bug” — which is all you an say for some issues). MadCap Support doesn’t give up on difficult to find issues; once there was a bug being reported by a couple of customers, but MadCap couldn’t track it down. They worked with the few customers reporting the issue until we discovered repeatable steps to encounter the issue, then they fixed it that same day. Try getting that kind of support from Adobe.

So here is a shout out to all the fabulous people at MadCap Support. Thanks guys for a job well done! You are a big, big part of what makes using MadCap software a great experience.