Really? Yes. Really. You know, like if you wanted to ensure the timing of the video is correct as you’re listening to the audio, or if you make an adjustment to your video or audio timeline that affects your other actions — good luck trying to resync the audio with the video.

When you edit the audio, it opens in another window, or even in Soundbooth if you have the Adobe eLearning suite. But the video recording doesn’t play, so you can’t tell if the small addition or deletion you make on the audio timeline is throwing everything else out of sync with the video recording.

Blog Sponsors

• 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

I was confused by the difference between SWF and MPEG-4 before I read this explanation (which includes video examples).

Blog Sponsors

• 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

Download MP3 (to download, right-click and select Save Target As)
Length: 65 min.

Screencasting Presentation Summary

In this podcast, Collin Turner presents on “Screencasting — Workflow and Presentation” to the Intermountain STC chapter in Utah. Here’s the presentation summary:

Screencasting (when applied properly) is a valuable tool whose popularity is gaining traction. Most available software is accessible and easy to use. You can make or break a screencast before you ever capture a single screen. This presentation covers the basics of screencasting from concept to publication. This is not a presentation on software … this is all about planning and workflow!
Collin breaks the process of creating screencasts into five accessible phases:

• Concept
• Pre-production
• Production
• Post-production
• Publication/launch

View the accompanying Zoho presentation slides.

You can also see a presentation outline here.

About Collin Turner

Collin Turner is a technical communicator, sometimes author, editor and photographer usually found deep within the workings of APIs, writing manuals or managing projects. Screen casting is one of his latest focus points during a 15-year career in the field. You can find him online at www.collinturner.com.

Links

• Intermountain STC chapter.
• Collin turner

(See a flyer about the presentation here.)

Blog Sponsors

• 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

You can create video tutorials using dozens of different methods. There are no official steps to create videos, because situations and audiences vary so widely. If you’re creating e-learning with quizzes for a global audience, your approach will be different from one who is creating demo videos for a small company.

Having said all that, here’s my general process for creating video tutorials:

1. I copy a topic from my help, put it into a Word document, and modify it into a script that I’ll read. I’ve tried being more spontaneous and off-the-cuff rather than reading scripts, but I end up having to restart so many times that it frustrates me. Scripts are fine, as long as I can communicate the info without sounding too much like I’m reading. Ideally, I start the script off with a conceptual paragraph that I illustrate in the video with a diagram. The more I write, the more I find that everyone wants to see a visual workflow or process.
2. I find an empty, quiet conference room. Luckily, at my work there’s a conference room that can’t be scheduled (so it’s often free), and it’s not adjacent to any office or other conference room. In general, I turn off anything in the room, such as a humming computer, air conditioning machine, ticking clock, or mini-fridge. One day I’ll make my own sound booth to dampen the acoustic echoing.
3. I connect my microphone to my laptop. I use an H4 Zoom recorder that connects to my laptop with a USB cord. My laptop then recognizes the Zoom as a microphone device. The Zoom H4 records pretty clearly, but since it’s a little pricey ($300), I also recommend a high-end Plantronics headset ($90). Whatever you use, avoid using your laptop’s built-in mic (because it sounds like a CB radio).
4. I open up my recording tool and the software application I’m explaining. I then fit the recording screen to the application. I personally like Camtasia Studio because it allows me to edit full-motion recording in ways that Captivate doesn’t. 640 x 480 is a good screen size, especially since some users may have their resolutions set at 1024 x 768. I start at 640 X 480 and drag the recording edge to 1000 x 750 (this keeps the same proportions while allowing me to capture the entire application; when I later edit and produce at 640 X 480, the video still looks clear because it’s proportional).
5. I prop the script up next to my laptop’s screen, and then simultaneously read my script as I move and click my mouse in the application to demonstrate a task. This is the hard part. I use the pause and resume hotkey (F9 in Camtasia Studio) to recompose myself or clear my throat if necessary. It’s hard to look at a script while also looking at the monitor, but if I keep the steps simple and short, I can often manage it without too many restarts.
6. As I read, I try to avoid swallowing, licking my lips, breathing loudly through my nose, stuttering or stumbling, over-enunciating, mumbling, sounding as if I’m reading, coughing, yawning, mis-pronouncing words I never have trouble with, or veering off my script.
7. When I’m finished making several recordings, I trot back to my desk and start editing the recordings. If the script has a conceptual intro, I insert a diagram (which I draw in Visio and Photoshop) depicting a workflow, process, or other concept. I think the visual diagram works well at the beginning of a tutorial, as it gives variety to the demo and grounds the user in a better understanding of the overall process.
8. As I edit the recording, I often need to manipulate the audio or video independently. In Camtasia Studio, I do this by selecting a portion of the audio, and then choosing File > Produce Selection As. I then produce just an MP3 file at max quality. I silence the audio on Track 1, and then import the produced MP3 file back into my project and add it to Audio Track 2. I can then move the audio independently of the video.
9. I publish the video tutorial. Although I compress the audio, I crank up the audio quality all the way. I keep the JPEG quality at about 93%, set the frame rate at about 10, and use the One Show format because it includes the preloader (whereas Express Show doesn’t). I always keep the file size around 15 MB or less because I have some users in South America and I’m not sure what their bandwidth speeds are. By keeping the videos about three minutes or less, the file size rarely exceeds 15 MB. (Almost no one has an attention span that lasts more than 5 minutes anyway.)
10. I integrate the videos into my online help file in the appropriate topics using a little javascript that pops open a new window sized just about the same as the video dimensions. Here’s the javascript:
    

    <a onclick=”window.open(‘http://mydomain.org/training/helpresources/rp/Documents/Videos/Create New Widgets.html’,'RPvideo’,'width=660,height=560,resizable=no’);return false”/ >
    <img style=”text-decoration:none; border:none;” src=”../../Resources/Images/videocamera.gif” alt=”" /> Watch Video </a>

    I also publish a web menu (“Camtasia Theater”) of the video tutorials, and create a help topic with a list of them all.

That’s my process, in a nutshell, for creating video tutorials. Overall, I’m pretty happy with it, but especially with the independent audio/video manipulation and the integration of the visual diagrams to reinforce understanding. The Zoom H4 acting as an audio interface also records with near-perfect clarity.

But I am looking to improve several things. First, I want to sound less like I’m reading, while still reading. I also need to get faster at creating visual diagrams. Finally, I’m a little perplexed that my scripts vary so much from my help topic text. When I arrange the text in a script, I listen to myself talking it out, and I start making dozens of changes. Ideally, I’d like to have my video scripts single source from my help topic text.

I dislike captions in place of voice. I once asked a user which he preferred, and he said voice ten to one. I agree. Of course voice is much more problematic for translation, but I don’t have to worry about that (yet).

I’m also not fond of the “let-my-try” videos. We have a test environment where users can experiment, and it’s just as easy to send them there to play rather than requiring them to click little hidden pixels here and there.

What’s your process for creating video tutorials? Do you have any tips or advice for me?

If you’re a serious technical communicator, you probably need a high-end digital recording device like this. Seriously. It will change your career by allowing you to deliver more powerful content. It allows you to add the audio dimension to your deliverables, which will take you into new territory and expand your technical writing world.

Here are the six main situations in which I’m using the Zoom H4:

1. Video Tutorials

I always use the Zoom H4 to record video tutorials. My last help project had about 75 topics and 22 short video tutorials (by short, I mean 2-4 minutes). I think audio visual tutorials — done with real voice, not text captions — are one of the most powerful deliverables we can offer as technical communicators, almost more powerful than written manuals. Users absolutely love to see and hear how to do a task.

Ever since I abandoned the text-caption method with Captivate, and started using off-the-cuff voice instead (using Camtasia), the video tutorials have been a lot easier and more natural to create. (Even though they’re off-the-cuff, I hit the pause and resume button many times while recording to gather my thoughts for the next few sentences. And sometimes I redo the recording 3-4 times before getting it right.)

I also decided to ditch the pan and zoom feature that I so loved because the post-production editing (setting the pan and zoom points) was taking too long. I wanted to create these videos quickly — about 3-4 tutorials in one morning. I now leave the screen size at 800 x 600 — this rarely requires me to incorporate pan and zooms.

Audio connects with users ten times more powerfully than captions. Bad audio can make you sound amateur, like you have a lisp or nasal congestion. Good audio, with a relaxed, eloquent voice (still working on that) can be like oasis in a desert for starving, frustrated users. The voice also makes your help human again — an extremely important element that is often missed without audio.

The Zoom H4 acts as an audio interface to your computer and delivers crisp, clear audio — better than most other portable recorders. The only challenge is finding a quiet place to record. (I usually end up reserving a conference room somewhere.)

2. SME Demos

When I need a SME to provide a demo of an app I need to document, it’s reassuring to record the entire session. With a cheap recorder, I’d have to strain my ears trying to interpret what the SME says. With the Zoom H4, I connect it to my laptop and record with Camtasia Studio, and the Zoom H4 picks up the SME’s voice clearly. I set the Zoom H4 on a mini tripod near where the SME sits, and it works beautifully. It just does a lot better job at capturing audio than other mics (plus, the Zoom H4 acts as an audio interface for your computer, so you can set it as your mic for Camtasia recordings). I described my recording process here.

If you use a cheap Olympus recorder, it can sound like sizzling bacon, and it will trap the audio in its own proprietary, super-compressed format (which you have to then export into WAV somehow). The Zoom H4 allows me to record directly in WAV or MP3 format.

3. Presentations

If I’m giving a presentation somewhere, either a software demo or a chapter presentation, or am listening to someone else present, the Zoom H4 does a great job capturing the audio clearly. I recently even bought a lapel mic and phantom adapter so I could clip a mic onto myself and record my presentation on blogging and podcasting, among others.

I’ve also used the Zoom H4 to capture audio when others present. One time, I put the Zoom H4 on a side table and it captured the presenter and audience comments fairly well. You can easily prop the mic onto a tripod at the front of the room near the presenter, and capture the audio decently.

The only drawback is that it is bulky and doesn’t come with a belt clip, so it is a little awkward attaching it to a presenter other than yourself.

4. Podcasts

Because the Zoom H4 works as an audio interface for your computer, you can use it to record podcasts too. Start up Skype and select the Zoom H4 as an audio interface, and instead of a staticky headset, you’ve got a professional sounding mic.

I realize many technical communicators don’t record podcasts, but when I asked for STC candidates to share their stories last year, some of them seemed to use their laptops’ built-in mics, which are on par with Fisher-Price mics or Ham radio connections to China.

Perhaps if more technical communicators did have audio equipment, they would record more podcasts.

5. Live Interviews

Because it’s so portable, the Zoom H4 really excels at live interviews. Last year at the STC conference I interviewed 20 different people (for example, listen to Jack Molisani here).

Despite a lot of background audio and other extraneous noise, the Zoom H4 focused on the interviewee’s voice and captured it clearly. It allowed me to plug in an external standard mic (I used a Shure SM58) into the device. I’ve recently decided that the Zoom’s built-in mics are more powerful than external mics. (I still sometimes use the Gigavox Levelator to enhance the audio.)

6. Jing Support Casts

Jing is a quick video capture tool that works well for providing support to confused users or to demo bugs for developers (I wrote about this here.) It’s nice to have a quick mic available to record these.

I find myself using Jing almost every day, particularly to show bugs to others. Seeing is 100 times more convincing than a convoluted description. Additionally, Jing already compresses the audio more than I like, making it sound a bit staticky. Without a good mic to record sound clearly, the Jing audio compression may degrade too much.

Final Thoughts

The price of the Zoom H4 ($299) is definitely a drawback. And you’ll spend another $100 in essential peripherals — a carrying case, a mini tripod, a 2 GB SD card, and possibly a lapel mic, phantom adapter, and standard mic. But man, this device is definitely worth it. A lot of you have purchased iPods for Christmas or your birthday. This isn’t that much more, and it will boost your career.

As an added bonus, it also looks like a taser, so you can have fun pointing it at people and pretending to press a button.

I never would have discovered this high-end recording device had I not gotten into podcasting. It’s interesting how skills in one field have carried over into another.

The new zoom-and-pan feature in Camtasia is, without argument, the most exciting feature in Camtasia. The zoom-and-pan feature allows you to easily zoom in or pan to a different area of the screen in a smooth way. This allows you to have a small frame size for your video without forcing users to break out a magnifying glass to read the screen.

I made a little screencast to demonstrate what I’m talking about. I recorded this with Camtasia over the breakfast table this morning.

[kml_flashembed movie="http://www.idratherbewriting.com/video/camtasia/camtasiavideo/camtasiavideo.swf" height="300" width="400"/]

Here’s the same attempt with Captivate.
[kml_flashembed movie="http://idratherbewriting.com/video/captivate/captivate/captivate_skin.swf " height="300" width="400"/]

I hope it’s obvious that with Camtasia, users can still view the video in a small space, whereas with Captivate, you need a magnifying glass.

The more I think about the zoom-and-pan feature, the more Camtasia wins me over. We live in an age of mobile devices — BlackBerry, iPhone, PDA, iPod, cell phones, and so on. To deliver screencasts for these applications (as well as youtube and the myriad other online video sites), you don’t have much real estate for your video.

If you shrink the application frame you’re documenting, at some point the buttons and toolbars start disappearing, misaligning, or not displaying all the columns and text you need to capture. This can be a real problem, because large frames simply do not fit into the size of your publication space. And resized frames can leave the text so small as to render the screencast useless.

Another growing publication medium is the blog post. As blogs become more common among businesses, bloggers will need to fill their posts with interesting, video content. Unless they take a video camera around to capture footage of people and scenery, most likely much of the content will be screencasts (at least for software companies). The average blog post width is about 400 pixels wide — not a lot of room if the application you’re showing spans twice that space. Smart companies will also want to get the screencasts into youtube’s space.

The only drawback of the zoom-and-pan is increased file size. You want the motion to look smooth rather than jerky, but turning up the framerate to 15 frames per second results in a larger file size. A 4 minute video can have a 10 MB flash file (but you can reduce the size by lowering the image and voice quality, or by breaking up the file into multiple small videos, and lowering the number of special effects, including the zoom-and-pan).

One of Captivate’s strength is that it doesn’t consolidate all the information into one flash file. Captivate breaks it up into smaller chunks that load faster. It not only breaks up the audio, but spreads it across multiple slides. (Captivate also has a zoom/magnify feature, but it just doesn’t work in the same smooth way as Captivate.)

Overall, I’m still too new to Camtasia to really provide an extensive analysis of the two tools. But I’m leaning toward Camtasia for several reasons. First, I really, really like that zoom-and-pan feature. But second, I also like voice and full-motion recording. I tire of screen demos that force me to click in specific areas to keep the video going. Clicking around is a hassle, and it doesn’t teach me more efficiently. I prefer to sit back, munch on something, and soak in the tutorial, listening to a human voice.

Additional Resources

• Check out the Tech Smith Visual Lounge blog, one of the best company blogs I’ve seen.
• Here’s a tutorial on posting Camtasia videos onto WordPress.com blogs
• By the way, for the microphone, I was using the H4 Zoom Recorder as an audio interface to my laptop.
• I used the Kimili Flash Embed plugin to embed the flash files directly into my WordPress site.
• Here’s the original Camtasia video on its own page.
• Here’s the original Captivate video on its own page.

I am a computer science Master’s student at the University of British Columbia, Vancouver. I am in my second year and I am on the lookout for jobs. Other than the system software engineer posts, I am considering applying for a job as a technical writer too. I do love witing as much or maybe more than I love coding and understanding operating systems. I do have experience in system software but not in technical writing, though I do blog occasionally and I also have written a few technical how-tos.

Could you please tell me what the job of a technical writer is like? How different is it from that of a software engineer? I know it pays less, but I guess you might get more satisfaction especially if you like writing? Could you, if you have the time, tell me how a day at work goes like? Do you think with my limited experience, I have a shot as a technical writer and in the area that I’m interested in?

I love getting questions like this. Of course technical writing isn’t creative writing, but it does require a lot of writing skills. If you can organize complex topics and communicate concepts clearly and concisely, conforming to a specific style, you probably have most of the writing skills you need.

As far as the salary and economic outlook, technical writing was listed as the 13th best job in America, according to Money Magazine. Technical writers earn an average salary of $57k per year. Software engineers, in contrast, appear at the top of the list and have an average salary of $80k. The job growth for engineers is projected at 46%, while that of technical writers is 23%.

In short, the economic outlook for the field of technical writing is good. As long as the tech industry is hot, the demand for technical writers will be there. Almost every software project needs a technical writer.

A lot of your job as a technical writer involves figuring out what the engineer is building. If you have an engineering background, you’re often a step ahead of other technical writers. If you can read programming code, your potential for higher income increases significantly.

The questions you asked can be answered in a lot of different ways, so I’ll give you a sample of my typical day. Below is more like a composite of different tasks all done within several weeks.

Tom’s Typical Day as a Technical Writer

• Ride metro to work — listen to podcasts on technology topics. (Tech Writer Vocies and DMN Communications are great podcasts to listen to for technical communication.)
• Attend morning scrum meeting, where each team member reports on what they did the day before. Try to figure out what has changed in the app., what new features or functionality have been added or are planned.
• Return to desk and explore the application. With development environment access, the app is only partly-functional. Have to fill in the gaps of how it could work. Experiment, test, click here and there. Guess, test out hypotheses, isolate, observe, try, etc.
• Visit software engineers to ask questions about application functionality. Inquire about workflow and other procedures.
• Visit business analyst to ask about user characteristics and tasks. What tasks will users want to perform? Try to determine who users are, clarify the different roles and their familiarity with the concepts.
• Return to desk and validate online help file by meticulously going over the steps to confirm the accuracy.
• Create screencasts using Camtasia Studio that provide audiovisual tutorials for the most confusing tasks. Getting the timing right for the slides is painstaking, but the end product is appealing.
• Create Visio diagrams representing workflows and other processes in the application. Submit to project manager for review.
• Create one-page quick reference guides in Adobe Indesign for each user role. Meticulously confirm accuracy of the steps.
• Discover new functionality in software app that wasn’t told to me. Have to return to the documentation and update it.
• Attend meeting about project, listen to engineers and project managers and business analysts talk for a while. Ask when they’re going to code the help button. Realize that the project is going to be delayed several weeks.
• Tackle bug with online help output. Display in IE needs a style adjustment. Tweak css for a while.
• Access project sites to see if any technical documentation is relevant to my needs (and up-to-date). Skim through requirements. Find discrepancies between requirements and development environment. Ask project manager which is right.
• Add more topics to online help based on new features and functionality discovered in the app.
• Suggest to engineers that they change some of the on-screen text and make the buttons behave more predictably.
• Print out documentation for the business analyst to review, and set up a meeting to encourage her to review it.
• Write article on new features for release notes and corporate newsletter. Pitch idea of a product blog.
• Return to metro for home — put on headphones and listen to podcasts.

That’s sort of a typical day/week/month/life of a technical writer.

You mentioned you’re in Vancouver. Vancouver happens to be a hub of tech writing. Last year I gave a presentation titled “20 Usability Tips for Blogging” at Doc Train West (held in downtown Vancouver). This year I’m going to be on a blogging panel with several noteworthy bloggers. If you can make it, (May 6-9), I highly recommend that you attend the Doc Train West 2008 conference.

Is technical writing satisfying? In a way, yes. I previously worked as a marketing copywriter. Sometimes I had a hard time feeling good about what I was writing, because I myself didn’t buy the products. I know technical writing helps people. Today I received an email from someone who mentioned they used the help and now they understand a difficult concept in the app. That felt good. With all the people out there who are confused by technology, who feel frustrated and try to find answers online or in help files, it feels satisfying to know I’m engaged in a good cause.

Through my examples above, I tried to show that technical writers do a lot more than writing. Very little time in the day is taken up by pure writing. There’s a lot of design, discovery, visuals and other tasks that writers do. My blog is actually what cures my itch to write.

You’ve probably wondered if technical writing is boring. I wrote a post on this a while back and received some great feedback. I think the key is to keep yourself engaged in the field. Writing a blog and creating podcasts make me enthusiastic about technical communication more than anything else.

Specifically, listening to podcasts can give you ideas, help you see how others have approached problems, and expand your knowledge in numerous ways. Unlike blog posts, you can often feel people’s excitement and energy through their voices.

If any readers have any advice or reflections for Anoop, please share them in the comments. You can also describe your typical day. I’d be interested to read that myself.

March 29 update: Definitely check out this Shanghai tech writer’s description of her typical day. A lot of parallels, despite being on the other side of the globe.

This past month I’ve been heavily using the RoboHelp 7 and Captivate 3 components of the Technical Communication Suite. RoboHelp 7 offers some impressive new features: snippets, breadcrumbs, a pod-based interface that you can drag around, integration with Framemaker and Captivate, and so on. But as is the case with many new releases, there are some bugs and unexpected shortcomings.

Captivate Integration Led to Fuzzy Videos

I really love the integration with Captivate, and the inclusion of Captivate is what sold me on the product. RoboHelp 7 allows you to begin Captivate movies from within RoboHelp. That way you don’t have to keep re-importing the files each time you update them. Additionally, you can directly embed screen demos on topics or in drop-down hotspots.

I think that’s the strength of the product, and for the most part it works well. But some glitch happened in RoboHelp that resized my Captivate movies and made them look fuzzy. I ended up deleting the RoboHelp-initiated movies and imported them manually instead (File > Import).

Firefox Display Never Finishes Loading

I was disappointed to see that my custom webhelp skin wouldn’t work in Firefox. It loaded eternally and kept trying to load until I pressed the Escape key. The Back and Forward buttons don’t store any history (until you press Escape). So when you do finally click Back, it takes you out of the help. Click Forward and it takes you back into the help, but with no TOC pane.

Luckily, there is an easy fix for this. It only involves a quick change to some lines of code. Go to Peter Grainge’s site and see the section “Help is slow to complete loading or it fails to complete loading.”

Bullets and Sub-Lists Display Differently in Firefox

While you’re looking at your project in Firefox, you might want to look closely at your bullets and sub-lists (by sub-list, I mean a, b, c …). If you apply a style to either of these elements, Firefox’s display looks goofy. The bullet or sub-list is left-aligned, while the text is spaced too far to the right.

You might also want to be careful about manually editing the css style sheet. I opened up the css style sheet in Dreamweaver and edited the topics while keeping the RoboHelp project open. It was cool to bypass the tedious style editor and quickly modify my styles like this. However, when I published the file, the output in Firefox was skewampus. In addition to the bullets and sub-lists problem, paragraph spacing was absent. Plus the help’s buttons didn’t work and the TOC collapsed on a Kubuntu OS.

I recommend using RoboHelp’s official style editor, and perhaps playing with the _ns.css stylesheet that RoboHelp outputs when you generate help.

Easy to Drag Panes into Oblivion

The new graphic interface with the draggable panes looks more modern, and you can actually drag the panes onto other monitors. But be careful with this. If you have popup windows that open on a second monitor, when you switch back to single monitor mode, RoboHelp might not know you’re only using monitor. I had an Import dialog box that kept opening on a second monitor that I didn’t have, and the app would freeze until I hit escape to close the invisible dialog box.

When I switched back to dual-monitor mode, I dragged the Import box where it should appear, and that fixed it.

Webhelp Skin Graphics Lacking

I really wish Adobe would have created more appealing webhelp skins. I think they added one new skin (“Beautiful Vista”), but it’s not very beautiful. If Adobe hired more graphic designers to create up-to-date looking buttons, the output could be a lot more attractive.

Online Help Quality Plummets

RoboHelp’s online help is interesting. There’s an online and offline mode. (The online mode didn’t work at first, but they eventually fixed it.) In Rob Houser’s review, he noted how the help was careless and sloppy. I’d add the word “uninformative.” It seems to lack more comprehensive instructions specific to the Suite.  The help points out the obvious in too many places, without providing real insight.

Rob writes,

I hate to make this observation, but RoboHelp’s online help seems to be getting worse. I’m not talking about RoboHelp’s ability to output a professional and standard looking help viewer. I’m talking about the help content that is supposed to help you learn and use RoboHelp. The examples may not seem dramatic, but taken as a whole I’m afraid that new users may not be able to learn RoboHelp simply by using the online help. They certainly aren’t seeing best practices and full RoboHelp capabilities being demonstrated.

For example, I wanted more thorough instructions on how each component interrelates with the others. When you initiate a Captivate movie from within RoboHelp, the source file (with a .cp extension) remains in your computer’s My Documents > My Adobe Captivate Projects folder — which is outside the RoboHelp project folder. To edit the movie, you right-click the .skn file from inside RoboHelp’s interface (in the Project folder) and that skin file opens the .cp file on your desktop. Don’t rename the .cp file or the .skn file won’t recognize it.

Also, don’t manually delete anything from the RoboHelp project folder (such as through Windows Explorer) because doing so will corrupt the .cpd file and RoboHelp will have to re-index the contents of that folder. I wanted more information like that in the help.

Framemaker Import Groundbreaking But Irrelevant for Me

Although the integration with Framemaker is revolutionary, I’d still rather output to a Frame file, rather than import it. Rob makes some noteworthy comments about this interaction:

The import is only one way—from FrameMaker to RoboHelp. However, many RoboHelp features are not supported in FrameMaker documents, so single-sourcing from FrameMaker to RoboHelp would seriously restrict the quality of your help system.

Another big issue: there is no capability for generating the printed documentation from RoboHelp in FrameMaker. This means the main form of printed documentation supported by RoboHelp is still Microsoft Word, which has numerous layout and formatting issues that have not been addressed for over seven years.

In his conclusion, he makes an interesting observation comparing Robohelp to Flare in terms of Framemaker interaction:

Flare is developed by a team that is experienced with help authoring, and—perhaps the most confusing distinction—Flare seems to support FrameMaker more thoroughly both for importing and exporting content than does RoboHelp.

Conclusion

RoboHelp continues to ignore some major issues, such as the lack of character-level indexing and the formatting errors when you export to Word. Despite my complaints, I like many others have an affinity for the usability of this tool. It’s like an old pair of sneakers that has some new laces and polish. Maybe some new traction too.

(The content of the demos is not what I’m showing here, but if you’re totally new to Audacity, you might find them helpful as a basic intro.) Let me know if you have any feedback.